Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Why are FBOs faster than writing directly to the screen?  (Read 2845 times)
0 Members and 1 Guest are viewing this topic.
Offline kitfox

Junior Member




Java games rock!


« Posted 2011-06-28 12:46:02 »

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).
Offline gouessej
« Reply #1 - Posted 2011-06-28 14:24:15 »

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.

Offline lhkbob

JGO Knight


Medals: 32



« Reply #2 - Posted 2011-06-28 16:34:37 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kitfox

Junior Member




Java games rock!


« Reply #3 - Posted 2011-06-29 23:27:00 »

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?
Offline lhkbob

JGO Knight


Medals: 32



« Reply #4 - Posted 2011-06-30 00:10:49 »

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.

Offline kitfox

Junior Member




Java games rock!


« Reply #5 - Posted 2011-06-30 00:30:11 »

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.
Offline lhkbob

JGO Knight


Medals: 32



« Reply #6 - Posted 2011-06-30 04:00:56 »

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.

Offline kitfox

Junior Member




Java games rock!


« Reply #7 - Posted 2011-07-01 11:13:13 »

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.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (37 views)
2014-07-24 01:59:36

Riven (38 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00

Cero (60 views)
2014-07-16 00:42:17

Riven (57 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!