dealing with very large client screen sizes

[totaam]

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)

[totaam]

Short term, the solution is probably #976

[totaam]

2015-09-11 14:25:15: antoine uploaded file enable-16kx15k.patch (2.1 KiB)

enables the largest resolutions possible with the current dummy driver

[totaam]

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.

[totaam]

2015-09-11 15:15:57: antoine uploaded file dummy-dac-fix.patch (0.8 KiB)

fix for the dummy driver to honour DacSpeed

[totaam]

• dummy patch submitted upstream: dummy driver obvious DacSpeed fix
• added to our dummy RPM builds in r10620
• beta builds available: [http://xpra.org/beta]

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

[totaam]

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

[totaam]

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

[totaam]

See also #2714 (comment) (Firefox large windows)

[totaam]

This is no longer a problem for distributions using Xdummy, that is, anything except Debian based distros which should be avoided.