When using high DPI displays, it is usually required to scale up UI and Text to keep things readable. Eclipse and SWT work fine. However, the GLCanvas included in jogl has some issues. When using a scale factor of 200%, only the lower left quarter of the GLCanvas is used. The cause of this was fairly easy to track down. The method com.jogamp.opengl.swt.GLCanvas.updateSizeCheck() retrieves the size of the canvas by calling org.eclipse.swt.widgets.Scrollable.getClientArea(). A quick look at the code shows that this method returns the scaled size. This means that GLCanvas treats the canvas smaller than it actually is.
Even worse, it appears that SWT has no public method for retrieving the actual size of a widget on screen. My current workaround is overwriting getClientArea for GLCanvas and scaling the size back to the original values.
For my app (which uses Eclipse's SWT GL canvas instead of Jogamp's), I had to do some similar workarounds, because Eclipse's GL canvas reports the client area in pixels, but now all the mouse events are in scaled "SWT points".
Eclipse's GLCanvas hasn't been maintened since 2006, which is why we switched to the jogl GLCanvas. Not surprising it suffers the same issue. I also noticed the scaled mouse input once I added the workaround for the OpenGL part. I'm not sure if the eclipse developers had widgets like GLCanvas in mind when the DPI scaling was implemented. I suppose it allows developers to ignore the issue of DPI scaling while working only with SWT widgets. But for our application I'm afraid some rather tedious code changes are required to accommodate for this.
SWT_AUTOSCALE property would be the wrong one. It's the scaling passed to DPIUtil by VM-argument and maybe the operating system. Eclipse does some rounding as described on the page that I linked in my original post. From a quick look at the code there seems to be the propery "org.eclipse.swt.internal.deviceZoom" which holds the actual scale factor used by eclipse. I'm not at work right now so I can't check if this works.
Another option is calling org.eclipse.swt.widgets.Scrollable.getClientAreaInPixels () via reflection. Not a very nice solution either. In my opinion this is the method that the GLCanvas should use, but can't since it is private.
I'll file the bug report once I get my account. Thanks for the input.
With Eclipse 4.8 (SWT 3.107) Display class provides a new method Display.getDPI (inherrited from Device class) as well as Monitor class provides Monitor.getZoom() (int). As far as I understand the monitor zoom is normalized at a value of 100.
This is not very comfortable but I think you can recalculated the bounds of your controls back to its pixel values with it.
If you have to stay at Eclipse 4.6 you still can use DPIUtil class which lies in swt.internal. This is not public API but when working with GL you sometimes need the exact pixel values. Maybe you can provide a Facade which encapsulates the non public API and replace it later with the new methods from Eclipse 4.8.