Xpra: Ticket #969: dealing with very large client screen sizes

Related to #948 and #942.

We are already hitting the limits of some encoders easily enough (around 4k for most, including nvenc). In other cases, we exhaust the RAM before we can complete the selftests... (vp9 at 8kx8k). Some client's opengl drivers are limited to 4k too (#942).

Most of the code already assumes that the screen size is no bigger than 8k in width. By default, the vfb max size is just 8k x 4k:

DUMMY(0): Not using mode "16384x8192" (insufficient memory for mode)

But 4k screens are cheap and becoming commonplace, so sooner or later we will have to deal with 8k screens or bigger!

The next big limit is going to be 32768 because window dimensions are stored as signed shorts in many places... And this one will be very very difficult to overcome.

One way of dealing with this is to just use the max-size switch (see #263). I don't think we can deal with sizes bigger than 4k without hardware encoding (at least not when dealing video-like content).

See also #33 (could implement some scaling)



Fri, 04 Sep 2015 07:56:44 GMT - Antoine Martin: status changed

Short term, the solution is probably #976


Fri, 11 Sep 2015 13:25:15 GMT - Antoine Martin: attachment set

enables the largest resolutions possible with the current dummy driver


Fri, 11 Sep 2015 13:55:16 GMT - Antoine Martin: milestone changed

Testing with the patch above and the scaling code from #976, the current limit that I am hitting is 16000x15000 due to the hardcoded pixel max clock in the dummy driver:

    clockRanges->maxClock = 300000;

This code looks buggy too: it sets the maxClock local variable but doesn't use it... So I patched it to allow new crazy large resolutions with no side effects (will push upstream).

The good news is that everything worked nicely in xpra. I upscaled the client's 5760x2160 display:

$ XPRA_X_SCALING=0.3 XPRA_Y_SCALING=0.11 xpra attach
Warning: the desktop size is extremely large: 19200x19636

Moved the windows to the bottom right corner and everything still worked as expected! It gets a bit slow at these sizes, which is to be expected.

So there does not seem to be any problems going above 16k+, at least not with the regular test applications and toolkits (your mileage may vary with dodgy proprietary applications..) There will certainly be problems going above 32k..

But we have time to think about this, and until then we can just scale things which also gives us much better performance.


Fri, 11 Sep 2015 14:15:56 GMT - Antoine Martin: attachment set

fix for the dummy driver to honour DacSpeed?


Fri, 11 Sep 2015 14:39:59 GMT - Antoine Martin:

Tested on Fedora 22. Will push to stable later, maybe if/when I hear back from xorg-devel.


Thu, 17 Sep 2015 15:20:51 GMT - Antoine Martin:

The patch has been merged upstream: http://cgit.freedesktop.org/xorg/driver/xf86-video-dummy/commit/?id=29433844c8b8989ea2ac64bd92b3ad61b6f9cf10


Mon, 11 Jan 2016 13:40:06 GMT - Antoine Martin:

libyuv supports scaling beyond 32kx32k! (see #973)


Wed, 28 Mar 2018 06:05:13 GMT - Antoine Martin: milestone changed


Wed, 20 Mar 2019 05:05:33 GMT - Antoine Martin: milestone changed

Milestone renamed


Sat, 23 Jan 2021 05:11:11 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/969