thinking about Performance

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

thinking about Performance

slajar
Hi there,

I am pushing our swing/jogl combined software a bit more and I am diving a bit deeper into OpenGL to get more performance out of the PC (in my development it is a Macbook Pro Retina running MacOSX 10.11) :)

Please imagine a 1x1 pixel sized fakecanvas (with window around it) where I calculate GLSL Shaders to an FBO at 25fps. My application utilizes approx. 10% CPU in that case. Now I have a real "window", actually it is a glcanvas that's embedded into a swing application, where I actually draw this FBO from the "fake"-canvas (sharedDrawable/context sharing).
When I activate this my CPU load rises up to 30%. First I tough I have to analyse the java parts, so I took a bunch of profilers and I found that the java part does not create any reasonable CPU load.
The Instruments tool from Apple tells me that the GL calls create a lot of CPU load. Now I am a bit confused, sine I tough "orchestring" those GL-calls just creates calculation load on the GPU side not on the CPU.
Maybe someone has a good idea, where I could dig into?

I have some ideas like:
- Renita
- activated Software renderer? (actually, I checked already)
- GLCanvas embedding?!?!

Any idea is appreciated :)

regards
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: thinking about Performance

gouessej
Administrator
Hi

Forget Swing if you really want better performance. GLJPanel is useful but has a noticeable footprint.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: thinking about Performance

slajar
thanks for your answer. Yes, you are right GLJPanel is bad cause of the glReadPixel stuff.
 
Well, I am not using GLJPanel ;) I am only using GLCanvas because of performance reasons.
Since GLCanvas is attached to the AWT window handle/surface I still expect it to be neutral from a performance perspective.
Reply | Threaded
Open this post in threaded view
|

Re: thinking about Performance

gouessej
Administrator
GLCanvas has a lower memory footprint than GLJPanel but both relies on Swing/AWT and AWT under OS X has changed a lot, the JogAmp community isn't responsible for those changes and we cannot guarantee to provide "neutral" canvases when interacting with APIs not under our control. AWT under OS X uses CALayer (layer objects). I advise you to use NewtCanvasAWT instead of GLCanvas. Maybe there are some other solutions to improve your performance.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: thinking about Performance

slajar
Okay, I see. Do you have expierence with mixing Swing and NewtCanvasAWT?
The GLCanvas did a good job in the past but newt seems to be more major in performance manner. I just tried a seprate NewtCanvasAWT window and it really does run much better though. Great job!