[PATCH wayland-protocols] Add zwp_linux_explicit_synchronization_v1

[Pekka Paalanen]

On Wed, 20 Sep 2017 07:11:57 -0700
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Matt,
> 
> On 20 September 2017 at 05:48, Matt Hoosier <matt.hoosier at gmail.com> wrote:
> > On a related subject, there was discussion back at
> > https://lists.freedesktop.org/archives/wayland-devel/2013-September/011091.html
> > that acknowledged a longstanding bug where wl_buffer::release events
> > are starved indefinitely in the outbound server socket if there
> > doesn't happen to be any frame callback installed. That discussion
> > petered out, but it looked like there was a consensus that the issue
> > should be fixed (post the WL_BUFFER_RELEASE immediately rather than
> > queue if no frame callbacks attached).
> >
> > That seems like a good issue to get closed up. Any objections to
> > reviving the patch along the lines that Pekka suggested?  
> 
> Since then, we've moved the frame events around, such that they're no
> longer sent immediately, which might change the calculus a bit. Pekka?

Hi,

since 2013, we have got rid of the separate wl_event_loop used to
throttle the input events as well, IIRC.

I have to say today I would be completely fine with just posting the
release events always and never delaying them. The queueing has been
such a pain for EGL implementations.

I'm not sure we would even have the necessary information in the
compositor about whether a client wants release event ASAP or is it
happy with throttling. I suppose we could track whether the
wl_surface.commit that makes a wl_buffer reserved in the compositor
also had a wl_surface.frame request and only in that case queue the
release, otherwise post. I haven't thought it through.

Frame callbacks are sent as the last thing in weston_output_repaint(),
that has not changed. What did change is that there is now a delay
between the pageflip event and the call to weston_output_repaint(). Now
we also have the repaint grouping across outputs but I don't think that
makes much of a difference. So I would say the situation has not
changed wrt. to when the frame callbacks are sent out.

Well, if we need a pageflip event to release a buffer, then yes, the
frame callback will be coming later than in 2013. But that implies the
client buffer was on scanout.

I don't really like the idea that a client needs to "flush out" the
release events somehow. That is like leaking compositor implementation
details into clients. And that's exactly what asking for frame or sync
callbacks is when you have no other use for them.

I also don't quite like the idea of magically inferring whether a
client is speed-runner game or a leisurely office app. We might even
need explicit protocol for that, and then could use it for both buffer
releases and input event throttling and coalescing.

All in all, in the spirit of avoiding premature optimization, I'd go
for the simple solution and let profiling drive more complicated
solutions when the need arises. We're talking about buffer releases.
Buffer releases happen when clients animate. Surely animation is heavy
enough to obliterate any power savings we might get from optimizing
when to flush out release events?


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.freedesktop.org/archives/wayland-devel/attachments/20170922/c4f39c09/attachment-0001.sig>