Why are FBOs faster than writing directly to the screen?

OpenGL Development JOGL Development
#1

I recently modified a program of mine that blits textured 2D shapes to the screen. Previously, I had broken my viewport into tile regions, created a tile sized FBO, and then for each tile rendered it’s content to the FBO and then blited the FBO to the screen (using a GLJPanel). Thinking this was way to complicated, I decided to do away with the tiling and simply draw everything directly to the GLJPanel with no FBO at all. I was very surprised to find my once responsive program had slowed to a crawl. I thought it might have something to do with the GLJPanel’s pBuffers, but using a GLCanvas without FBOs didn’t speed things up much.

Unfortunately, FBOs have a drawback. If I’m using any other application on my system that uses my graphics card (Firefox, Photoshop), my FBO using Java app will often fail with an error message saying that the particular FBO I requested isn’t supported. If I kill my other programs, Java FBOs magically start working again. While this is a work around for debugging, I can’t ship like this. It’s also a pain to have to keep closing my other programs.

Any idea what’s going on? Is there a way I can get my super speed without having to use a redundant FBO? (I’m using JOGL 1.1.1. All the JSR 231s I can find are still in beta).

#2

Hi!

Your problem of FBO resquests failing because of Firefox should not happen as the both applications (Firefox and yours) do not use the same OpenGL context.

JOGL 1.1.1a is no more maintained, please switch to JOGL 2.0 Release Candidate 2 if possible.

#3

The FBO issue sounds like a driver bug, so you could consider upgrading your card drivers to see if that goes away. Also, rendering to a GLJPanel does not render directly to the screen. It renders to a pbuffer and then that gets copied into memory and drawn.

#4

My drivers are in their latest version and I’ve upgraded to JSR 231, but am still having the same issue. The FBO error aside, why would drawing everything to an FBO texture and then drawing that to the main window as a textured quad be so much faster than drawing everything to the main window directly?

#5

Its hard to say. Do you see the performance improvement when rendering to an FBO that is the same size as your GLCanvas or GLJPanel and blitting the FBO to the surface, or does the performance only exist when you render to tile-sized FBOs and blit them? It might just be that your first algorithm works better than dumping everything in one go, but its a fickle business.

#6

I’ve tried both small tiles and a single tile the size of the entire screen. In both cases I get the speedup. I’ve also tried skipping my whole tile pipeline and simply writing everything to a single screen-sized FBO buffer. I get the speed up in that case too.

#7

There could be some low-level synchronization issues that cause the performance differences. Theoretically, if the driver is forced to lock the frame memory for an onscreen canvas or pbuffer (which are both allocated by the window manager), every time it needs to render some pixels it will take a performance hit. Rendering into a texture directly means that this synchronization goes away until a single quad is blitted to the screen.

However, if you’re using double-buffering or a pbuffer, I would think the window manager and drivers would have some fast path for sharing memory.

Have you tried testing this on other machines? If you have a self-contained demo, I’d be happy to try to run it on my computer to see if I can get the same performance differences.

#8

I’ve got a test case. It runs a simple animation loop drawing many small textures to the screen.

I’ve not been able to run this on other machines, but I did find out more info.

You can get the test case here:
http://kitfox.com/tmp/FBOTest.zip

While working with the test, I learned a few things:

-This bug only seems to appear when I have Firefox 5 open in the background.
-Whenever I’m using an FBO, rendering speed is always fast
-Whenever I’m not using the FBO and Firefox is open, sometimes the program runs fast and sometimes it runs slowly (by slow, I mean about 2 fps with a 640x480 window. By fast, the frames blur together)
-I think the longer Firefox has been open, the more likely my program is to run slowly - however, this is hard to test since I would need a couple of hours between tests. However, if I keep running the program with no FBO and Firefox open, I will sometimes get a slow run, even if I have just launched Firefox.

  • I’ve not tried this with other web browsers. I have disabled hardware acceleration in Firefox.