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)
Short term, the solution is probably #976
enables the largest resolutions possible with the current dummy driver
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.
fix for the dummy driver to honour DacSpeed?
Tested on Fedora 22. Will push to stable later, maybe if/when I hear back from xorg-devel.
The patch has been merged upstream: http://cgit.freedesktop.org/xorg/driver/xf86-video-dummy/commit/?id=29433844c8b8989ea2ac64bd92b3ad61b6f9cf10
libyuv supports scaling beyond 32kx32k! (see #973)
Milestone renamed
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/969