Hi, just wanted to get an idea of how well (or not) the new Retina macs are supported in JOGL. Any specific issues/recommendations to keep in mind? For instance, does pure NEWT support Retina out of the box, or does it need special parameters, etc.?
Thanks a lot, Andres |
Administrator
|
If it already works with OpenGL, it should work with JOGL.
Julien Gouesse | Personal blog | Website
|
Yes, that sounds like the logical answer, however a couple of people reported Processing issues that only happen on Retina machines:
https://github.com/processing/processing/issues/1812 https://github.com/processing/processing/issues/1699 I don't know if this is relevant here, but from some discussion on a LWJGL thread about OSX it seems that Retina support might be tricky, at least in certain modes: http://lwjgl.org/forum/index.php/topic,4711.msg26462.html#msg26462 "A rather messy issue with implementing retina support is when switching it on the high resolution mode only applies to the OpenGL context (normally 4x the normal pixel size but not guaranteed to be so and can change in future). The size used by the windowing API's (Cocoa/Quartz, etc) still remains the original non retina pixel size, so API calls like Display.getWidth(), Display.getHeight(), Mouse.getX(), Mouse.getY(), etc won't match the context size (often used in calls like glViewport, glScissor, glReadPixels, glTexImage2D, etc)." I still need to run tests on Retina machines myself, so I cannot talk from my own experience yet. |
Administrator
|
On 05/29/2013 04:54 PM, ac [via jogamp] wrote:
> Yes, that sounds like the logical answer, however a couple of people reported > Processing issues that only happen on Retina machines: > > https://github.com/processing/processing/issues/1812 > https://github.com/processing/processing/issues/1699 > > I don't know if this is relevant here, but from some discussion on a LWJGL > thread about OSX it seems that Retina support might be tricky, at least in > certain modes: > > http://lwjgl.org/forum/index.php/topic,4711.msg26462.html#msg26462 > > "A rather messy issue with implementing retina support is when switching it on > the high resolution mode only applies to the OpenGL context (normally 4x the > normal pixel size but not guaranteed to be so and can change in future). The > size used by the windowing API's (Cocoa/Quartz, etc) still remains the > original non retina pixel size, so API calls like Display.getWidth(), > Display.getHeight(), Mouse.getX(), Mouse.getY(), etc won't match the context > size (often used in calls like glViewport, glScissor, glReadPixels, > glTexImage2D, etc)." > > I still need to run tests on Retina machines myself, so I cannot talk from my > own experience yet. Can you add a new bug entry (enhancement) for this and add all the above ? I would call it "Enable Hi-Dpi Mode on OSX (Retina)" IMHO, if retina is available, we should use it - i.e. why missing all the pixels ? This would give similar [hardware] experience as w/ other TKs. AFAIK, we 'just' have to set a magic pixel-configuration bit/property. As you mentioned, the window coordinate mapping must be performed as well then. Naturally, I am against an OSX only config flag to toggle Hi-Dpi. Maybe it can fit in our MonitorMode schema ? Only problem is that on OSX, it is window based - but we could ignore this fact ofc and use Hi-Dpi per monitor, if so selected. More thoughts / ideas are welcome. Note: I do not posses a Retina OSX machine. ~Sven signature.asc (911 bytes) Download Attachment |
Administrator
|
It will be tricky to make it work with Swing, AWT & SWT whereas it should not be very difficult to support in pure NEWT. I didn't imagine that it was implemented that way.
Julien Gouesse | Personal blog | Website
|
Administrator
|
On 05/29/2013 05:14 PM, gouessej [via jogamp] wrote:
> It will be tricky to make it work with Swing, AWT & SWT whereas it should not > be very difficult to support in pure NEWT. Yes, was more thinking about NEWT 1st ofc :) ~Sven signature.asc (911 bytes) Download Attachment |
The bug report is here: https://jogamp.org/bugzilla/show_bug.cgi?id=741
|
Administrator
|
In reply to this post by Sven Gothel
I was more thinking about NEWT only, it makes sense as it works only for OpenGL under OSX.
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by ac
Bug 741 Solved <https://jogamp.org/bugzilla/show_bug.cgi?id=741>
Test cases: <https://jogamp.org/bugzilla/show_bug.cgi?id=741#c20> - com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT - com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2AWT - com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2GLJPanelAWT - com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NewtCanvasAWT i.e. works w/ AWT GLCanvas, GLJPanel, NEWT Window and NewtCanvasAWT. |
Is this problem solved in Ardor3D also?
It appears that although this was solved in JOGL a year ago, in Ardor3D it's still a problem. My Ardor3D application has this problem in Retina display mac computers. I tried both Newt and SwingCanvas and they both have Retina display problems: JoglNewtAwtCanvas canvas = new JoglNewtAwtCanvas(settings, new JoglCanvasRenderer(this)); JoglSwingCanvas canvas = new JoglSwingCanvas(settings, new JoglCanvasRenderer(this));
Saeid Nourian, Ph.D. Eng. | Graphing Calculator 3D
|
Administrator
|
Please use the right words: Ardor3D != JogAmp's Ardor3D Continuation.
Yes it's a problem in JogAmp's Ardor3D Continuation: https://github.com/gouessej/Ardor3D/issues/14 The workaround isn't very nice but it's best than nothing. Fixing this bug is quite risky and requires a good understanding of window units and pixel units. Reminder: JoglSwingCanvas has been moved into ardor3d-jogl-awt. Edit.: Keep in mind that everybody doesn't own a Mac. I do my best.
Julien Gouesse | Personal blog | Website
|
Thanks gouessej,
I was indeed referring to JogAmp Ardor3D. Curious, how come this problem is fixed in JOGL without workaround, but in Ardor3D we need to use the workaround you mentioned? Also, why would JoglSwingCanvas be affected by it? Doesn't JoglSwingCanvas simply paint the canvas buffer on swing component and allow the swing component to be stretched/resize in anyway it wants under retina display condition? Finally, how can I access setSurfaceScale() method from within Ardor3D framework?
Saeid Nourian, Ph.D. Eng. | Graphing Calculator 3D
|
Administrator
|
JogAmp's Ardor3D Continuation wraps some JOGL APIs and assumes that the pixel unit and the window unit are the same as I explained in the bug report. JoglSwingCanvas extends GLJPanel, then you can call this method on it.
Runiter, you should have looked at the Java documentation and I remind you that I have spent a lot of time to make it work and generate it.
Julien Gouesse | Personal blog | Website
|
This post was updated on .
I spent lots of time trying to figure how I can call setSurfaceScale from Ardor3D and I finally figured it out.
I called it this way: ((JAWTWindow)((JoglNewtAwtCanvas)canvas).getNativeWindow()).setSurfaceScale(new float[] {2, 2}); Is this correct? The above code does not throw any errors but it doesn't do what it's supposed to do either. The canvas rendering region is not resized at all. It looks exactly the same regardless of the above code. What am I doing wrong? Edit: I'm testing it in Windows and I just realized that this function is OS dependent. I will test it on a mac when I can get one to see if it works in there.
Saeid Nourian, Ph.D. Eng. | Graphing Calculator 3D
|
Administrator
|
On 10/07/2015 07:42 PM, runiter [via jogamp] wrote:
> I spent lots of time trying to figure how I can call setSurfaceScale from > Ardor3D ... Why don't you coop and plan surface-scale support w/ Julien? Maybe you can add a similar semantic to this software, since it is backward compatible. ~Sven signature.asc (828 bytes) Download Attachment |
Administrator
|
In reply to this post by runiter
You should have used com.jogamp.nativewindow.ScalableSurface.IDENTITY_PIXELSCALE, it's mentioned in the bug report.
I can fix the resizing bug, I know exactly what to do. Please can you tell me what is wrong except this bug when you use a Retina screen?
Julien Gouesse | Personal blog | Website
|
Thanks for your help. So my problem is that when I run my Ardor3D application in Retina display screens, the canvas only renders the lower left quarter and the rest of the canvas is black. My understanding is that to fix this problem, instead of ScalableSurface.IDENTITY_PIXELSCALE I should pass 2, is this not correct?
Saeid Nourian, Ph.D. Eng. | Graphing Calculator 3D
|
Okay I found out another interesting thing.
Java3D which is also built on top of JOGL works fine in Retina display! Any idea why Java3D scales well but Ardor3D doesn't?
Saeid Nourian, Ph.D. Eng. | Graphing Calculator 3D
|
In reply to this post by gouessej
Thanks gouessej, Your suggestion worked great. I just assumed that surfaceScale is set to IDENTITY by default so I didn't even bother trying passing that arguement. But the following indeed worked: ((JoglSwingCanvas)canvas).setSurfaceScale(new float[] {ScalableSurface.IDENTITY_PIXELSCALE, ScalableSurface.IDENTITY_PIXELSCALE}); My question is, why not set SurfaceScale to IDENTITY_PIXELSCALE by default to fix this issue for all Ardor3D programmers without any direct intervention by them?
Saeid Nourian, Ph.D. Eng. | Graphing Calculator 3D
|
Administrator
|
On 10/08/2015 07:33 PM, runiter [via jogamp] wrote:
> gouessej wrote > You should have used > com.jogamp.nativewindow.ScalableSurface.IDENTITY_PIXELSCALE, it's > mentioned in the bug report. > > Thanks gouessej, > Your suggestion worked great. I just assumed that surfaceScale is set to > IDENTITY by default so I didn't even bother trying passing that arguement. But > the following indeed worked: > > ((JoglSwingCanvas)canvas).setSurfaceScale(new float[] > {ScalableSurface.IDENTITY_PIXELSCALE, ScalableSurface.IDENTITY_PIXELSCALE}); > That implies .. use highest available scale, or default. > My question is, why not set SurfaceScale to IDENTITY_PIXELSCALE by default to > fix this issue for all Ardor3D programmers without any direct intervention by > them? In the current situation this would be the best choice! However, Ardor3D could work w/ the scale if getSurface[Width|Height]() (pixel units) would be used for all graphics related operations, instead of get[Width|Height]() (window units). The 'windowing operations' still use get[Width|Height]() hence a scale operation (look it up) must be performed to convert window units <-> pixel units. ~Sven signature.asc (828 bytes) Download Attachment |
Free forum by Nabble | Edit this page |