Just to be clear, I think the discussion about whether to queue release events is no longer related to implementing eglSwapInterval(0) so it shouldn't hold up the patch. As far as I understand if you want to render at the maximum rate you need four buffer slots and being able to disable the queuing mechanism isn't going to affect that. If the device can't handle four buffers then applications simply can't use eglSwapInterval(0) when rendering fullscreen. Increasing the number of buffer slots doesn't affect the number of buffers that will actually be used in the normal case of non-fullscreen applications which should continue to just use two buffers.
I agree that we should probably do something about the event queuing anyway. Currently if a fullscreen application goes idle after drawing its last frame it will never get the release event for the buffer because nothing will flush the queue. This would deny the application a chance to free the buffer. However I don't know if having a mechanism to explicitly disable the queuing is the right answer in this case and it might make more sense for the compositor to ensure that it always eventually flushes the queue instead of keeping it indefinitely. My previous patch to disable the queuing when there are no frame callbacks could still be a good way to achieve that. Regards, - Neil Daniel Stone <dan...@fooishbar.org> writes: > Hi, > > 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. > > Yeah, I agree. Maybe it could be an eglQueryWaylandBufferWL parameter > for EGL buffers? > > Ramping up the number of buffers used just isn't an option on > platforms with not massive amounts of memory, but enormous displays. > It also kinda cancels out some of the buffer_age benefits too. I take > the point that this is solving a different symptom of the same > problem, but I'm worried that it'll paper over the problem and we'll > end up just shipping patched versions (or fielding bug reports) on ARM > indefinitely. > > Cheers, > Daniel > _______________________________________________ > 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
