aboutsummaryrefslogtreecommitdiffstats
path: root/make/lib/swt/win32-win32-x86_64/.project
diff options
context:
space:
mode:
authorSven Gothel <[email protected]>2019-04-10 05:36:16 +0200
committerSven Gothel <[email protected]>2019-04-10 05:36:16 +0200
commitca7f0fb61b0a608b6e684a5bbde71f6ecb6e3fe0 (patch)
tree94a272f64d4343d223c914ecab68e379815a85f3 /make/lib/swt/win32-win32-x86_64/.project
parentfc2edeb79e42897b926081769ad3cb3e509aed71 (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/lib/swt/win32-win32-x86_64/.project')
0 files changed, 0 insertions, 0 deletions