JUCE > v3.1.1 apps invisible or improperly scaled at scaled monitor resolutions

Continuing the discussion from JUCE v3.2.0 and v4.0.1 apps window is not visible in scaled monitor resolutions:

with JUCE v4.2 the app window is now visible but the window and all elements are grossly enlarged by about a factor of 3x larger than the specified dimensions - an improvement for sure but still utterly unusable - please fix this

this is JuceDemo at its default unmaximized size

JuceDemo can be maximized (which ironically makes it much smaller) - it is then usable but still all components are huge

1 Like

There is quite a lot of logic involved in trying to get the right scale factor for a certain display. This will depend on the distribution. On Ubuntu for example, we use dconf read /com/ubuntu/user-interface/scale-factor.

Can you set a breakpoint at queryDisplayInfos in JUCE/modules/juce_gui_basics/native/juce_linux_Windowing.cpp:1164. Then check which path it takes and to what the variable e.scale is set (lines 1217 or 1248 or 1296). Thank you!

ok - thanks for pointing me in the right direction

as it turns out the difference i noticed was because of a different monitor - the window is still not visible on the monitor i was using when i first reported this issue in v3.2.0

i discovered though that hard-coding e.scale = 1.0 (line 1218) allows the JUCE demo to render correctly on all of my monitors at all resolutions - this seems sufficient to me for now to finally upgrade my apps from v3.1.1 and see how that goes

i compiled a report of the state at methods queryDisplayInfos() and getScaleForDisplay() in the file JUCE/modules/juce_gui_basics/native/juce_linux_Windowing.cpp on several OSs on both hardware and virtual installs (debian testing , arch , trisquel 7 , ubuntu 15.10 , opensuse tumbleweed , fedora 23) - ive created a PR on github where you can see these results along with the diff showing where the traces were inserted https://github.com/bill-auger/JUCE/pull/1/files - i hope this helps

1 Like

Wow this is really great. On the display that has the 3x scaling factor: any idea why the OS is reporting such a high DPI? I would imagine that other apps would behave similar to JUCE if the display reports a DPI I like that. At least that’s what I remember when I manually changed the DPI in xorg.conf for testing.

i tried this with all available resolutions and the reported values were at least self-considtent

1360x768 info.dpi=487.108
1280x768 info.dpi=472.798
1024x768 info.dpi=427.006
800x600 info.dpi=333.599
640x480 info.dpi=266.879
720x400 info.dpi=255.789

i added a few more traces to see what was happening with the dpi and X seems to be reporting correctly and the result of getDisplayDPI() seems reasonable - the confusion seems to be in subsequent dpi calculation (after the note about raspberry pi returning zero)

queryDisplayInfos()  ==> xrandr path ==>
getDisplayDPI()      DisplayWidth=1360
getDisplayDPI()      DisplayWidthMM=357
getDisplayDPI()      DisplayHeight=768
getDisplayDPI()      DisplayHeightMM=201
getDisplayDPI()      dpiX=96.7619
getDisplayDPI()      dpiY=97.0507
queryDisplayInfos()  crtc->width=1360
queryDisplayInfos()  crtc->height=768
queryDisplayInfos()  output->mm_width=71
queryDisplayInfos()  output->mm_height=40
queryDisplayInfos()  (crtc->width * 25.4 * 0.5) / output->mm_width)=243.268
queryDisplayInfos()  (crtc->height * 25.4 * 0.5) / output->mm_height)=243.84
queryDisplayInfos()  243.268 + 243.84 = 487.108
queryDisplayInfos()  masterScale=1
getScaleForDisplay() output->name=VGA1
getScaleForDisplay() ==> gsettings path ==>
getScaleForDisplay() scaleFactor=0
getScaleForDisplay() ==> 'other' path ==>
getScaleForDisplay() info.dpi=487.108
queryDisplayInfos()  e.scale=3

one curious thing i noted is that the mm_width and mm_height via xrandr->getOutputInfo() match what is reported by xrandr on the command line - while DisplayWidthMM() and DisplayHeightMM() match what is reported by xdpyinfo on the command line which is a much larger value

$ xrandr -q
VGA1 connected 1360x768+0+0 (normal left inverted right x axis y axis) 71mm x 40mm

$ xdpyinfo
  dimensions:    1360x768 pixels (357x201 millimeters)
  resolution:    97x97 dots per inch

substituting the larger mm value reported by xdpyinfo (and DisplayWidthMM()) results in a more reasonable calculation that would yeild a final scale factor > 1.0 in this case

with xrandr values
(1360 * 25.4 * 0.5) / 71 = 243.26760563380282
( 768 * 25.4 * 0.5) / 40 = 243.83999999999997
with xdpyinfo values
(1360 * 25.4 * 0.5) / 357 = 48.38095238095238
( 768 * 25.4 * 0.5) / 201 = 48.52537313432835

Hmmm… I could definitely do this but it seems like a bit of a hack to mix two different APIs (xrandr and Xlib) to calculate the DPI. Do you have any idea why xrandr is reporting that your monitor is only 7cm wide?!?

Seems to be a known issue btw: https://bbs.archlinux.org/viewtopic.php?id=171374

in reality this monitor is about 25 inches wide so the xdpyinfo result of 357mm (~14 inches) is also not reliable - it is only JUCE apps the exhibit this behaviour but i have not seen another GUI framework that does auto-scaling or is concerned at all with the physical size of the monitor (maybe mobile toolkits do this ? - i dunno) - at first my guess was that it is just a corner case of an obscure monitor (a TV set actually) poorly-supported by X but after some reading i discovered something a bit more interesting

from what i understand now the canonical data that programs such as xrandr use is the EDID codes reported directly from the device (described here --> https://en.wikipedia.org/wiki/Extended_Display_Identification_Data ) - there is a program named read-edid for accessing this directly

it reports “DisplaySize 710 400” which according to wikipedia. is in cm units - so that explains why xrandr reports 71x40mm - as i understand windows stores this EDID in the registry but does not actually use it for anything and instead does something generic so that could explain why this problem does not occur on windows - also note the manufacture date of this monitor is 2008 so i would probably just call this one a hopeless cause - i may well be the only one in the world that is using this monitor on linux - for completeness i will add that it is said that this can be compensated for case-by-case with an explicit xorg.conf if anyone so cares - if you come across more cases like this you can ask them to install read-edid and run like this:

su -c 'apt install read-edid' su -c 'get-edid | parse-edid’
Section "Monitor"
Identifier "SONY TV"
ModelName "SONY TV"
VendorName “SNY”
# Monitor Manufactured week 1 of 2008
# EDID version 1.3
# Analog Display
DisplaySize 710 400
Gamma 2.20
Option “DPMS” "true"
Horizsync 15-57
VertRefresh 50-85
# Maximum pixel clock is 100MHz
#Not giving standard mode: 640x480, 60Hz
#Not giving standard mode: 800x600, 60Hz
#Not giving standard mode: 1024x768, 60Hz
Modeline “Mode 0” +hsync +vsync
Modeline “Mode 1” -hsync +vsync

i am not much concerned with that monitor myself - it is the case of my other monitor where the window is completely invisible that is more concerning because the end-user is simply going to conclude “this app doesnt work” - it may be that many cheapo displays are designed for 90dpi at max resolution and so it maybe safe to assume that they would all report less than 90 dpi at lower resolutions - imho auto-scaling is a neat feature but i dont see it as essential - it would satisfy me if you guys would just add some reasonable failsafe like:

if (e.scale < 0.1) e.scale = 1.0 ;

and declare this bug squished

1 Like

OK I’ll add this.

sweet - ill keep an eye on github and verify that it’s a good fix

OK I’ve implemented a sanity check.

Fabian, this patch is good - ty