xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 5 years ago

Closed 4 years ago

Last modified 16 months ago

#1592 closed task (fixed)

Browser and Xterm scroll test data

Reported by: J. Max Mena Owned by: J. Max Mena
Priority: major Milestone: 2.1
Component: tests Version: 2.1.x
Keywords: tests Cc: afarr@…


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.

Attachments (1)

simulate_browser.py (2.3 KB) - added by J. Max Mena 5 years ago.
The python file referenced in the config files

Download all attachments as: .zip

Change History (6)

Changed 5 years ago by J. Max Mena

Attachment: simulate_browser.py added

The python file referenced in the config files

comment:1 Changed 4 years ago by Antoine Martin

Milestone: never2.1
Owner: changed from Antoine Martin to J. Max Mena

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.

comment:2 Changed 4 years ago by J. Max Mena

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.

comment:3 Changed 4 years ago by J. Max Mena


comment:4 Changed 4 years ago by J. Max Mena

Resolution: fixed
Status: newclosed

comment:5 Changed 16 months ago by migration script

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

Note: See TracTickets for help on using tickets.