ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Tue, Mar 25, 2014 at 9:34 PM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> On 03/25/2014 09:19 PM, Thomas Voß wrote:
>> We spent some time evaluating the situation and both alternatives.
>> While we can certainly map our lifecycle events to the respective Qt
>> events, we would have to block turning off the screen until all
>> applications have ack'd and thus told us that they are good to go. In
>> addition, we would need to handle applications not responding,
>> including potential grace periods such that apps can flush their
>> rendering queue. Moreover, we think that interpreting a potentially
>> blocking call to eglSwapBuffers as an error case is not correct. From
>> our POV, a call to eglSwapBuffers is a legitimate outcome, and we (as
>> well as many others) leverage this semantics for throttling client
>> applications.
>>
>> Right now, we are considering the second alternative as it is much
>> less intrusive.
>
> Less intrusive for who? :-)

For any EGL-based platform from my pov, but specifically for us.

> I actually liked your original idea (eglSwapBuffers returning false
> while the screen is off) much better, and that's definitely less
> intrusive for application developers.

If an application developer does not care about his/her application's
event processing being tightly coupled with the render thread and thus
with vblanc, no change is required at all. "Ordinary" applications
will not be hit by the issue anyway, as they will not be running when
the screen is off. That being said, we should certainly make sure that
our lifecycle events are mapped to the Qt equivalents.

> What is the reason who made you reconsider this? You explained it above,
> but I failed to understand why you need to wait for the applications to
> ack;

If we don't wait for the applications to ack before we carry out the
state change, we risk the application to run into a blocking
eglSwapBuffers call.

> can't you simply make eglSwapBuffers return false from the instant
> when you send the expose event?

As pointed out before: Interpreting a potential block as an error
condition in the context of eglSwapBuffers is difficult from my POV.
We also have to bear in mind that while Qt is the most prominent
toolkit on Ubuntu Touch right now, we also have to make sure that
other toolkits work flawlessly.

> As Gunnar wrote in the bug, for the
> small time window between the time when the screen goes off and the time
> when the applications receives the expose (off) event, Qt would just
> ignore the failed eglSwapBuffer.
>

Right, Qt :) eglSwapBuffer blocking is legitimate. If we return false,
we would also have to raise an appropriate error. According to:

  http://www.khronos.org/registry/egl/sdk/docs/man/xhtml/eglSwapBuffers.html

nothing really fits, and Qt does not yet handle EGL_CONTEXT_LOST. Even
if it would, raising EGL_CONTEXT_LOST and thus triggering the
application to reinitialize the entire EGL/GL context is not the right
thing to do here.

Cheers,

  Thomas

> Ciao,
>   Alberto
>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp