Bug 1358 - Incorrect OpenGL surface size on SWT GLCanvas with High-DPI scaling enabled
Summary: Incorrect OpenGL surface size on SWT GLCanvas with High-DPI scaling enabled
Alias: None
Product: Jogl
Classification: JogAmp
Component: swt (show other bugs)
Version: 2.4.0
Hardware: All all
: P4 normal
Assignee: Sven Gothel
Depends on:
Blocks: 1373 1378
  Show dependency treegraph
Reported: 2018-01-30 09:26 CET by Christian B
Modified: 2019-08-20 20:05 CEST (History)
1 user (show)

See Also:
SCM Refs:
Workaround: TRUE


Note You need to log in before you can comment on or make changes to this bug.
Description Christian B 2018-01-30 09:26:19 CET
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. 

Three possible workarounds:
1. Use reflection to access call org.eclipse.swt.widgets.Scrollable.getClientAreaInPixels()
2. Overwrite org.eclipse.swt.widgets.Scrollable.getClientArea() and use DPIUtil to scale the surface back to it's size in pixels.
3. Overwrite org.eclipse.swt.widgets.Scrollable.getClientArea(), read the current scaling from the system property "org.eclipse.swt.internal.deviceZoom" and scale the surface back to it's size in pixels. (untested)

I already have a thread about this in the jogl forum

jogl version is 2.3.2, designated as current on the download page. Tested with Eclipse Oxygen on Windows 7 and 10.
Comment 1 Sven Gothel 2019-04-10 05:36:48 CEST
Commit ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0

Christian reported this bug and described multiple pathways.

This change usese the following:
- access to getClientAreaInPixels w/ fallback of
- DPIUtil.autoScaleUp(getClientArea())

I hardly have tested this on Linux/GTK, even though I use a High DPI monitor,
maybe just because of it and Eclipse _poor_ state of proper UI presentation.

Christian: Please test this .. if buggy, reopen quick for release 2.4.0

SWT/GTK High-DPI is a PIA: 
- GDK_SCALE renders offscreen and scales the image (wow & ugly)
- GDK_DPI_SCALE works at least on the fonts properly
- swt.autoScale is pretty much like: What will be scaled?
  It scales some icons in Eclipse, not fonts and result in Eclipse 
  looks horrible.

Maybe I just made this patch to vent about this poor state of things.

Notable: KDE looks great and uses DPI, firefox some GDK_DPI_SCALE equivalent (OK)

One also wonders why there is only a single scale dimension, where DPI differs x/y!
But enough of my rant :)