Posted by Matteo Battaglio on Jul 26, 2010; 2:21pm
URL: https://forum.jogamp.org/Texture-rendering-performance-problems-tp966089p996442.html

Demoscene Passivist wrote

- Use -Dsun.java2d.opengl=true AND -Dsun.java2d.noddraw=true to avoid hardware acceleration trouble

Using these options causes artifacts on my applications.. Here's an example:

- Use GLCanvas and do ur Java2D rendering stuff with com.jogamp.opengl.util.awt.TextureRenderer
- Use VolatileImages in conjunction with -Dsun.java2d.opengl.fbobject=true to render ur Java2D stuff
  See here for further info: http://weblogs.java.net/blog/campbell/archive/2005/09/java2djogl_inte_1.html

In my code I don't use Buffered/VolatileImage, but only native ByteBuffers which are passed as parameter to glTexImage2D in the display() method of the GLCanvas/JPanel

- Try using PBOs for CPU base rendering if none of the above works.
  See here for some nice code+benchmarks: http://today.java.net/article/2008/10/28/integrating-glpbuffer-and-java-graphics2d

As far as I know (after reading this thread) PBuffer and PBOs are two completely different things.. Am I wrong?
Why are you associating PBOs with CPU based rendering?
My intentions are to achieve asynchronous and DMA-based texture transfers as described in this tutorial I've just found.

In addition to that I can't really understand why performance of ur texture transfer is so bad. Take a look at this small routine I've done a couple of month ago: http://www.youtube.com/watch?v=zPX8z0du5I4

It renders a fullscreen 1280x1024 texture using a GLCanvas and TextureRenderer. In front of the Java2D stuff theres some simple translucent JOGL rendering going on. The Java2D 'wave' is a simple BufferedImage rendered using pure softwarerendering setting every single pixel by hand (1280x1024 using the CPU). The whole BufferedImage is then tranferred to the GPU every frame (using TextureRenderer) and rendered as simple plane texture in the background. The whole routine runs at ~100+ frames per second on my nearly 3+ year old Core2Duo notebook. And this is all without any DMA/PBuffer/FBO trickery ...

Maybe u could provide some code of what u are actually doing so that we can get a better impression. Seems to me the problem lies somewhere else ...

The real problem is that my application is a video-surveillance application which needs to display up to 16 video panels, each of those rendering a 720x576 @ 25 fps video stream.
Since the decoding process is CPU-hungry, I need to optimize the most I can the rendering process.
So far I can say that:
-GLJPanel shouldn't be used, since without the opengl and noddraw options it doesn't enable hw acceleration
-The CPU load in my tests (which DON'T involve the decoding phase) is directly dependent on the video frame resolution (or -better - the video frame weight), suggesting that the problem lies in the textures not being transferred by the DMA but by the CPU.