On Fri, Sep 22, 2017 at 6:18 PM, Matt Hoosier <[email protected]> wrote: > On Fri, Sep 22, 2017 at 10:24 AM, Pekka Paalanen <[email protected]> wrote: >> On Wed, 20 Sep 2017 07:11:57 -0700 >> Daniel Stone <[email protected]> wrote: >> >>> Hi Matt, >>> >>> On 20 September 2017 at 05:48, Matt Hoosier <[email protected]> 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. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
