allow better control over automatic scaling

[Antoine Martin]

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.

[Antoine Martin]

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):

• xpra control :DISPLAY scale N:M [window ids] to set the scaling to a specific value
• xpra control :DISPLAY scale-control V [window ids] to override the command line "scaling" option

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).

[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.

• The control channel (xpra control :DISPLAY scaling N:M [window ids]) seems to be working as expected to adjust scaling, but only with --opengl=off (I guess that's what #693 meant when it said it has to paint the screen in unscaled dimensions?)

• The scaling-control override, on the other hand, seems to be throwing an error (or I'm getting the syntax wrong):

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

• Scaling=off displays very clearly, while scaling=100 is definitely aggressive about trying to scale (blurry text ensues), both as I'd expect.

• With opengl=on I don't see any difference no matter what I do with the scaling.

[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.

[alas]

• Testing again with -d scaling server-side and --opengl=on client-side... yes, I can see that the scaling=off sets scaling at 0, setting to other values is working, and the control channel changes on the fly are working as expected. (& using a higher framerate window makes it easier to confirm visually as well.)

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

[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).

[alas]

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.

[migration script]

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