Video Region Tearing With Video Controls

[totaam]

Issue migrated from trac ticket # 1218

component: client | priority: critical | resolution: fixed

2016-06-03 19:42:43: maxmylyn created the issue

---

We've been talking about this one a bit recently, and we've gathered all necessary data to finally open a ticket.

The repro is fairly straightforward:

• Start up a session with Google Chrome

• Connect to the session with XPRA_OPENGL_PAINT_BOX=1 enabled optionally, does help to visualize what's going on
• Navigate to a YouTube video of your choice.
• Start playing the video.
• Once the heuristics have calmed down a bit, start mousing over the video and other items on the page.

Outcome:

The video starts getting tearing due a partial repaint over the h264 region.

---

I'll attach a screenshot, a short video, and the requested Xpra Info.

---

Also, I'm marking this as client, but I'm not sure if that's where the issue is lying. All of this was done with latest trunk r12735 on Fedora 23 (both machines) 64-bit.

[totaam]

2016-06-03 19:43:20: maxmylyn uploaded file 1218xprainfo.txt (141.9 KiB)

Requested Xpra info

[totaam]

2016-06-03 19:45:49: maxmylyn uploaded file 1218 Video tearing Chrome.mp4 (4286.8 KiB)

A quick video documenting what we're seeing

[totaam]

2016-06-03 19:46:19: maxmylyn uploaded file 1218 Tearing SS.png (358.0 KiB)

A screenshot depicting the partial painting over the video region

[totaam]

2016-06-03 19:46:45: maxmylyn changed title from Video Region Tearing With YouTube Controls to Video Region Tearing With Video Controls

[totaam]

2016-06-03 19:46:45: maxmylyn commented

---

(update title, we see this in a few spots, but YouTube is the easiest to repro with Chrome)

[totaam]

2016-06-05 07:46:44: antoine changed owner from antoine to maxmylyn

[totaam]

2016-06-05 07:46:44: antoine commented

---

Found the bugs: if we are processing the video frames sufficiently fast, the window damage events for the other bits (widgets, progress bar, etc) may arrive whilst there are no video damage events queued up, we then decide that the update is not video as it is not worth sending the whole area as video since it is only a small portion of it.

There were actually two bugs here, both fixed by r12744. This will be backported.

Note: this is going to be worse when we have av-sync on. The widgets will now get repainted with the video, which is delayed for av-sync.. And if they only partially overlap the video, only half will be delayed.

PS: r12740 is another bug somewhat related that needs to be backported. And maybe also r12758.

[totaam]

2016-06-06 17:38:46: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2016-06-06 17:38:46: maxmylyn commented

---

Upped my client and server to r12754:

I am now seeing some really peculiar painting issues while using Firefox. When typing or highlighting text, nothing appears to update until I scroll within the webpage. It's like it's not partially repainting properly. I assume it's because of the fixes for this ticket. I'll attach a quick recording to demonstrate.

But, I no longer see the region tearing with video controls.

---

Of course, if it's unrelated to this, it can go into a new ticket.

[totaam]

2016-06-06 17:42:06: maxmylyn commented

---

Of note:

I also see this issue in Chrome. Playing a video seems to avoid the issue entirely.

[totaam]

2016-06-07 06:28:56: antoine changed owner from antoine to maxmylyn

[totaam]

2016-06-07 06:28:56: antoine commented

---

I have tested this on my dev box, then built new beta packages then tested in all the Fedora vms that I have and I cannot reproduce this problem at all.
Are you sure that this is caused by this changeset? Have you tried any other versions to compare?

I can only guess that you are doing something different than I am. Having xpra info or at the very least, the command lines you've used would help. Maybe you're enabling opengl on a buggy chipset? If that's the case, it could help us fix it as the effects seem quite dramatic. (new ticket, please include opengl paint boxes, opengl debug, etc)

[totaam]

2016-06-07 18:00:22: maxmylyn changed status from new to closed

[totaam]

2016-06-07 18:00:22: maxmylyn set resolution to fixed

[totaam]

2016-06-07 18:00:22: maxmylyn commented

---

Maybe you're enabling opengl on a buggy chipset?

[[br]]

Oddly enough I'm getting it with OpenGL off as well. Either way, this machine has an Nvidia 745, so OpenGL shouldn't be a problem. Well...maybe. It is Nvidia after all....

[[br]]

---

Server start commands:

xpra start :13 --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm --start-child="xterm -bg black -cr white -fg white" --start-child="xterm -bg black -cr white -fg white"

Client attach:

xpra attach tcp:ip:port

So nothing special, really. Just a TCP server with a couple Xterms.

---

Either way the issues I'm seeing for this ticket are resolved, so since you can't repro what I'm seeing now, I'll go ahead and close this one (again, video controls no longer tear video) and file a new one after some further investigation.

[totaam]

2016-06-07 19:13:10: bspikes commented

---

I've been unable to reproduce Max's issue.. I think what he saw might be unrelated to this fix.

[totaam]

2016-06-09 06:49:21: antoine commented

---

The paint issue is now tracked in #1225 and may have been caused by r12754: we may not refresh parts of the window in the video region exclusion zone if the "video" stops.

[totaam]

2016-06-09 12:55:57: antoine uploaded file track-nonvideo.patch (8.6 KiB)

when we exclude non-video regions from the window paint, make sure they eventually get refreshed too

[totaam]

2016-06-09 12:57:40: antoine changed status from closed to reopened

[totaam]

2016-06-09 12:57:40: antoine removed resolution (was fixed)

[totaam]

2016-06-09 12:57:40: antoine commented

---

There may be a region leak now, caused by r12744.
The patch above should fix it, but I don't really like it as it is too intrusive and may also make it much more difficult to implement #981.

[totaam]

2016-06-10 12:46:40: antoine changed priority from major to critical

[totaam]

2016-06-10 12:46:40: antoine commented

---

r12776 (+ optional r12777 and r12780 fixup) is the more correct fix (details in commit message) - also more complicated.

Please confirm that the original bug is still fixed and that the regression in #1225 is also gone.

[totaam]

2016-06-10 20:33:53: maxmylyn changed status from reopened to closed

[totaam]

2016-06-10 20:33:53: maxmylyn set resolution to fixed

[totaam]

2016-06-10 20:33:53: maxmylyn commented

---

• Upped server and client to r12780:

• I can't reproduce the issues I found in the description, so it looks like this is still fixed

• And, I cannot induce the issues I found with Paint issues on latest trunk #1225 after some very thorough testing

re-closing this ticket as fixed.

[totaam]

2016-07-12 17:52:23: antoine commented

---

Milestone renamed