<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 28, 2013 at 9:10 AM, Neil Roberts <span dir="ltr"><<a href="mailto:neil@linux.intel.com" target="_blank">neil@linux.intel.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just to be clear, I think the discussion about whether to queue release<br>
events is no longer related to implementing eglSwapInterval(0) so it<br>
shouldn't hold up the patch. As far as I understand if you want to<br>
render at the maximum rate you need four buffer slots and being able to<br>
disable the queuing mechanism isn't going to affect that. If the device<br>
can't handle four buffers then applications simply can't use<br>
eglSwapInterval(0) when rendering fullscreen. Increasing the number of<br>
buffer slots doesn't affect the number of buffers that will actually be<br>
used in the normal case of non-fullscreen applications which should<br>
continue to just use two buffers.<br>
<br>
I agree that we should probably do something about the event queuing<br>
anyway. Currently if a fullscreen application goes idle after drawing<br>
its last frame it will never get the release event for the buffer<br>
because nothing will flush the queue. This would deny the application a<br>
chance to free the buffer. However I don't know if having a mechanism to<br>
explicitly disable the queuing is the right answer in this case and it<br>
might make more sense for the compositor to ensure that it always<br>
eventually flushes the queue instead of keeping it indefinitely. My<br>
previous patch to disable the queuing when there are no frame callbacks<br>
could still be a good way to achieve that.<br></blockquote><div><br></div><div>Yes, I think we should find some way to ensure that the queue gets flushed eventually.  Your patches may work for this.  Another approach would be to simply force-flush the queue of every client every once-in-a-while.  In any case, I think that's a Weston implementation issue not a fundamental protocol issue.  Another option would be to detect when a application goes from being in its own plane to the primary plane (Or any other operation that would cause the number of required buffers to decrease) and make sure the buffer releases get posted in that case.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
- Neil<br>
<div><div><br>
Daniel Stone <<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>> writes:<br>
<br>
> Hi,<br>
><br>
> On 28 October 2013 11:19, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net" target="_blank">tomeu@tomeuvizoso.net</a>> wrote:<br>
>> I'm still concerned about platforms with high resolution displays but<br>
>> relatively little memory.<br>
>><br>
>> I'm thinking of the RPi, but my understanding is that Android goes to<br>
>> great lengths to reduce the number of buffers that clients have to<br>
>> keep, because of general memory consumption, but also because scanout<br>
>> buffers are precious when you try to get the smoothest of the<br>
>> experiences that is possible on these phones.<br>
>><br>
>> I think we should still consider adding a flag through which the<br>
>> client can tell the compositor to send the release events immediately<br>
>> instead of queuing them.<br>
>><br>
>> Otherwise, the compositor is making a very broad assumption on the<br>
>> client's inner workings if it assumes that release events can be<br>
>> queued without a negative impact on performance.<br></div></div></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br></div><div>Thanks,<br></div><div>--Jason Ekstrand<br></div></div><br></div></div>