diff options
| author | Sven Gothel <[email protected]> | 2019-04-10 05:36:16 +0200 |
|---|---|---|
| committer | Sven Gothel <[email protected]> | 2019-04-10 05:36:16 +0200 |
| commit | ca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0 (patch) | |
| tree | 94a272f64d4343d223c914ecab68e379815a85f3 /make/scripts/lsGLtoES2_commons.sh | |
| parent | fc2edeb79e42897b926081769ad3cb3e509aed71 (diff) | |
Bug 1358: 'Honor' SWT's projection of High-DPI Scaling (Reading hidden pixel dimensions)
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 :)
Diffstat (limited to 'make/scripts/lsGLtoES2_commons.sh')
0 files changed, 0 insertions, 0 deletions