xpra icon
Bug tracker and wiki

Opened 7 months ago

Closed 6 months ago

Last modified 2 months ago

#1432 closed defect (fixed)

html5 client should honour paint flush order

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 2.0
Component: html5 Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

Split from #1426. Maybe scrolling should be disabled in v1.x html5 clients, otherwise they will show display corruption when connecting to v2.x servers that provide the "scroll" encoding. (v1.x servers require video - which is not enabled by default)

The "flush" screen update attribute can be used as some kind of barrier: we can decode and paint the updates in parallel as they come in, but we should not start decoding a new group of screen updates until the current group has made it to the canvas. (this is only per-window, and there are no constraints on the paint ordering of screen updates within the same flush group)

Ideally, we could start decoding the new screen updates, but just avoid updating the canvas. But that's likely to be much more difficult to implement.

Attachments (1)

html5-scroll-tmp-canvas.patch (1.3 KB) - added by Antoine Martin 7 months ago.
use a temporary canvas to avoid overlapping blitting - does not help

Download all attachments as: .zip

Change History (7)

comment:1 Changed 7 months ago by Antoine Martin

Description: modified (diff)
Status: newassigned

Keeping a simple queue of pending paint events would probably be enough:

  • add to the queue instead of actually painting whenever we have pending paints
  • process all elements in that queue (play catch up) when we have processed all the paint events for a given flush group

We just keep track of the pending flush numbers in an associative array.
A flush value of 0 (or undefined) indicates the end of the current group. Or another way: if the flush value increases, we are receiving the start of a new paint group. At that point, we cannot add new entries to the associative array until it is empty.

comment:2 Changed 7 months ago by Antoine Martin

Done in r15139 using a simple queue. Sadly, the scroll paints still look a bit off.

Note: we could do something more fancy where we decode more than all the draw commands as they come in and only synchronize the actual updating of the offscreen canvas. But seeing how quickly things get decoded, this doesn't look like it is worth the effort.

Changed 7 months ago by Antoine Martin

use a temporary canvas to avoid overlapping blitting - does not help

comment:3 Changed 7 months ago by Antoine Martin

I've seen similar visual corruption with the python client... so maybe the scrolling paint code is fine and we're just sending the wrong instructions.
The python client just auto-refreshes it quickly so we don't see it as much.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 6 months ago by Antoine Martin

The visual corruption with scrolling has been fixed in r15235 (r15236 for v1.0.x branch), but the html5 client still shows artifacts.

comment:5 Changed 6 months ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

The bug was in the scroll paint code, fixed in r15275 (backport in r15277)

The flush paint order is being honoured and the picture is now fine.

comment:6 Changed 2 months ago by Antoine Martin

Some changes related to the paint lock: r16441.

Note: See TracTickets for help on using tickets.