Retina support in OSX?

classic Classic list List threaded Threaded
27 messages Options
12
ac
Reply | Threaded
Open this post in threaded view
|

Retina support in OSX?

ac
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

gouessej
Administrator
If it already works with OpenGL, it should work with JOGL.
Julien Gouesse | Personal blog | Website
ac
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

ac
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.

Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

Sven Gothel
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.
This is a very good summary of what probably needs to be done!

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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

gouessej
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

Sven Gothel
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
ac
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

ac
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

gouessej
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

Sven Gothel
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.
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

runiter
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

gouessej
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

runiter
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

gouessej
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

runiter
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

Sven Gothel
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

gouessej
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

runiter
gouessej wrote
Please can you tell me what is wrong except this bug when you use a Retina screen?
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

runiter
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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

runiter
In reply to this post by gouessej
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});

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
Reply | Threaded
Open this post in threaded view
|

Re: Retina support in OSX?

Sven Gothel
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});
>
JOGL's default is AUTO* .. (look it up).
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
12