jogl and jre8 on macosx

Hey guys,

we always test our software with future versions of OS and JRE. Since a while we found that JRE8 (no matter which version) and jogl (latest build) on MACOSX (currently tested on 10.8,10.9, 10.10) is not performing well anymore. There is way more CPU load with jre8.
We know that Canvas has beeing ported form Quartz to CALayer in JRE8 and we think this might be the underlaying issue.

Does anyone have a glue, what we could try to reach the same performance as we did with JRE6?

thanks in advance
Matthias

Hi

Oracle Java is quite "young" under Mac. Have you tried GLG2D? What do you do exactly with Canvas? I know it's not trivial but porting your AWT code to JOGL and using NewtCanvasAWT would give better performance for sure. I will have a similar problem soon as one part of my CAD software uses an AWT Canvas too even though supporting Mac isn't my priority.

Hey Julien,

I am not using a canvas directly, but I know that jogl is using it for GLCanvas, what I am using to mix swing and jogl code.
Unfortunately, I am not able to port the entire swing code to Newt :( I am sure that would give us better performance with a drawback of development speed (probably).

What do you mean by "trying GLG2D"? On JRE8 there is only one pipeline (OpenGL) since Quartz has been removed.

regards
Matthias

Hi

Don't you know GLG2D?

Personally, I would be very happy if I could simply use a Swing fork based on JOGL and compatible with NEWT. Brandon gave me an example of Swing drawn with NEWT here:
https://github.com/brandonborkholder/glg2d/commit/605e1b80a0dc53e70d349ae6a881832a19461188

Uhh, I haven't seen this project for a while and didn't know you mean this ;)
This is a great approach but I amm sure our swing code to way too complex to be used in that way. We'll continue to mixed swing and jogl for quite a while. Therefore we will have to fix the JRE8 issue.

In my humble opinion, it won't be fixed as AWT and Swing aren't Oracle's priority (it favors JavaFX), we'll have to live with this limitation. The example I quote is a bit old and has been removed from the repository. The maintainer of GLG2D talked a bit about a smarter solution requiring no change in the code relying on Swing but it is only a plan. In the meantime, I have nothing else to suggest :(

well, we did a short test run (takes only 1 line of code) with GLG2D and our application. Surprisingly, it is running. Well, the user interaction is not running and there are still a lot of features missing but it looks promising. Nevertheless the performance is pretty bad. Where we had 30% CPU load we have now more than 150% on a retina macbook.

We really like to have our app running on JavaFX but it is still limited in it's feature set and jogl-javaFX integration is also not really possible :( We don't want to miss jogl.

Personally, I'm not a big fan of JavaFX, it has an higher memory footprint. I assume you already looked at my bug report about JavaFX JOGL integration.

Yes, I've seen it and I ve been active in the discussion with the Oracle guys as well. I know the GL layers in JFX pretty well and I know that integrating is pretty tough. I hope they will come up with some kind of an integration layer.

The only thing we have in mind as a fallback for the future is a GLCavas Proxy that is virtually bound to a node in JFX. This will work of course but this is not really fancy ;)

One more thing ;)

I have to take up the cudgels for JavaFX. From my perspective JFX is the very first and comprehensive toolkit that unifies the ease of use and the power of GPU drawing. IMO I don't know any other toolkit at that maturity and size that does the same thing. Even on other OSs or programming platforms. The idea is great using CPU to prepare the UI and GPU to actually drawing enriched by shaders. This is great. Newt is also a good start but JFX has the potential to be successful over all platforms even on mobile and this is their major plus point. It is easier to code than swing and has potentially much better performance. What do you want more? ;)

Okay, less Memory footprint. In this case you should not even consider Java as development platform.

What do you mean exactly by "GLCanvas Proxy that is virtually bound to a node in JFX"? Please can you elaborate? Would it work better than SwingNode + GLJPanel?

The major drawback of Swingnode is that they capture the swing-UI and draw it in JFX. That takes a lot of time and CPU.

I am sure it woll work a bit better than swing node. Basically the idea consist of two things

1. GLCanvas is created in an undecorated JFrame
2. a blind node (Probably a label or so) is created in the Stage.

The JFrame is beeing positioned whenever the "blind node" is moved or resized. These movement and resizing events have to be pushed to the JFrame. The "blind node" is nothing more than a proxy to receive all events.

This procedure allows us to use JavaFX in default settings and still having Jogl power in small portios of the UI. We know this is not a real integration but it will be felt like that. I stil hope we can integrate JOGL directly in the JFX drawing so we could share textures and so on.

I know that in theory using fully hardware accelerated pipeline to draw UIs is easier with OpenJFX / JavaFX than with Swing, its architecture has been designed for this purpose from the bottom. NEWT is "only" a windowing toolkit, it has no widget but there have been already several attempts of rendering Swing components without AWT with NEWT, it can't be compared with OpenJFX which does a lot more.

JavaFX 2 was catastrophic in the real world, especially at the time it was available separately, it caused tons of deployment problems, there are still numerous machines on which it doesn't work at all and you don't know why. Sometimes, under Windows, there is no other solution than reinstalling the JRE :(

As I said in the report, unfortunately, JavaFX has some of the design flaws than AWT / Swing (bad interoperability with other toolkits as you can't really choose which thread to use as an EDT except for Swing when using a private experimental property which can be removed any time) and Java3D (multiple backends, inconsistent performance, very poor 3D features, ...). I have never seen any elaborated GUI working faster after having been ported from Swing to JavaFX, the end result was just more beautiful but neither faster nor less memory intensive. Finally, some AWT code has been copied into OpenJFX / JavaFX, it doesn't help in making it work under AWT-less environments (Android) and as lots of Android smartphones have a better support of ES 1 than ES 2 & 3, OpenJFX / JavaFX would be very slow even on a Samsung S3 like HTML5.

I started learning Java in 2002 and the first alpha version of my main 3D game only uses about 10 MB. Sorry, I use Java to make fast applications with a reasonable memory footprint, it's possible :) One of my very first test of JOGL (pre 1.0) was even between 5 and 15% faster than its C + GLUT equivalent.

Thank you. It's a nice trick :) Rewriting the ES 2 pipeline with JOGL isn't undoable but it would require a lot of time. You can already share textures with OpenJFX if you build it and ship it yourself with the ES 2 pipeline, you can create an external context that "points" to the one created by OpenJFX.