Compressing video can be expensive, especially at high-res, let's provide a way to cap this CPU cost by forcing video the be down-scaled to a size that doesn't place too high a burden on the server.
This will also help maintain a decent framerate with HTML5 clients where the decoding is often CPU-bound.
Done in r19591:
The server will then choose a scaling value which makes the video smaller than the "video-max-size".
client.window.2.scaling=(1, 2) client.window.2.supports_video_scaling=True client.window.2.video-max-size=(1024, 768)
(the scaling values are integer ratios, ie: 1/2, 2/3, etc)
@maxmylyn: this may help with your CPU constraints if you also enable h264 decoding. (#1839) You may also want to raise min-speed. This will use more bandwidth and less CPU time.
Running a Fedora 28 trunk r19621 server:
I'm getting this traceback serverside when attaching via an HTML5 client:
2018-06-12 13:03:15,892 listget('video_max_size', (8192, 8192), <type 'int'>, None) None 2018-06-12 13:03:15,892 expected a list or tuple value for video_max_size but got <type 'int'>
I'm assuming it's related to this ticket since it's printing about video maximum size.
I'm getting this traceback serverside when attaching via an HTML5 client:
I cannot reproduce. Make sure that the HTML5 client you use is up to date, hit shift+reload if necessary. If you can still reproduce it, please attach the server's "-d server" log output.
The current version clearly has a pair of ints as value: browser/xpra/trunk/src/html5/js/Client.js.
Never mind, I hit it (no idea why I didn't before - I still despise Javascript too much to care), fixed in r19624.
See also #1951
Okay that solved it.
Closing
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1867