Questions about XPresent

[Michel Dänzer]

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
> 	necessarily waiting for the next vertical blank interval.
> 
> What does the "necessarily" here mean?  That the presentation might
> still wait for vblank, even if PresentOptionAsync is specified, and the
> target MSC is less than the MSC of the window?

I think so.

However, AFAICT the xserver Present code will always execute the presentation ASAP in this case, never wait for vblank first.


> What will a following SyncSetCounter do?  Will the counter always be set
> to the new value after the presentation happens and the window damage is
> sent to the compositor?

You mean if the presentation waited for vblank first? If so, I don't see any such implicit synchronization between PresentPixmap and SyncSetCounter (or any other request).


> My second question is about drawing to the window after presentation
> happens.  When direct presentation becomes impossible (by, for example,
> the Wayland client attaching a subsurface), then the results of any
> previously made presentation must be overwritten by the following
> Composite requests.  What happens if a Composite request is made,
> targeting a window whose contents have been previously specified with
> PresentPixmap, especially if the pixmap has been flipped and not copied?
> 
> Do I have to present an empty pixmap, wait for any PresentIdleNotify
> for the previously attached pixmap, or what?

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.


> That brings me to the third question.  Wouldn't a good optimization be
> to "flip" the presented pixmap, if possible, into the contents of the
> window pixmap if the window were to be redirected?  Compositing managers
> would then be able to read from the window immediately after
> presentation, without needing the contents of the presented pixmap to be
> copied to the window pixmap first.

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 presentation has already flipped in a new pixmap, and the client may already be drawing a new frame to the pixmap used by the compositor, resulting in visual artifacts.

(Xwayland can do essentially what you're describing, since it has an explicit transfer of ownership via Wayland)


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer