Keith Packard writes:
> I got started creating a 'semi-automatic compositing' design where the
> compositing manager could tell the X server "Hey, just composite this
> window to the screen in the 'obvious' way and don't bother me with the
> details".
Wouldn't that just be RedirectWindow with
Po Lu writes:
> Does that make any sense? I'm thinking of a control flow that looks
> like this, when the client draws to the window after a pixmap has been
> presented by the compositor:
>
> Client Server Compositing manager
> PresentPixmap >
Michel Dänzer writes:
> I'm thinking of this kind of scenario with a direct rendering compositor:
>
> 1. Compositor retrieves window pixmap, creates OpenGL texture object for it.
> 2. Client sends PresentPixmap request, which results in replacing the window
> pixmap.
> 3. Client starts drawing
On 2022-10-18 16:14, Po Lu wrote:
> Michel Dänzer writes:
>
>> The problem with this is that there's no explicit transfer of
>> ownership of the window pixmap between the compositor and other
>> entities. So the compositor may end up reading from a stale window
>> pixmap after another
Michel Dänzer writes:
> You don't need to do anything special. The effect of PresentPixmap is
> essentially the same as XCopyArea as far as the destination window
> contents are concerned, regardless of how the presentation is
> effectively performed.
Thanks.
> The problem with this is that
On 2022-10-07 09:09, Po Lu wrote:
>
> The documentation for PresentPixmap says:
>
> If 'options' contains PresentOptionAsync, and the 'target-msc'
> is less than or equal to the current msc for 'window', then
> the operation will be performed as soon as possible, not
>
Hello. I have recently been working on a Wayland compositor that runs
on X, and have several questions about the presentation extension.
My compositor utilizes XRender for compositing subsurfaces with the
contents of a toplevel window, and _NET_WM_SYNC_REQUEST to handle frame
synchronization.
