0

I am trying to implemente a CoverFlow like effect using a QGLWidget, the problem is the texture loading process.

I have a worker (QThread) for loading images from disk, and the main thread checks for new loaded images, if it finds any then uses bindTexture for loading them into QGLContext. While the texture is being bound, the main thread is blocked, so I have a fps drop.

What is the right way to do this?

louissmr
  • 748
  • 8
  • 18

2 Answers2

2

I have found that the default behaviour of bindTexture in Qt4 is extremelly slow:

bindTexture(image,target,format,LinearFilteringBindOption | InvertedYBindOption | MipmapBindOption)

using only the LinearFilteringBindOption in the binding options speeds up the things a lot, this is my current call:

bindTexture(image, GL_TEXTURE_2D,GL_RGBA,QGLContext::LinearFilteringBindOption);

more info here : load time for a 3800x2850 bmp file reduced from 2 seconds to 34 milliseconds

Of course, if you need mipmapping, this is not the solution. In this case, I think that the way to go is Pixel Buffer Objects.

louissmr
  • 748
  • 8
  • 18
  • So, generating mipmaps of a large non-power of two sized texture is slow, why do you think Pixel Buffers would make any difference? – artm Sep 27 '12 at 18:00
  • PBOs can transfer pixel data to the graphic card using DMA without involving CPU cycles, isn't it? So using a PBO in a separated thread could solve the problem. – louissmr Sep 28 '12 at 05:26
  • Anything graphics driver can do to optimize uploading a PBO it will do to optimize uploading a texture. The problem with mipmapping a picture of that size isn't (only) the transfer, but the fact that it'll be extended to 4096x4096 and scaled down 12 times to form the mipmaps. These operations won't be sped up by switching to PBOs, in fact I don't see how PBO is relevant to mipmapping at all. – artm Sep 28 '12 at 05:49
  • even worse, if you upload several images that large without mipmapping, your rendering will be slowed down because of constant scaling down of huge textures. **With** mipmapping on the other hand you'll be wasting the video memory. The better approach in your case is to scale down the images before making textures out of them, and if you don't expect you need to scale them down much when rendering - don't create the mipmaps. – artm Sep 28 '12 at 06:01
  • So, if I use mipmapping I will use more VRAM and more bandwidth when the binding occurs, and if I don't the video card will down scale the textures If it's needed (bad for the rendering performance). The solution should be: down scale my images + mipmapping – louissmr Sep 28 '12 at 07:09
  • depending on what your cover flow looks like you might not need mipmapping at all: if you always render textures at around the same size. If the interface is such that use might resize the cover flow window at any moment making covers much smaller, it might be useful. But measuring performance with/without mipmaps will be easy once the rest of the program works. – artm Sep 28 '12 at 07:18
0

Binding in the main thread (single QGLWidget solution):

  1. decide on maximum texture size. You could decide it based on maximum possible widget size for example. Say you know that the widget can be at most (approximately) 800x600 pixels and the largest cover visible has 30 pixels margins up and down and 1:2 aspect ratio -> 600-2*30 = 540 -> maximum size of the cover is 270x540, e.g. stored in m_maxCoverSize.

  2. scale the incoming images to that size in the loader thread. It doesn't make sense to bind larger textures and the larger it is, the longer it'll take to upload to the graphics card. Use QImage::scaled(m_maxCoverSize, Qt::KeepAspectRatio) to scale loaded image and pass it to the main thread.

  3. limit the number of textures or better time spent binding them per frame. I.e. remember the time at which you started binding textures (e.g. QTime bindStartTime;) and after binding each texture do:

    if (bindStartTime.elapsed() > BIND_TIME_LIMIT) break;

BIND_TIME_LIMIT would depend on frame rate you want to keep. But of course if binding each one texture takes much longer than BIND_TIME_LIMIT you haven't solved anything.

You might still experience framerate drop while loading images though on slower machines / graphics cards. The rest of the code should be prepared to live with it (e.g. use actual time to drive animation).

Alternative solution is to bind in a separate thread (using a second invisible QGLWidget, see documentation):

2. Texture uploading in a thread.

Doing texture uploads in a thread may be very useful for applications handling large amounts of images that needs to be displayed, like for instance a photo gallery application. This is supported in Qt through the existing bindTexture() API. A simple way of doing this is to create two sharing QGLWidgets. One is made current in the main GUI thread, while the other is made current in the texture upload thread. The widget in the uploading thread is never shown, it is only used for sharing textures with the main thread. For each texture that is bound via bindTexture(), notify the main thread so that it can start using the texture.

artm
  • 3,559
  • 1
  • 26
  • 36
  • The problem is the texture size, I am using 480x700 images (more or less), but each cover has its own size (480x741, 480x744, 640x437) in order to keep the aspect ratio of the cover. I have downsized the covers on the worker thread, but depending on the graphic card, the cover size must be scaled too much.... – louissmr Sep 27 '12 at 12:07
  • sorry, my comment was incomplete. – louissmr Sep 27 '12 at 12:14
  • Thank you so much for your answer, I have tried limiting the number of binds per frame, and it helps a bit. Yesterday I have tried the alternative solution, but binding a texture in a background thread needs a makeCurrent() call (get access to the shared QGLContext) so the main thread can't access to the context while the texture is being binding and I get the same fps drop. Maybe I am doing something wrong... – louissmr Sep 27 '12 at 12:56
  • you need two QGLWidgets for the second solution - one (invisible) to bind textures and the other (visible) to render. – artm Sep 27 '12 at 12:59
  • I will try again with a second QGLWidget and a QThread, if I found problems I will share some code. Thanks again. – louissmr Sep 27 '12 at 13:25