GLCanvas rendering differs among JVM version
Locked
GLCanvas rendering differs among JVM version
 
|
Re: GLCanvas rendering differs among JVM version
Administrator
|
On 10/19/2015 02:26 PM, Martin [via jogamp] wrote:
> Hi, > > 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. Yup. > > Important : all pictures are based on *GLCanvas* for AWT. > > *Are these known issues?* > > http://download.jzy3d.org/jogldiscuss/jzy1.0-jogl2.3.2-surface.png > http://download.jzy3d.org/jogldiscuss/jzy1.0-jogl2.3.2-scatter.png > > --------------------------------------------------- > 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: <http://jogamp.org/jogl/doc/NEWT-Overview.html> 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. Cheers, Sven |
signature.asc (828 bytes)
Re: GLCanvas rendering differs among JVM version
|
|
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: |
signature.asc (828 bytes)
Re: GLCanvas rendering differs among JVM version
|
|
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]>:
|
Re: GLCanvas rendering differs among JVM version
Administrator
|
Re: GLCanvas rendering differs among JVM version
|
|
Re: GLCanvas rendering differs among JVM version
|
|
Re: GLCanvas rendering differs among JVM version
|
Administrator
|
Re: GLCanvas rendering differs among JVM version
|
|
Re: GLCanvas rendering differs among JVM version
|
Administrator
|
Re: GLCanvas rendering differs among JVM version
|
Re: GLCanvas rendering differs among JVM version
|
Administrator
|
Re: GLCanvas rendering differs among JVM version
|
|
Re: GLCanvas rendering differs among JVM version
|
|
| Free forum by Nabble | Edit this page |