Some clarifications about Texture performance

[fabrizio.giudici]

Hello.

I’m going to release a component based on JOGL that renders a “CoverFlow” View for the NetBeans RCP platform (screenshot below). I started from the “Twinkle” demo by Romain Guy, Chris Campbell and others and refactored it heavily for making the animation pluggable, managing asynchronous loading of images (needed in the real world) and integrating with the NetBeans RCP APIs.

There are some issues left, that I think are mostly related to my deep ignorance of JOGL (without starting from Twinkle code I would never be able to deal with the JOGL stuff by myself). In details:

1. the animation is reasonably smooth when the component is run with the size shown in the screenshot, but if I maximize it, things get not so smooth as I would expect (on a MacBook Pro). At the moment, the bitmaps used as texture are 400x400 but I plan to reuse part of the code for other things that would deal with full-screen images (e.g. 1500x1500). Part of the problem is that I don’t know which performance I should expect from the thing, but looking at NASA World Wind for Java or some games, I think it should be better. Is there any benchmark I can use as a reference? Could it be due to the use of GLJPanel instead of GLCanvas? At the moment I’m reinstalling my Linux and Windows box, so I didn’t run any test with Java 6 yet.

2. one specific problem with the animation smoothness is when a new image is loaded and converted in a Texture. In this case the problem is severe since the operation takes around 200ms (around 100ms during the preparation of the texture and 100 extra ms I see with the next paintComponent(). To address this issue I’m evaluating some different way of caching, for instance trying to keep as long as possible the Textures (instead of purging them whenever an object exits from the scene), but in this case I need to know how I can get the amount of free video card memory (where I suppose textures are stored) in order to implement a LRU cache or such. Also, I suppose the glTexSubImage2D() operation can’t be performed in a separate thread, right?

Thanks in advance.

[kbr]

@fabrizio.giudici

1. the animation is reasonably smooth when the component is run with the size shown in the screenshot, but if I maximize it, things get not so smooth as I would expect (on a MacBook Pro). At the moment, the bitmaps used as texture are 400x400 but I plan to reuse part of the code for other things that would deal with full-screen images (e.g. 1500x1500). Part of the problem is that I don’t know which performance I should expect from the thing, but looking at NASA World Wind for Java or some games, I think it should be better. Is there any benchmark I can use as a reference? Could it be due to the use of GLJPanel instead of GLCanvas? At the moment I’m reinstalling my Linux and Windows box, so I didn’t run any test with Java 6 yet.

Yes, the GLJPanel is not the highest performance option. You need to use the GLCanvas to reach the fully hardware accelerated code path in a portable way.

@fabrizio.giudici

2. one specific problem with the animation smoothness is when a new image is loaded and converted in a Texture. In this case the problem is severe since the operation takes around 200ms (around 100ms during the preparation of the texture and 100 extra ms I see with the next paintComponent(). To address this issue I’m evaluating some different way of caching, for instance trying to keep as long as possible the Textures (instead of purging them whenever an object exits from the scene), but in this case I need to know how I can get the amount of free video card memory (where I suppose textures are stored) in order to implement a LRU cache or such. Also, I suppose the glTexSubImage2D() operation can’t be performed in a separate thread, right?

In OpenGL there is no way to query the amount of available video card memory. You can use the API glAreTexturesResident but this is only a hint. Since OpenGL takes over the responsibility of transferring your texture data back up to the card if it gets punted due to a lack of VRAM, you might just make your cache time-expiring rather than space-constrained.

If you create a 1x1 GLPbuffer that shares textures and display lists with your main view (a GLCanvas or a GLJPanel), then you can make that pbuffer’s context current on a background thread and do your texture uploads from that thread, and use the textures from the main rendering thread. Note that if you do this, you might run into multithreading bugs with some OpenGL drivers so you should probably have an alternate code path that reverts back to a single-threaded mode.