[PATCH wayland-protocols] Add zwp_linux_explicit_synchronization_v1

[Matt Hoosier]

On Fri, Sep 22, 2017 at 6:18 PM, Matt Hoosier <matt.hoosier at gmail.com> wrote:
> 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.

Done, see https://lists.freedesktop.org/archives/wayland-devel/2017-September/035175.html.