#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 )
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)
Change History (8)
comment:1 Changed 5 years ago by
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:2 Changed 5 years ago by
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 5 years ago by
Attachment: | html5-scroll-tmp-canvas.patch added |
---|
use a temporary canvas to avoid overlapping blitting - does not help
comment:3 Changed 5 years ago by
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.
comment:4 Changed 5 years ago by
comment:5 Changed 5 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1432
Keeping a simple queue of pending paint events would probably be enough:
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.