Bug 7267 - Xvnc DPI increases slowly on resize
Summary: Xvnc DPI increases slowly on resize
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Pierre Ossman
URL:
Keywords: ossman_tester, relnotes
Depends on: 7785
Blocks:
  Show dependency tree / graph
 
Reported: 2018-10-30 12:30 CET by Karl Mikaelsson
Modified: 2021-12-13 15:59 CET (History)
3 users (show)

See Also:
Acceptance Criteria:
• ☐ The session-side DPI is kept constant (± 1 DPI) over 5 cycles of session resizes between low resolution (720x576) and high resolution (3840x2160). • ☐ If no explicit DPI is set, it should be kept at 96. • ☐ If the X server is given an explicit DPI through `-dpi <dpi>' in `/vsmagent/xserver_args', the DPI should be kept at `<dpi>'. • ☐ `-dpi 48' • ☐ `-dpi 96' • ☐ `-dpi 192'

Attachments
Suggested patch (2.32 KB, patch)
2020-05-14 18:08 CEST, Pierre Ossman 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Description Karl Mikaelsson cendio 2018-10-30 12:30:45 CET 
When resizing a ThinLinc session, the session-side DPI is increased by a small amount on some, but not all resizes.

I've reproduced this on a ThinLinc 4.9.0 server.

This shell oneliner can be used to view the resolution change as you resize the ThinLinc session.

> $ oldres=""; while true; do newres=$(xdpyinfo | grep resolution); if [[ "x${newres}" != "x${oldres}" ]]; then echo "$(date): ${newres}"; oldres="${newres}"; fi; sleep 1; done

> tis okt 30 12:23:24 CET 2018:   resolution:    96x96 dots per inch
> tis okt 30 12:23:32 CET 2018:   resolution:    96x97 dots per inch
> tis okt 30 12:23:42 CET 2018:   resolution:    96x98 dots per inch
> tis okt 30 12:23:46 CET 2018:   resolution:    96x99 dots per inch
> tis okt 30 12:23:54 CET 2018:   resolution:    96x100 dots per inch
> tis okt 30 12:24:00 CET 2018:   resolution:    96x101 dots per inch
> tis okt 30 12:24:06 CET 2018:   resolution:    96x102 dots per inch
> tis okt 30 12:24:14 CET 2018:   resolution:    97x102 dots per inch
> tis okt 30 12:24:26 CET 2018:   resolution:    98x102 dots per inch
> tis okt 30 12:24:40 CET 2018:   resolution:    99x102 dots per inch

It looks that the DPI value is only changed for the "direction" of the resize - making the session wider/narrower will only affect the first number, and making it higher/lower will only modify the second number.
Comment 2 Pierre Ossman cendio 2018-10-30 16:26:15 CET 
This is supposed to be handled by vncRandRResizeScreen() in RandrGlue.c. Must be some rounding error that keeps accumulating.
Comment 3 Karl Mikaelsson cendio 2018-10-31 09:21:21 CET 
As a workaround, run "xrandr --dpi <desired resolution>" inside the ThinLinc session whenever this starts becoming annoying.
Comment 4 Pierre Ossman cendio 2020-05-14 18:08:24 CEST 
Created attachment 953 [details]
Suggested patch
Comment 8 William Sjöblom cendio 2021-12-09 16:32:45 CET 
I've managed to reproduce the issue using the 4.13.0 server (on Fedora Server 35) with client build #2287 (on Fedora Workstation 34).

Using the above setup, but with the server upgraded to build #2371 containing the upstream fix, I can no longer see the issue.

Testing was done by repeatedly resizing the ThinLinc vncviewer window (with automatic session resize enabled) between its minimum size and covering both my 1200p monitors while observing the output of:

> xdpyinfo | grep resolution

Worth noting is that the observed DPI will creep a tiny bit from the set DPI for really small resolutions. Just as before, this is due to integer rounding errors. But since these errors are no longer part of a feedback loop, the observed DPI will not diverge from the set DPI over time as before. Thus, I deem this small creep very much acceptable since we are dealing with integers after all.
Comment 10 William Sjöblom cendio 2021-12-09 16:54:19 CET 
Since I was not involved in the upstream fix we can consider this bug tested from a technical standpoint. So what remains for the tester is checking that the release notes look fine.
Comment 11 William Sjöblom cendio 2021-12-10 10:21:58 CET 
After a round of feedback, we've come to the conclusion that this bug needs some acceptance criteria and additional testing.
Comment 12 William Sjöblom cendio 2021-12-10 13:10:41 CET 
I have now verified all acceptance criteria using the same setup as in comment 8. The high-resolution session size was accomplished by enabling full-screen mode on a 4k 16:9 monitor while the low-resolution one was accomplished by running the following while in windowed mode:

> wmctrl -r "ThinLinc Client" -e 0,0,0,720,576

• ☑ The session-side DPI is kept constant (± 1 DPI) over 5 cycles of
  session resizes between low resolution (720x576) and high resolution
  (3840x2160).
  • ☑ If no explicit DPI is set, it should be kept at 96.
  • ☑ If the X server is given an explicit DPI through `-dpi <dpi>' in
    `/vsmagent/xserver_args', the DPI should be kept at `<dpi>'.
    • ☑ `-dpi 48'
    • ☑ `-dpi 96'
    • ☑ `-dpi 192'

Marking as resolved!
Comment 13 Pierre Ossman cendio 2021-12-13 13:20:11 CET 
It seems like some desktop environments have a fix for this. I cannot reproduce this using GNOME on Ubuntu 20.04 with ThinLinc 4.13.0. The bug is seen if I use Xfce on the same system though.

The test case is the same in both cases, toggling between 1024x768 and 1920x1131 (maximised on my local GNOME desktop).
Comment 14 Pierre Ossman cendio 2021-12-13 15:59:45 CET 
After upgrading to build 2373 everything stays stable at 96 dpi with the above test.

Random resizing doesn't seem to trigger any DPI creep. However it does get some rounding issues for extremely low resolutions. The lowest resolution that vncviewer will allow is 100x100 pixels. At this point a DPI of 98 is reported, which is as close as is possible given the limits of the variables (the ideal physical width is 26.46 cm, and 26 is picked).

Release notes look good.

> • ☐ The session-side DPI is kept constant (± 1 DPI) over 5 cycles of
>   session resizes between low resolution (720x576) and high resolution
>   (3840x2160).

It is kept as close as possible (which can be +2 DPI) over all resolutions I've thrown at it.

>   • ☐ If no explicit DPI is set, it should be kept at 96.

Yup.

>   • ☐ If the X server is given an explicit DPI through `-dpi <dpi>' in
>     `/vsmagent/xserver_args', the DPI should be kept at `<dpi>'.
>     • ☐ `-dpi 48'
>     • ☐ `-dpi 96'
>     • ☐ `-dpi 192'

With Xfce it respects the argument given and holds the DPI at that level as best it can (i.e. only rounding problems at small resolutions). Tested 48 DPI and 280¹ DPI.

However with GNOME it tends to jump to 96 dpi no matter what I've configured. Not always though, and I'm not sure what exactly triggers things.

It's not an issue for this bug though, as there is no creep. But I've filed bug 7806 to track this separate issue.

¹ The rounding errors get more frequent at such a high DPI though
Note You need to log in before you can comment on or make changes to this bug.