xpra icon
Bug tracker and wiki

Opened 2 years ago

Last modified 22 months ago

#969 assigned enhancement

dealing with very large client screen sizes

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: future
Component: encodings Version: 0.15.x
Keywords: Cc:

Description

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)

Attachments (2)

enable-16kx15k.patch (2.1 KB) - added by Antoine Martin 2 years ago.
enables the largest resolutions possible with the current dummy driver
dummy-dac-fix.patch (831 bytes) - added by Antoine Martin 2 years ago.
fix for the dummy driver to honour DacSpeed?

Download all attachments as: .zip

Change History (7)

comment:1 Changed 2 years ago by Antoine Martin

Status: newassigned

Short term, the solution is probably #976

Changed 2 years ago by Antoine Martin

Attachment: enable-16kx15k.patch added

enables the largest resolutions possible with the current dummy driver

comment:2 Changed 2 years ago by Antoine Martin

Milestone: 1.0future

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.

Changed 2 years ago by Antoine Martin

Attachment: dummy-dac-fix.patch added

fix for the dummy driver to honour DacSpeed?

comment:3 Changed 2 years ago by Antoine Martin

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

comment:5 Changed 22 months ago by Antoine Martin

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

Note: See TracTickets for help on using tickets.