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? Thanks, pq
pgpscTliMUW8_.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
