xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 5 years ago

#715 closed enhancement (invalid)

Cursor in YouTube search bar causes elevated bandwidth usage

Reported by: Nick Centanni Owned by: Nick Centanni
Priority: minor Milestone:
Component: android Version: trunk
Keywords: Cc:

Description

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

Attachments (2)

encoding.log (259.9 KB) - added by Nick Centanni 6 years ago.
refresh.log (34.3 KB) - added by Nick Centanni 6 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to Nick Centanni

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.

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:2 in reply to:  1 Changed 6 years ago by 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?

Last edited 6 years ago by Antoine Martin (previous) (diff)

Changed 6 years ago by Nick Centanni

Attachment: encoding.log added

Changed 6 years ago by Nick Centanni

Attachment: refresh.log added

comment:3 in reply to:  1 Changed 6 years ago by 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.

comment:4 in reply to:  1 Changed 6 years ago by 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).

comment:5 Changed 6 years ago by Antoine Martin

Owner: changed from Nick Centanni to Antoine Martin
Priority: majorminor
Status: newassigned
Type: defectenhancement

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.

comment:6 Changed 6 years ago by Antoine Martin

#756 should help with this.

comment:7 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to Nick Centanni
Status: assignednew

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?

comment:8 Changed 5 years ago by Nick Centanni

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.