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. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
