On Mon, 16 Sep 2013 16:28:31 +0100 Neil Roberts <n...@linux.intel.com> wrote:
> Pekka Paalanen wrote: > > > Instead of all this, could you not have made Weston simply use > > wl_resource_post_event() instead of wl_resource_queue_event()? > > Yes, posting the event rather than queuing it when there are no frame > callbacks (is that what you meant?) is a lot simpler than having the > queue disabling mechanism. I'm not sure why I didn't think of that. Yeah :-) > Otherwise if you meant using post all of the time, then that was > discussed here and it doesn't seem like such a good idea: > > http://lists.freedesktop.org/archives/wayland-devel/2013-September/010987.html Yes, I'm aware. The main loop for a compositor is: while (1) { flush clients; dispatch idle handlers; /* repaint begin */ epoll_wait(); event loop dispatch; /* commit, repaint finish */ post_dispatch; } Hmm, Weston begins repaints from an idle handler, and finishes when a related event arrives (e.g. DRM page flip event). Yes, looks like there indeed is the double-wake-up of clients, if commit immediately releases an old buffer, and the release event is posted, not queued, and then compositor enters repaint, sending frame events. Frame events are sent in repaint begin, but usually flushed out only when something has woken the compositor up from epoll... that seems kind of strange, no? When looking at WAYLAND_DEBUG=server dumps, one thing to keep in mind is, are the events timestamped and printed when they are "sent" or actually flushed out. On client side, events are printed when they are dispatched (a missing listener for an object causes events not to be printed at all). And the double-wake-up also happens if repaint finish posts a release, I guess... If we look at client EGL buffers, that are not scanout, so they will be GL textures, an immediate release of the old buffer can happen only, if the compositor is not in the middle of repaint. Otherwise it would be releasing buffers that might still be textured from. If the compositor is waiting for a previous repaint to finish, the old buffer release should be postponed to the end of repaint (finish_frame). This applies, when the compositor is in a rendering loop, which is what a client with swapinterval 0 will cause, i.e. the case where the buffer releases are needed ASAP. Another thing I'm not sure about is when possible input events are posted to clients. The goal anyway is to group all event sending into one flush per output frame, at least when the compositor is continuously repainting. I'm not sure what I'm trying to say. I'm also not sure if Weston currently postpones the release of an EGL buffer used as a texture properly, if a repaint is on-going. > > I can't say if that is a good heuristic or not, to assume that > > surfaces where a client is not interested in frame callbacks need > > buffer releases ASAP. Apart from an explicit request, I have no > > better suggestions. > > As far as I understand, the queuing mechanism is specifically an > optimisation aimed at the frame callback mechanism to avoid waking up > the client twice. Therefore disabling it when there are no frame > callbacks seems like quite a natural thing to do in my mind. It's not > that the clients want the event ‘ASAP’ but rather that without the > patch the compositor will never send the events no matter how long the > client waits. Mm, maybe you are right. All the interactions are just too much for me to think quickly without spending a whole day. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
