Xpra: Ticket #1754: present_fbo vsync delays sending paint acks
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
Fri, 26 Jan 2018 15:25:45 GMT - Antoine Martin: status changed
- status
changed from new to assigned
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
Fri, 26 Jan 2018 17:38:01 GMT - Antoine Martin: status changed; resolution set
- status
changed from assigned to closed
- resolution
set to fixed
Works well enough for now.
Sat, 23 Jan 2021 05:32:54 GMT - migration script:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1754