present_fbo vsync delays sending paint acks

[Antoine Martin]

Discovered as part of #999 / #1688: with double-buffering, present_fbo / gl_show will wait for vsync when swapping the buffers, which means that we will only send the paint ack after up to ~17ms on a 60Hz display.
If we send a number of consecutive flushed paints, they can often be decoded very quickly but the actual screen update will be rate limited by the vsync...
This makes it look like we have bandwidth problems when in fact it's just bad scheduling of screen updates.

Potential solutions:

• rate limit the sending of damage packet groups: hard, because the batch delay fluctuates a lot - maybe we can ensure that we always wait at least 1/vsync? (also we only want this rate limit when sending a fair number of screen updates - punctual ones don't need to wait..)
• send the acks before the vsync: the rate limiting would still be there, not sure this would help at all
• allow new paints to update the fbo: can't be done since we need the UI thread to access the context, used by the swap buffers

[Antoine Martin]

Updates:

• r18167 + r18168: fixed bugs in the python3 version which were making things worse by triggering a flush with every paint
• r18171: fire paint callbacks before present_fbo so the decode time reported is correct (does not include the vsync buffer swap time)
• r18172: try harder to send screen updates at the same rate as the client's vertical refresh rate (if we have it, otherwise 60Hz)

vsync ticket: #386

[Antoine Martin]

Works well enough for now.

[migration script]

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