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.
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).
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.
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?)
[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.
opengl=on I don't see any difference no matter what I do with the scaling.
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(..) Withopengl=onI 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.
-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.)
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).
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/692