MEGAsync icon indicating copy to clipboard operation
MEGAsync copied to clipboard

GUI too big in 4K NON-HIDPI displays

Open sl1pkn07 opened this issue 8 years ago • 8 comments

pic:

executing megasync througth console or directly from the .desktop file (https://github.com/meganz/MEGAsync/blob/master/src/MEGASync/platform/linux/data/megasync.desktop)

full desktop: screenshot_20170815_181556

screenshot_20170815_181847

executing from cosole with QT_SCALE_FACTOR=1 (for avoid HIDPI mode in Qt5):

screenshot_20170815_181801

seems the "QT_SCALE_FACTOR=2" is actived by default in megasync

sl1pkn07 avatar Aug 15 '17 16:08 sl1pkn07

found it:

https://github.com/meganz/MEGAsync/blob/d1f61ccfcc1b5c5a11a52da1d4c869f230223887/src/MEGASync/MegaApplication.cpp#L151-L160

this is inacurate when have 4K display with low or medium range DPI

for example, my screen Asus PB287Q have 4K panel, but the DPI is only 157x161 (28")

└───╼  xdpyinfo | grep -B 2 resolution
screen #0:
  dimensions:    3840x2160 pixels (621x341 millimeters)
  resolution:    157x161 dots per inch

this lead "QT_SCALE_FACTOR=%1" draw window/components/gui too big

sl1pkn07 avatar Aug 15 '17 16:08 sl1pkn07

that piece of code basically scales based on screen size. Keeping QT_SCALE_FACTOR=1 for 4K displays (even though they're not HiDPI -I'm testing on a ~124 DPI screen) will show a maybe too tiny window. In my particular case making megasync almost unusable. Plus, Qt (and for the case xdpyinfo) seems to be having trouble providing an accurate DPI measure for some screens. We can't rely on that to take an scale decision I'm afraid.

polmr avatar Aug 16 '17 15:08 polmr

in my case, xdypinfo and xrandr both show the correct DPI and screen dimensions as the official display specs

quoted from https://www.asus.com/us/Commercial-Monitors/PB287Q/:

with resolution up to 3840 by 2160. With a pixel density of 157 pixels-per-inch (PPI),

https://www.asus.com/us/Commercial-Monitors/PB287Q/specifications/

Display Viewing Area(HxV) : 620.93 x 341.28 mm
└───╼  xdpyinfo | grep -B1 dots
  dimensions:    3840x2160 pixels (621x341 millimeters)
  resolution:    157x161 dots per inch
└───╼  xrandr | grep ' connected'
DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 621mm x 341mm

I'm not sure if Qt use a own calculator or use xdpyinfo directly

about the xdpyinfo trouble (finded here https://lists.archlinux.org/pipermail/arch-general/2017-August/044077.html)

https://lists.x.org/archives/xorg-devel/2017-May/053743.html

i'm not sure if this patch has been merged in the upstream

sl1pkn07 avatar Aug 16 '17 17:08 sl1pkn07

Hi. any update about this?

greetings

sl1pkn07 avatar Apr 12 '18 15:04 sl1pkn07

Hi

a year has passed and this bug still here

any update?

greetings

sl1pkn07 avatar Jul 11 '19 15:07 sl1pkn07

This bug also affects HiDPI displays where the desktop environment's scaling factor is configured (e.g. to 200%). Setting QT_SCALE_FACTOR=1 eliminates the issue.

parcelcat avatar Sep 06 '19 14:09 parcelcat

This bug has been resolved for at least several months on a GNOME Shell environment.

parcelcat avatar Jun 05 '20 07:06 parcelcat

OS: Windows 11 Pro x64 22000.527 MEGA App: 4.6.5 x64 Display: 2560x1440 px Scale: 150% Mega app looks:

20220306-1646549157 20220306-1646549145 20220306-1646549129

FadeMind avatar Mar 06 '22 06:03 FadeMind