This ticket is just a place where I can dump the .CSVs and .log files from when I ran a series of tests a few weeks ago.
In no particular order here are the .tars I made:
configs.tar includes all of my config files I ran with. The
config_just_xterm narrows down the tests to just the terminal tests,
config_scrolling_whatever files are the ones where I narrowed down the tests to just the simulate_console_user tests (which usually just failed, not sure why) and the xterm test that just does
dmesg over and over again. In a few of the tests with that last config file I modified the xterm command print to spew out some text from lorum ipsum to get something more guaranteed to use the scrolling codec. Of interest is the
config_browser config file - sorry for hardcoding directories but I was lazy. That config file is the one I ran with (with some minor modifications) for the majority of the browser tests.
xterm_data.tar is the .CSV and .log output of the xterm tests, and
browser_data.tar is the browser data. Generally I tried to keep to the
testName_numRuns_XpraVersion rule, but not always. For tests with the scrolling encoding disabled, I usually appended
no_scroll_encoding or something like that.
And last but not least, I'll attach the Python file I wrote to scroll a Chrome window. It's not quite done yet (need to add an option for Firefox, too), but for the most part is good enough if someone else wants to run the tests on their own machine.
NOTE: The browser test is very taxing on machines - two of my test machines weren't powerful enough to run the tests and get meaningful data. I found that anything below an Intel i5 generally isn't powerful enough to run this test. Also, your test machine needs to have working OpenGL on both server and client-side. I found that the Intel iGPU didn't work on my machine, but the Nvidia ones worked (even super low end cards) without any noticeable issues.
The python file referenced in the config files
Tickets are not a good place to dump raw data. Results and analysis yes, not big binary files. Please delete those heavy files after doing a summary.
Here's a quick summary I wrote in an email way back when:
The new scroll encoding does not appear to use significantly more or less bandwidth than the previous method of sending large amounts of updates. However, it does use the same amount of bandwidth far more efficiently, allowing users to perceive a much clearer and better performing experience than before. In essence, we aren't saving bandwidth, but rather using it far more efficiently - allowing us to send far higher quality updates using the same amount of bandwidth as before.
That being said, my testing steps were very straightforward and reproducible. I added a new test to the already existing Xpra performance tests that launches a Chrome or Chromium window (can be set by an environment variable) that launches in Kiosk mode - essentially launching the website full-screen. The website it launches can also be set by an environment variable. Once the website loads, it proceeds to scroll down and up endlessly at a speed that can be changed by modifying the config file, and for a duration in each direction that can also be changed by modifying the config file. The default is 20 scroll events, with a 10ms pause between scroll events. This makes the browser window scroll down then back up pretty quickly - notably faster than one would be able to read a webpage.
If anyone would like to have the raw data, they'll have to get ahold of me so I can give it to them - I'll keep the tars on hand.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1592