html5 client should honour paint flush order

[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.

[Antoine Martin]

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.

[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.

[Antoine Martin]

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

[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.

[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.

[Antoine Martin]

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.

[Antoine Martin]

Some changes related to the paint lock: r16441.

[migration script]

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