Opened 5 years ago
Closed 4 years ago
#792 closed enhancement (fixed)
paint everything together with opengl
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | minor | Milestone: | 0.16 |
Component: | client | Version: | trunk |
Keywords: | Cc: |
Description
Instead of doing the video screen update, followed by the rgb paint for the 1 pixel bottom and right edges, we could either bundle them together (as an array of updates?), or at least pass a flag that implies "present" so that we update the back buffer and only when everything is updated we present it on screen with a single swap-buffers.
Somewhat related to other opengl improvements, see #679.
Change History (5)
comment:1 Changed 5 years ago by
Owner: | changed from Antoine Martin to Antoine Martin |
---|---|
Status: | new → assigned |
Summary: | paint thing together with opengl → paint everything together with opengl |
comment:2 Changed 4 years ago by
Milestone: | future → 0.16 |
---|
comment:3 Changed 4 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
Done in r9846.
As per the commit message, this affects:
- regions batched up together (happens regularly)
- edges of video encoders (which are usually limited to even dimensions, so we send the edge separately using rgb)
We now send a flag to the client so it will delay updating the screen until all the screen updates have been received. (flush=0 or unset)
This is what it looks like with -d opengl
:
- a normal paint (without delayed flush)
present_fbo: adding (155, 756, 6, 13) to pending paint list, flush=0 do_present_fbo: painting [(155, 756, 6, 13)]
- a group of delayed paints:
present_fbo: adding (17, 197, 90, 13) to pending paint list, flush=9 present_fbo: adding (107, 197, 24, 13) to pending paint list, flush=8 present_fbo: adding (155, 756, 6, 13) to pending paint list, flush=7 present_fbo: adding (17, 210, 240, 13) to pending paint list, flush=6 present_fbo: adding (131, 197, 852, 13) to pending paint list, flush=5 present_fbo: adding (17, 171, 966, 13) to pending paint list, flush=4 present_fbo: adding (17, 158, 966, 13) to pending paint list, flush=3 present_fbo: adding (17, 184, 48, 13) to pending paint list, flush=2 present_fbo: adding (65, 184, 918, 13) to pending paint list, flush=1 present_fbo: adding (509, 145, 474, 13) to pending paint list, flush=0 do_present_fbo: painting [(17, 197, 90, 13), (107, 197, 24, 13), (155, 756, 6, 13), (17, 210, 240, 13), (131, 197, 852, 13), (17, 171, 966, 13), (17, 158, 966, 13), (17, 184, 48, 13), (65, 184, 918, 13), (509, 145, 474, 13)]
Notable difference: on win32, we use double buffering and so the painting will just paint the whole window (a single region will be shown).
Hopefully, this will reduce CPU load on the client (I guess this could be done in #797), and give us smoother repaints, and maybe even a higher refresh rate.
@afarr: mostly a FYI, I can't think of anything specific to test. Maybe just verify the present_fbo
debug output matches expectations.
comment:4 Changed 4 years ago by
Owner: | changed from alas to Antoine Martin |
---|
Tested with 0.16.0 r10624 windows and osx clients against 0.16.0 r10624 fedora 21 client.
I'm seeing the present_fbo
output as expected. It is nearly always doing normal paints (always in my short test on windows client), but I saw some of the delayed paints on OSX (with messages in between about gtk2 window backing stats and notifications of switching to RGB paint state in between a flush=2 and a flush=1 and a flush=0).
I'm assuming that is expected, and handing this back to you to close. If that sounds unexpected let me know and I'll collect some logs.
comment:5 Changed 4 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
@afarr: you should be able to reproduce more easily on win32:
- with an odd sized window and video, which is probably what you were seeing on osx: flush=2 will be a large video yuv paint, followed by flush=1 and flush=0 as rgb
- with rgb encoding and lots of activity on screen
- with
XPRA_BATCH_MIN_DELAY=50 XPRA_BATCH_ALWAYS=1
with r10625 onwards, this caps the framerate at 20 fps and forces paint batching
Will follow up in #981, so closing here.
I want to get this in 0.16, at the very least for the "easy" case of 1 pixel edge windows. If we ever get vsync frames on the server (#386 - maybe as part of wayland #387), then this will take care of the client side.
We should be able to add an extra optional flag called "flush", which would default to True when not present (older servers, or for the normal path).
When we process multiple regions (1 pixel case, or as part of the same set of batched screen updates), we can set the flag on all but the last paint packet.
Client-side, we can just accumulate the rectangles in
present_fbo
and only process them when we flush.