SWT GLCanvas with DPI scaling in Eclipse

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.

I'm using jogl 2.3.2 and Eclipse Oxygen.
This help page explains how Eclipse treats scale settings and how to tweak them
https://www.eclipse.org/eclipse/news/4.6/platform.php#swt-autoscale-tweaks

Hey

Please fill a bug report, don't forget to mention your workaround.

Does bugzilla share the login with another site? Because I couldn't find the register button on bugzillar nor did my forum login work. Which is why I posted this here.

Send me an email and I'll create a new account for you. We had to disable the registration because of spam bots.

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

As you alluded, I use the private API org.eclipse.swt.internal.DPIUtil.autoScaleUp() methods to convert my mouse events to pixels so everything matches again. It's a bit unsatisfactory to rely on an internal SWT API, but I guess you could also write your own version of DPIUtil if you have some way to query the scale factor. It appears that DPIUtil uses System.getProperty (SWT_AUTOSCALE) to query this factor (see http://git.eclipse.org/c/platform/eclipse.platform.swt.git/plain/bundles/org.eclipse.swt/Eclipse%20SWT/common/org/eclipse/swt/internal/DPIUtil.java), which should also work from user code.

You're right, it seems to be the way to go:
https://www.eclipse.org/eclipse/news/4.6/platform.php#swt-autoscale-tweaks

I haven't used Eclipse RCP and SWT since 2013, feel free to provide a test case and a patch.

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.

Hi,

Are there any updates on this issue ? Or any ready-to-use workarounds (I couldn't really figure which workarounds could work from the discussion above).

Thanks in advance for any information !
Cheers
Alexis

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.

Hope this helps
Felix