#1754 closed defect (fixed)
present_fbo vsync delays sending paint acks
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 2.3 |
Component: | core | Version: | 2.2.x |
Keywords: | Cc: |
Description
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
Change History (3)
comment:1 Changed 3 years ago by
Status: | new → assigned |
---|
comment:2 Changed 3 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Works well enough for now.
comment:3 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1754
Note: See
TracTickets for help on using
tickets.
Updates:
vsync ticket: #386