Xpra: Ticket #692: allow better control over automatic scaling

We have the ability of setting the scaling value via xpra control (see #461). But this is too coarse and completely bypasses the heuristics we have for deciding when to downscale and by how much.

We should make it easier to tune the heuristics, as this is more likely to allow us to improve the default behaviour.

Thu, 25 Sep 2014 03:40:43 GMT - Antoine Martin: owner changed

Done in r7800 + r7801: we still enable scaling when there is no other choice (when the window is too big for the encoder).

This adds the --scaling= command line option and corresponding config file option. The control interface has also been added, so now we have (both commands can apply to all windows or to specific window ids):

Ready for testing: using scaling=off should prevent scaling from kicking in, while scaling=100 should enable it more aggressively, scaling==on should be more or less the same as the default before. Note: until #693 is fixed, testing should be done without opengl, or with older versions (0.14.x is fine AFAICT).

Fri, 03 Oct 2014 00:39:09 GMT - alas:

Testing with 0.15.0 r 7865 windows client (windows 8.1) against 0.15.0 r 7865 server (fedora 20)

Didn't test the --control= and config file option.

[jimador@zapopan ~]$ xpra control :23 scaling-control 100 3
server returned error code 127
error processing command: local variable 'set_scaling' referenced before assignment

Fri, 03 Oct 2014 04:58:43 GMT - Antoine Martin:

Didn't test the --control= and config file option.

Good, because there isn't one! It was a mistake, I've edited the comment, the command line and config option is actually called scaling.

The scaling-control override, on the other hand, seems to be throwing an error

That's another mistake! Fixed in r7868.

but only with --opengl=off (..) With opengl=on I don't see any difference no matter what I do with the scaling.

I am checking visually (text becomes blurry) and with xpra info:

xpra info | grep \.scaling=

You can also use -d scaling on the server.

I think that what may happening is that the non-opengl client is so much slower that the scaling kicks in earlier to try to speed things up a bit.

You need to make the window bigger. I've used glxspheres to generate a high framerate window of varying size.

Fri, 03 Oct 2014 18:48:20 GMT - alas:

(Will have to wait to confirm r7868 fix, and will also test OSX rather quickly to be thorough.)

Mon, 06 Oct 2014 22:21:03 GMT - alas:

Testing with OSX (10.9) client, 0.15.0 r7897, vs. 0.15.0 r7897 server (Fedora 20).

Works as expected, with opengl=on or off... both the command-line setting of scaling and the control channel scaling_control settings and scaling ratio settings (except where scaling_control=0, in which case ratios are always 1:1, which I assume is also expected).

Mon, 06 Oct 2014 23:50:18 GMT - alas: owner changed

Testing with win32 client 0.15.0 r7897 (windows 8.1).

Confirmed - xpra control :DISPLAY scale-control V [window ids] works as expected.

This looks ready to be closed.

Tue, 07 Oct 2014 02:40:29 GMT - Antoine Martin: status changed; resolution set

Sat, 23 Jan 2021 05:03:09 GMT - migration script:

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