xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 3 years ago

#1132 closed enhancement (fixed)

more sensible default vfb resolution on startup

Reported by: Antoine Martin Owned by: alas
Priority: major Milestone: 0.17
Component: server Version: trunk
Keywords: x11 resolution xvfb Cc:

Description

One way to ensure that the Xvfb resolution matches that of the client when the child commands get started is to use the new start-after-connect flag (see ticket:1114#comment:3). But this is not practical in all situations.

Another stop gap measure would be to provide more sensible defaults.
The default initial resolution with xdummy will be the highest resolution available. With the current trunk builds on Fedora (and probably as far back as 0.15.x too), that's:

$ DISPLAY=:100 xdpyinfo | grep dimensions
  dimensions:    8192x4096 pixels (2167x1084 millimeters)

Most clients will be connecting from 1080p or at most 4k.
We should set the screen a resolution that is more likely to be close to the final resolution we set.
According to statistics http://www.w3schools.com/browsers/browsers_display.asp, I think 1080p is a good bet. (or we could overestimate slightly and go for something like WQHD).
I don't think we want this configurable on the command line either, an env var override should be enough.

This is somewhat related to dpi (#163) and dummy randr (#56).

Change History (8)

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

For older versions this kinda works around the issue:

xpra start :100 --start-child=xterm --start="xrandr -s 1920x1080"

But when adding more start commands, there is no guarantee that the xrandr one will have completed by the time the other ones start. (though generally speaking, that's almost always the case since xrandr is very fast to run)


Done more "properly" in r12007: we set the xvfb resolution to 1080p on startup.
You can tweak this using:

XPRA_DEFAULT_VFB_RESOLUTION=2560x1600 xpra start ..

Invalid values may cause the server to fail to start, use the value "0" to turn off this feature.
We only set the resolution if it matches one of the default ones exactly.

@afarr: the applications will now see the virtual screen dimensions as being 1080p rather than the huge 8k default we had. This may have an impact on DPI and rendering. We still resize the virtual screen when the client connects (if needed).
Feel free to suggest a better default resolution we can use.

comment:2 Changed 3 years ago by alas

Owner: changed from alas to Antoine Martin

Did some testing of this... with XPRA_DEFAULT_VFB_RESOLUTION = 0; 2560x1440; 2560x2490 (the two display desktop size calculated for the system I was testing on); and without specifying the resolution (presumably the 1080p).

I couldn't tell any differences in any behaviors. (For one pass I thought I saw slightly better/crisper rendering with the default vs. the 2560x1440, but it wasn't enough to be convincing on a second pass...).

Since it seems to be performing about the same, I can't think of any reason to use any other default resolution.

One odd note, in one case when trying to use the 2560x2490 resolution the server did seem to hang/fail to start, though it worked every other time I tried that value... it's probably a coincidence, but it happened to fail at the same point (just after the server output line of 2016-05-19 18:19:59,271 GStreamer version 1.6 for Python 2.7) that both of the low-resource servers I was using to test in #1199 were failing. Since it wouldn't fail afterward though, I couldn't get any more logs to compare to see if it might be more of a coincidence.

In any case, this looks like it can be closed, passing it back to you in case there's something I missed in this perhaps too simple & cooperative of tickets.

comment:3 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

That will do.

comment:4 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: closedreopened

I'm seeing problems with resolutions higher than the default: the windows mapped at locations which were not in the original screen size cannot get pointer events. You first have to move them to a location within the original size then back to where they were.

comment:5 Changed 3 years ago by Antoine Martin

100% reproducible with:

xpra start --start="xterm -geometry 80x25+3000+500" 

The xterm is mapped when the screen is only set to 1080p... we connect at a higher resolution and re-map it in the same place, which isn't enough apparently.
I believe that this can also occur if we start the child command whilst we requested the initial 1080p resize.
We may have to re-configure some of the windows on startup and whenever the virtual screen size changes.

comment:6 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: reopenednew

Fixed in r13672 + r13673: we clamp the windows to the current desktop size, and apply clamping again when the resolution changes.
This should be race-free too since we listen for screen size changes before we register the list of windows.

@afarr: see comment:5, the xterm was not usable with the mouse before (ie: dragging to select text) when connecting with a 4K monitor, it is usable now.
It won't show up where requested on the xterm command line (3000,500) but clamped to the size of the screen it got mapped on (by default XPRA_DEFAULT_VFB_RESOLUTION=1920x1080).
And this will need to be backported...

comment:7 Changed 3 years ago by Antoine Martin

Fix in r13753: honour the "resize-display=no" flag and leave it as it is.

comment:8 Changed 3 years ago by alas

Resolution: fixed
Status: newclosed

Tested (building an r13670 1.0 server to compare against) with 1.0 r13786 fedora 23 server against a 1.0 r13673 win32 client.

Saw the issue with the old build, definitely fixed with the new... and --resize-display=no seems to be doing what I presume it should be doing (xterm doesn't seem to be moved nearly as far across my display when using the flag, with the fixed build... landing in what seems to be the same place with the new build as it did, non-interactively, with the older).

All looks well... closing another ticket (which also looks well).

Note: See TracTickets for help on using tickets.