Xpra: Ticket #715: Cursor in YouTube search bar causes elevated bandwidth usage

Using nethogs to monitor bandwidth usage, and using epiphany to display the main page of YouTube -- with no video playing.

Placing the mouse cursor in the browser address bar causes a normal surge in bandwidth, that quickly calms down to less than 100KB. Placing the cursor in the search bar causes a surge to 1M or more, and the bandwidth does not subside.

Here is a grid of the various ways I tested the bug.

Client			Server			OpenGL	Encoding	Bug reproduced
------			------			------	--------	--------------
0.15.0 Windows 8.1 VM	0.14.7 Fedora 20 VM	no	jpeg		yes
0.15.0 Windows 8.1 VM	0.14.7 Fedora 20 VM	no	h264		no
0.14.7 Fedora 20 VM	0.14.7 Fedora 20 VM	no	jpeg		yes
0.14.9 Fedora 20 VM	0.14.9 Fedora 20 VM	no	jpeg		yes
0.14.9 Fedora 20 VM	0.14.9 Fedora 20 VM	no	h264		yes
0.14.9 Fedora 20 VM	0.14.9 Fedora 20 VM	yes	jpeg		client crashes - cannot test
0.14.9 Fedora 20 VM	0.14.9 Fedora 20 VM	yes	h264		yes (transparency issues, cursor doesn't display)
0.15.0 Fedora 20 VM	0.15.0 Fedora 20 VM	no	jpeg		yes
0.15.0 Fedora 20 VM	0.15.0 Fedora 20 VM	no	h264		yes
0.15.0 Fedora 20 VM	0.15.0 Fedora 20 VM	yes	jpeg		client crashes - cannot test
0.15.0 Fedora 20 VM	0.15.0 Fedora 20 VM	yes	h264		yes (transparency issues, cursor doesn't display)
0.14.9 Fedora 20	0.14.9 Fedora 20	no	jpeg		no
0.14.9 Fedora 20	0.14.9 Fedora 20	no	h264		no
0.14.9 Fedora 20	0.14.9 Fedora 20	yes	jpeg		no
0.14.9 Fedora 20	0.14.9 Fedora 20	yes	h264		no
0.15.0 Fedora 20	0.15.0 Fedora 20	no	jpeg		no
0.15.0 Fedora 20	0.15.0 Fedora 20	no	h264		no


Fri, 17 Oct 2014 06:05:55 GMT - Antoine Martin: owner changed

client crashes - cannot test


Please create a blocker ticket for this one.

Using nethogs to monitor bandwidth usage


BTW, does that match (more or less) the bandwidth information shown on session info?

Placing the cursor in the search bar causes a surge to 1M or more, and the bandwidth does not subside


Please provide -d encoding debug output so we can see what it is encoding. It could also be auto-refresh related, so -d refresh is also worth trying. And try to narrow it down by changing the encodings list and figuring out what is different between the Fedora 20 and the VM case. (which one matters: server or client?)

FWIW: I've briefly tried it, I had to use vglrun to be able to launch epiphany on my system, so it looks like it uses opengl for rendering to the vfb. No sign of the bug.


Fri, 17 Oct 2014 21:08:43 GMT - Nick Centanni:

client crashes - cannot test


Please create a blocker ticket for this one.


Blocker bug #717 has been created.

Using nethogs to monitor bandwidth usage


BTW, does that match (more or less) the bandwidth information shown on session info?


The "SENT KB/s" output of nethogs (monitoring the loopback interface) appears to match the average value shown in Session Info Graphs "recv KB/s" output. Does that sound correct?

However I did notice that the nethogs value is always about 500 or 600 KB/s higher in all cases, when the Session Info Graph window is open. Could the graph window itself be adding to the overall bandwidth?


Fri, 17 Oct 2014 21:24:01 GMT - Nick Centanni: attachment set


Fri, 17 Oct 2014 21:24:16 GMT - Nick Centanni: attachment set


Fri, 17 Oct 2014 21:29:48 GMT - Nick Centanni:

Placing the cursor in the search bar causes a surge to 1M or more, and the bandwidth does not subside


Please provide -d encoding debug output so we can see what it is encoding. It could also be auto-refresh related, so -d refresh is also worth trying.


The attached encoding.log captures the encoding filter, for a period of time from the top of the file down to about the 13:59:00 timestamp, where the cursor was in the search bar. The output after that point is all in the address bar.
I did notice that when the cursor is in the address bar, these logs stop after a while. But when the cursor is in the search bar, the logs just keep rolling and rolling.
The refresh.log captures a few seconds in the address bar, where the screen output is png or rgb32, then a good stretch of time in the search bar when the output changes to wepb, then a short period of time back in the address bar, at the end of the output.


Fri, 17 Oct 2014 22:48:21 GMT - Nick Centanni:

And try to narrow it down by changing the encodings list and figuring out what is different between the Fedora 20 and the VM case. (which one matters: server or client?)


The one thing I noticed between the full and VM versions of Fedora, is that on the VM, the encodings in the refresh output show that png is used while in the address bar, and changes to webp in the search bar. At least when I captured the log that was the case. The next time I tried it, using the same encodings list, it was always png, regardless of the position of the cursor.

But in full Fedora where the bug can't be reproduced, webp is used when the cursor is in the address bar, and rgb32 is used in the search bar.
One other possible clue, is that on the machine where I could repro the bug, the bandwidth increase occurs when the cursor is blinking, but if I put text in the search bar then select the text, the bandwidth goes down (possibly because selecting text causes the blinking cursor to disappear).


Sun, 19 Oct 2014 16:45:57 GMT - Antoine Martin: owner, priority, status, type changed

The "SENT KB/s" output of nethogs (monitoring the loopback interface) appears to match the average value shown in Session Info Graphs "recv KB/s" output. Does that sound correct?


Yes.

However I did notice that the nethogs value is always about 500 or 600 KB/s higher in all cases, when the Session Info Graph window is open. Could the graph window itself be adding to the overall bandwidth?


Yes it does. It requests information from the server, which uses more bandwidth. It could be trimmed a little I suppose.


Now, from the log I am reading, it looks like epiphany is repainting most of the window 4 times per second, in pairs of events about 40ms apart:

damage(0, 45, 748, 312, {}) wid=3, sending now with sequence 8794

That's a pretty big update: 748x312 pixels, especially if the window contents haven't actually changed. There isn't much we can do to prevent applications from telling us to repaint when it isn't needed. I guess that what we could do is raise the maximum size used for delta compression. As doing a delta between those unchanged screen updates should give us an empty result, which we can either skip (would require some new code to detect) or just send empty (as it will compress extremely well).

A better solution would be to fix epiphany so it doesn't repaint when it isn't needed.

I am lowering the priority of this ticket and changing it to an enhancement, because it doesn't look like a bug on our side. Maybe just a sub-optimal automatic encoding selection for a corner case.


Thu, 04 Dec 2014 17:27:42 GMT - Antoine Martin:

#756 should help with this.


Tue, 09 Dec 2014 04:01:56 GMT - Antoine Martin: owner, status changed

Can you reduce the bandwidth by using:

XPRA_MAX_DELTA_SIZE=4000000 xpra start

We could raise the default (10000), or make it more dynamic so we only allow large deltas when the framerate is low (framerate being a difficult value to extract... video regions and all)

Unless we're sending updates that aren't coming as damage events from the application, maybe we should just close this ticket as invalid and follow up in #756. Thoughts?


Tue, 09 Dec 2014 21:59:30 GMT - Nick Centanni: status changed; resolution set

My latest attempt to reproduce this bug, using the same conditions as the test case 4 and 5 from the table at the head of this ticket, was unsuccessful. Either YouTube? has changed, or we have, or it's intermittent.

I'm closing this until further notice.


Sat, 23 Jan 2021 05:03:50 GMT - migration script:

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