Increased resource utilization with Java 7 (OSX)

I was comparing the GL resources used by some examples in Ardor3D (specifically JoglAwtExample and JoglNewtAwtExample) between Java 1.6 and 1.7 on OSX (10.8.3) and found a significant difference. When using 1.6, the only resources being used are two textures. With 1.7, there are 16 textures, many of them with the size of the output window, 5 FBOs, 3 renderbuffers and several shaders that are not created in the program itself, including one that appears to be some sort of motion blur effect (?, I put the code of the shader here: http://pastebin.com/PBAY6b46). I did this particular test with Ardor3D, but I think this behavior is more general (https://github.com/processing/processing/issues/1776). Are these additional resources expected, or might be pointing to some other issue?

I have an animation application that has very bad performance characteristics with Java 7 compared to 6.  This would explain it if it is general.  How are you observing resource utilization in the running application?

I'm using the Apple's OpenGL profiler. It is included in the "Graphic Tools for Xcode" package in the Downloads for Apple Developers:

https://developer.apple.com/downloads/index.action

(you need an Apple Developer account)

Just in case, some docs about the profiler:

https://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGLProfilerUserGuide/GettedStarted/GettingStarted.html

On 05/24/2013 11:31 PM, ac [via jogamp] wrote: Yes, and .. you actually know them already.

Utilizing an AWT NativeWindow binding (GLCanvas) on OSX w/ Java7
and [Java6 and Applets w/ OSX 10.6.8] we are force to use the OSX CALayer.
The latter requires to render offscreen via FBOs using one GL ctx,
passing the resulting texture to a shared GL ctx for the CALayer 'compositor'/rendering.
Again: We are forced to walk this route, due to the AWT design change.

Hence it is expected to have 1-2 extra FBOs for each GLCanvas.

You can avoid this route by using pure NEWT.
Note: NewtCanvasAWT is forced to use OSX CALayer as well,
since the parent GLCanvas is not a native window but the described CALayer.

We may be able to analyze whether our FBO and CALayer implementation itself
can be optimized, however I have little hopes since it's pretty simple already,
just switching FBO buffer. Ofc, GPU and driver will give different performance here.

Hope this helps to understand the issue.

You could also say that the GLCanvas/CALayer path will expose a similar
performance as GLJPanel ..

Cheers, Sven

Short answer: we have to use NEWT without AWT + we need a great GUI library for NEWT

Hi guys, yes I was already aware of the extra resource creation from the conversation I had a while ago with Sven about the implementation of the FBO layer, the GLFBODrawable class, etc. However, I never checked the actual resource usage on OSX using a profiler (!), so I was a bit surprised to see that so many textures and FBOs are created even for the simplest programs. But anyways, I will just accept Sven's assessment and view this situation as an unfortunate consequence of the underlying changes in AWT made by Apple and Oracle. Just today I did some additional optimization in Processing, and I was able to remove a couple of superfluous textures I was creating along the away, but I agree with the view that not much more can be trimmed away...

Now, I also understand that the best performance is achieved using pure NEWT, which I can confirm since I run several tests comparing the performance between different setups. Unfortunately, at this point in the Processing 2.0 development path (our goal being to release 2.0 final fairly soon) switching to a pure NEWT architecture is not a possibility, since it would introduce a substantial amount of breakage with existing libraries and projects. So at this stage I just want to make sure that I'm using JOGL in the most appropriate and performant way given the constraints of embedding the canvas into an AWT's applet. In relation to this, I followed Julien's advice of using the invoke() method to execute my GL code, which works quite nicely on Windows/Linux, with the exception of OSX of course... I opened a bug report with a self contained test-case code:

https://jogamp.org/bugzilla/show_bug.cgi?id=735

if you Sven could take a quick look at this and give me some feedback at least to know that I'm not doing anything stupid, I'd appreciate it a lot.

Cheers,
Andres

I think that lots of third party libraries use Swing or at least AWT. You can switch to NEWT in the future but as soon as people will embed a NEWT window into an AWT component under Mac OS X, they will have similar problems. If we succeed in using JavaFX 2 with NEWT but without some parts of its own windowing toolkit, we might get a very reliable and interesting result.

On 05/28/2013 01:01 AM, ac [via jogamp] wrote: Unfortunately .. yes. However, if a 3rd party will review our
FBObject/CALayer solution - maybe she can find something.
I know, it is complicated w/ the offscreen surface layer interface,
spreading through quite a few modules (context, nativewindow and even NEWT).

One more thing, we optimized GLJPanel quite a bit .. so using it on OSX could
also be a solution to your resource problem.
Latest GLJPanel enhancements allow it to use a shared FBO/flip 'pixelbuffer',
which reduces the footprint when using multiple GLJPanels dramatically.
Performance wise there is no change ofc.
Thank you!

>
> if you Sven could take a quick look at this and give me some feedback at least
> to know that I'm not doing anything stupid, I'd appreciate it a lot.

I will try to look at it this week.

Due to some extraordinary server maintenance work (I will post this issue in
another thread) .. I am a bit tight with my time .. as usually.
However, let's see...
>
> Cheers,
> Andres

Cheers, Sven

I wonder if just switching Java3D to use GLJPanel as a base instead of AWT canvas might be an
option to break away form the AWT dependency, if the performance isn't that bad, it would certainly be
more flexible.

Harvey

Please don't do that. Swing depends on AWT anyway and the performance penalty when using GLJPanel instead of GLCanvas is important on some machines I have used for years (even though it isn't the case with recent high end graphics cards). Developers can still put a GLCanvas into a JPanel even though this is not the best solution. If you want better performance without AWT, use NEWT.

On 05/29/2013 11:02 PM, gouessej [via jogamp] wrote:
> Please don't do that. Swing depends on AWT anyway and the performance penalty
> when using GLJPanel instead of GLCanvas is important on some machines I have
> used for years (even though it isn't the case with recent high end graphics
> cards). Developers can still put a GLCanvas into a JPanel even though this is
> not the best solution. If you want better performance without AWT, use NEWT.

Disclaimer: I prefer pure NEWT as well, we know that :)

However .. if solving heavyweight/lightweight (lw/hw) issues w/ Java2D
and allowing a quirk-less simple user implementation w/ same behavior on
all platform - we lately figured that GLJPanel is the way to go.

Yes, it's slower in general, but allows seamlessly using Java2D
with any lw/hw hacks.

Note-1: 'Java2D use case' here includes Swing.

Note-2: A simple 'AWT use case' w/o Java2D hw/lw usage
        still can simply use GLCanvas.

From an application standpoint relying on the 'Java2D use case'
w/ lw/hw mixing etc, I would:

  - Base implementation w/ GLJPanel

  - Add a fast path w/ GLCanvas/NEWT if possible

Again .. this is for the lw/hw Java2D scenario only :)

~Sven

On 05/29/2013 11:02 PM, gouessej [via jogamp] wrote:
> Please don't do that. Swing depends on AWT anyway and the performance penalty
> when using GLJPanel instead of GLCanvas is important on some machines I have
> used for years (even though it isn't the case with recent high end graphics
> cards). Developers can still put a GLCanvas into a JPanel even though this is
> not the best solution.
Sadly this hw/lw mixing doesn't work on all platform - most notably:
  OSX (of course).

If you want better performance without AWT, use NEWT.

of course!

But sometimes .. there are constraints.

~Sven

I agree with you except about GLJPanel. I would rather keep the basic canvas of Java3D based on GLCanvas and encourage the use of the other one based on GLJPanel when the latter doesn't work as expected in order to avoid some end users to conclude that Java3D is generally slower than some other scenegraphs. It is difficult to encourage developers to use it because it has a very bad reputation, using the less fast canvas by default is not a good idea in my humble opinion even though GLJPanel is better in many cases. I understand that there are constraints, typically in RCP applications using Netbeans Platform (based on Swing) or Eclipse RCP (based on SWT).

> > if you Sven could take a quick look at this and give me some feedback at least
> > to know that I'm not doing anything stupid, I'd appreciate it a lot.
>
> I will try to look at it this week.
>
> Due to some extraordinary server maintenance work (I will post this issue in
> another thread) .. I am a bit tight with my time .. as usually.
> However, let's see...
> >
> > Cheers,
>>  Andres
>
> Cheers, Sven

Great, thanks a lot for all of your hard work!

Andres