>> > On 28 October 2013 11:19, Tomeu Vizoso <to...@tomeuvizoso.net> wrote: >> >> I'm still concerned about platforms with high resolution displays but >> >> relatively little memory. >> >> >> >> I'm thinking of the RPi, but my understanding is that Android goes to >> >> great lengths to reduce the number of buffers that clients have to >> >> keep, because of general memory consumption, but also because scanout >> >> buffers are precious when you try to get the smoothest of the >> >> experiences that is possible on these phones. >> >> >> >> I think we should still consider adding a flag through which the >> >> client can tell the compositor to send the release events immediately >> >> instead of queuing them. >> >> >> >> Otherwise, the compositor is making a very broad assumption on the >> >> client's inner workings if it assumes that release events can be >> >> queued without a negative impact on performance. > > I fail to see how this is such a broad assumption. If we don't want to make > assumptions, we should just post the event every time. Admittedly, I don't > know what the inside of your RPi EGL implementation looks like. However, it > costs almost nothing to call wl_display.sync after every attach/commit and > it *guarantees* that you get the events. You don't have to continuously > sync, just sync after every attach/commit. While it may be somewhat > non-obvious, I don't see how calling sync once per frame is any worse than > setting some flag somewhere.
What I fail to see is why a single sync should be enough, as we don't know when the GPU will signal that it's done with the buffer that we are waiting to be released. Regards, Tomeu > Unless, of course, you are wanting the event absolutely as soon as it > happens. I'd like to see an actual use-case where doing so would save you a > buffer. > > Thanks, > --Jason Ekstrand > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
