Xpra: Ticket #792: paint everything together with opengl

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.

Sat, 24 Jan 2015 07:15:12 GMT - Antoine Martin: owner, status, summary changed

Fri, 03 Jul 2015 15:38:13 GMT - Antoine Martin: milestone changed

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.

Mon, 06 Jul 2015 10:59:29 GMT - Antoine Martin: owner, status changed

Done in r9846.

As per the commit message, this affects:

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:

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.

Sat, 12 Sep 2015 01:44:04 GMT - alas: owner changed

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.

Sat, 12 Sep 2015 08:05:37 GMT - Antoine Martin: status changed; resolution set

@afarr: you should be able to reproduce more easily on win32:

Will follow up in #981, so closing here.

Sat, 23 Jan 2021 05:06:06 GMT - migration script:

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