I noticed rendering differs among different JVM with JOGL 2.3.2 : in these two examples, left window is 1.6 and right window is 1.8 (details below).
* text size of axis box differ (it uses GLUT.glutBitmapString)
* aliasing settings are not the same (1.8 version is cleaner than 1.6)
* alpha values are handled differently (1.8 appears lighter than 1.6)
* colorbar is not rendered properly on its translucent part (where text stand) : it is initially a Java2d image rendered by gl.getGL2().glPixelZoom, glRasterPos3f and then glDrawPixels)
And I just change JVM not JOGL or JZY3d versions.
Important : all pictures are based on GLCanvas for AWT.
Are these known issues?
Now if I use NewtCanvasAWT on jogl 2.3.2 I can see both version (6/8) rendering the same way : as GLCanvas renders on 1.8 (better aliasing, smaller text) without bug (no pb rendering alpha off Java2d images).
Should we throw away GLCanvas?
I then tried to do the same comparison using jzy-0.9 and jogl 2.0-rc1 (or earlier, sorry for lack of precision) with GLCanvas. There is no difference in rendering quality, but only a canvas position bug occuring for 1.8
I am comparing :
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
java version "1.8.0_40-ea"
Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b22)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
on MacOSX 10.8.5
On 10/19/2015 02:26 PM, Martin [via jogamp] wrote:
> I noticed rendering differs among different JVM with JOGL 2.3.2 : in these two
> examples, left window is 1.6 and right window is 1.8 (details below).
"on MacOSX 10.8.5"
^^ this was the most critical delta next to the JRE version (not JVM),
since 1.7* AWT uses an CALayer on OSX, which can only be utilized by
us via a FBO -> texture rendering.
Note: That means no more direct on-screen rendering since,
but FBO to texture, where the latter is being used for the
CALayer 'final compositioning'.
> * text size of axis box differ (it uses GLUT.glutBitmapString)
> * aliasing settings are not the same (1.8 version is cleaner than 1.6)
> * alpha values are handled differently (1.8 appears lighter than 1.6)
> * colorbar is not rendered properly on its translucent part (where text stand)
> : it is initially a Java2d image rendered by gl.getGL2().glPixelZoom,
> glRasterPos3f and then glDrawPixels)
Looks like there are many changes:
- FBO color space?
- Scaling ? HiDPI ?
- Java2D + GL mixing
- Translucency ?
It would be helpful to describe each difference separately
and let us analyze them, but lets continue below first:
> And I just change JVM not JOGL or JZY3d versions.
Note: NewtCanvasAWT has to use the same
> Important : all pictures are based on *GLCanvas* for AWT.
> *Are these known issues?*
> Now if I use *NewtCanvasAWT* on jogl 2.3.2 I can see both version (6/8)
> rendering the same way : as GLCanvas renders on 1.8 (better aliasing, smaller
> text) without bug (no pb rendering alpha off Java2d images).
AWT CALayer mechanism as GLCanvas for JRE >= 1.7* (see above).
Just to make sure to not misunderstand, you say that:
- NewtCanvasAWT behaves 'well' or 'as expected' on all JRE versions
(onscreen and offscreen).
- NewtCanvasAWT and GLCanvas behave 'well' or 'as expected' on JRE >= 1.7*.
so, to make a long story short:
- GLCanvas does _not_ behave 'well' or 'as expected' on JRE 6 (onscreen).
> *Should we throw away GLCanvas?*
B/c it does not behave well on JRE 6 on OSX?
Well, that is your decision ofc.
Indeed, a NEWT Window behaves more deterministic due to the simple
fact that this is our code base, i.e. we cannot influence AWTs
behavior that much.
And surely I favor NEWT and NewtCanvasAWT, for this and many other reasons
like better input responsiveness, see:
Then it will also be easier to make the NEWT based application
AWT agnostic, i.e. portable for other [embedded] platforms.
Hope this helps a bit.
Yes that's the point : NewtCanvasAwt behave consistently across JRE versions on MacOSX 10.8.5, whereas GLCanvas does not.
The things that changed in Newt compared to GLCanvas are not a big problem as long as they will alway appear the same way across JRE versions, Windowing Toolkits (SWT/AWT), GPU, OS (I understand how hard is jogamp's mission :).
Regards, and many thanks again for your help and huge work.
2015-10-19 17:14 GMT+02:00 Sven Gothel [via jogamp] <[hidden email]>:
On 10/19/2015 02:26 PM, Martin [via jogamp] wrote:
In reply to this post by Sven Gothel
To be honnest I am still hesitating to use Newt as default canvas instead of GLCanvas since :
-> NewtCanvasAwt does not downsize when it is embedded in a the following component hierarchy : JFrame -> swing.Miglayout -> JPanel -> jzy3d.CanvasNewtAwt extending either awt.Panel or JPanel -> NewtCanvasAwt (no problem if it stand the hierarchy JFrame -> jzy3d.CanvasNewtAwt )
-> part of jzy3d should be rewritten/replaced to appear as before (e.g. I liked the simple glutBitmapString but it is now sensitive to scaling as implemented in Jzy3d).
-> it has subtle but noticeable glitches :
---> there's sometime a 1 second delay to wait before the canvas react to mouse events (parenting phase?)
---> canvas resize in one step instead of resizing in multiple steps when the window is magnified (mac os animates window resizing)
---> canvas is blinking when I resize the window manually (probably a consequence of previous point)
---> sometime initializes with gray square out of frame for a very short time
---> although not able to reproduce now, I sometime had the initialized chart in a small square instead of full canvas size (by the way, that square seems to have the same size as the above mentioned gray square).
I hope I didn't sound severe, I just wanted to provide you with a general feedback after running Newt on multiple jzy3d demos.
Portability remains a huge advantage, and also final rendering is more beautiful than GLCanvas rendering.
2015-10-20 11:45 GMT+02:00 Martin Pernollet <[hidden email]>:
I don't own anything else than a mac so I can't answer :/
Anyway, here is a repo  where I try to reproduce the problem... but got another one  (see class documentation).
I added screenshots :
- the resize problem I try to reproduce (with jzy3d) : https://raw.githubusercontent.com/jzy3d/jzy3d-jogl-debug/master/images/jzy3dbug/3-after-downsize.png
- the parenting problem as it appear now (without jzy3d) : https://github.com/jzy3d/jzy3d-jogl-debug/tree/master/images/demobug.on.macos10.8.5
2015-10-20 13:14 GMT+02:00 gouessej [via jogamp] <[hidden email]>:
Maybe the first problem can be fixed, please provide a test case (preferably with JOGL but without Jzy3D so that we can add it to our unit tests) and fill a bug report.
As discussed in the above messages, I had a problem related to canvas resize on MacOSX. I submitted a bug with a complete code example to reproduce the problem with JOGL without Jzy3d but it seems it was forgotten somehow.
Some jzy3d users recently came back with the same problem on JOGL 2.3.2, hence my message.
Is this a known problem?
Thank you Julien.
I updated the bug declaration with updated versions (using Oracle VM with OSX 10.12 - Sierra).
I expect jzy3d users to confirm if they are using MigLayout or not.
2017-05-12 9:54 GMT+02:00 gouessej [via jogamp] <[hidden email]>:
By the way, JOGL 2.4.0 isn't available, we're working on JOGL 2.3.3:
In reply to this post by Martin
I am having that problem and that is the version I am using:
MacOs Sierra 10.12.4
Not sure it is related : We don t have problems with flickering but rather a non downsizing gl panel.
Upsizing is ok.
Le mar. 16 mai 2017 à 14:49, gouessej [via jogamp] <[hidden email]> a écrit :
Please indicate whether you use Oracle Java or OpenJDK. I advise you to use a more recent version of Java. Maybe this problem is already fixed. Sven fixed this one:
I concur to this!
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
Mac OS 10.12.4
I have bot upsizing- and downsizing problems.
|Free forum by Nabble - JMeter user||Edit this page|