On Thu, Oct 24, 2013 at 11:26:08AM +0100, Neil Roberts wrote: > Hi > > Thanks for the interesting insights. > > > It seems to me as if the default should always be to just send the > > event. > > I think I would vote for leaving the default as it is, ie, queuing the > release events. It's really quite a corner case that delaying events has > any effect on an application because most applications don't need to > know about the release events until they are about to draw something. > Usually they would only draw something in response to some event such as > a frame callback or an input event. In that case the event will have > caused the queue to flush so they will certainly be up-to-date about > what buffers are available at the point when they start drawing. If we > default to not queuing the event then I'd imagine most applications > wouldn't realise they should enable it and would miss out on the > optimisation. > > > We can identify buffer release events in weston as coming from one of > > three sources: > > > > 1) wl_surface.commit > > 2) surface_flush_damage (the gl renderer releases SHM buffers here) > > 3) random releases from the backdend/renderer > > > > Number 2 above happens during the redraw loop so we can just post the > > event and won't get a double-wakeup. > > Yes, I guess even if the compositor posts the event it's not going to > actually send it to the client until the compositor goes idle again > anyway and at that point it will probably have posted a frame complete > callback too so the client would wake up anyway. > > > Number 3 is something we can't really control; I'd personally lean > > towards posting the event here, but it's probably at most one > > reference per surface so we can probably get away with queueing. > > (Also, if the backend knows when it would release in the render cycle, > > it may be able to optimize this better than some compositor-general > > solution.) For these two, we can add an argument to > > weston_buffer_reference to set the release event type. > > I think case number 3 is the main problem. It's useful for most > fullscreen apps to have the event queued because most of them will be > throttled to the frame callback and don't need the release events > immediately. However this is also the use case most likely to want > eglSwapInterval(0) which would want them immediately so really for this > situation it is an application choice whether they should be queued or > not. > > > Number 1 above is the source of the vast majority of out release > > events. [...] The good news is that we can, from a client perspective, > > deal with this one easily. The solution is to send a wl_display.sync > > request immediately after the commit. > > Yes, I think it makes sense to always sync the rendering to at least a > wl_display.sync call and the Mesa patch I sent does already do this. You > are right that in practice this effectively solves the problem for most > use cases. So really the only case where this matters is when the > compositor is directly scanning out from the client's buffer. But on the > other hand, that is exactly what a fullscreen game is likely to be doing > and that is the most likely candidate for doing eglSwapInterval(0). > > > In any case, dummy sync and frame requests (you may need both) will allow > > you to achieve glSwapInterval(0) without server-side support. > > I'm not sure I follow you here. The release event may be queued at any > point after the frame complete is sent. In that case sending a sync > event to flush the queue is only going to help if Mesa sends it > repeatedly, but that amounts to busy-waiting which would be terrible. > > I still feel like the new request is the right way to go. The difficulty > with interface versioning feels like a separate wider problem that we > should think about. The crux of the problem is that Mesa probably > shouldn't be using proxy objects that are created outside of Mesa > because in that case it doesn't have control over what interface version > or event queue it is using. Working around the need for the new request > would just side-step the issue but it doesn't seem unlikely that Mesa > would want to use further new surface interfaces requests later too and > the same problem would come back. > > Maybe we should have a separate object that you can create per surface > in order to do new requests. This could be created by a new global > object much like the wl_shell interface. In order to make it usable to > both Mesa and the application, we would have to allow creating multiple > resources of the new interface for a single surface. I'm not sure what > to call it though because it would just end up being something like > ‘wl_surface_extra_stuff’. Considering that other objects may end up also > needing a similar kind of interface, maybe it would make more sense to > rethink it a bit and make the compositor allow multiple resources for an > object in general. Then you could have something like > wl_compositor.rebind_resource(object, version) which would make a new > resource for any object and it could have its own interface version. I > am just thinking aloud here though, I haven't really thought that > through much. > > I will take a look at how much hassle it would be to get Weston to allow > multiple resources per surface.
One idea that I haven't thought through that much as well is to add some way for mesa to get the "actual" version of some object it was provided. This could be done by adding a new global to put a "get_object_version" request that mesa could get its own object for. Then it would need to be specified that when a compositor got requested for an object of version N, it must need to be able to handle requests for newer versions than N as well. All this, assuming the opcodes for newer interfaces never conflict with old ones, one could just send requests using opcodes provided by the -protocol.h file mesa was built with, and the compositor should react accordingly. One could see it as something similar to instanceof on and casting the already provided object. Jonas > > Regards, > - Neil > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
