[PATCH wayland-protocols] Add zwp_linux_explicit_synchronization_v1

[Matt Hoosier]

On Fri, Sep 22, 2017 at 10:24 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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?

I completely agree. I'll submit something to wayland-devel on Monday.