Second Feedback request for my GSoC project to improve Present support in Xwayland

[Pekka Paalanen]

On Thu, 3 Aug 2017 14:11:25 +0200
Roman Gilg <subdiff at gmail.com> wrote:

> On Wed, Aug 2, 2017 at 11:36 AM, Michel Dänzer <michel at daenzer.net> wrote:
> 
> > On 02/08/17 03:53 AM, Roman Gilg wrote:  
> > >

> > > Another more serious problem would be, if an application only uses a
> > > fixed number of pixmap and never uses one which hasn't yet received
> > > the PresentIdleNotify event. In this case the app execution could halt.  
> >
> > Not sure that's an issue. Every PresentCompleteNotify event should be
> > followed by the corresponding PresentCompleteIdle event within finite time.
> >  
> 
> Yes, you're right in probably all relevant cases. It's just a principal
> concern, because the Wayland specification mentions explicitly that a
> compositor is free to send the buffer release event at any time. If a
> compositor now would for whatever reason hoard these buffers and send the
> release event back in batches after few seconds the client could run out of
> pixmaps in these few seconds and stop refreshing its content. But yea, it's
> probably not a real world problem.

Hi,

yes, Wayland clients are expected to allocate more buffers on demand.
Two is enough only in the optimal case. Three is quite possible, and in
certain cases four might be necessary.

Let's take an example of a synchronized sub-surface that gets presented
in a hardware overlay directly, bypassing compositing:

- buffer A is on its way out of screen, but the vblank to flip it out
  has not happened just yet

- buffer B has been programmed to KMS, so it will get flipped on the
  next vblank in hardware, replacing buffer A

- buffer C has just been applied to the sub-surface, and will be taken
  to KMS on the next compositor repaint cycle, to replace buffer B

- buffer D has been committed to the sub-surface by the Wayland client,
  but the parent surface has not seen a commit yet, so it will not
  trigger the immediate release of buffer C

If the client wants to paint at this exact time instant, it would
actually need a fifth buffer. Buffer A is guaranteed to be released
in finite time "soon", so even with four buffers the client will not be
stuck indefinitely.

Of course, no Wayland server should be keeping client buffers reserved
for no reason, but there are more reasons than just the obvious reason
for needing two buffers.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170810/c32a6617/attachment.sig>