ubuntu-phone team mailing list archive

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

On Wed, Mar 26, 2014 at 12:05 AM, Michał Sawicz
<michal.sawicz@xxxxxxxxxxxxx> wrote:
> I must say I'm not liking, what appears to me to be, a "they're doing it
> wrong, let's work around it" approach.
>

Well, I don't think we are just saying "They are doing it wrong". The
alternative approach with the POC that Gerry is working on is less
intrusive on our side. That being said: We should still work on
correctly exposing our lifecycle events to Qt via QtUbuntu.

> On 25.03.2014 22:12, Thomas Voß wrote:
>> 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:
>>> 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.
>
> If they're Doing It Wrong™, should we not try and discuss with them how
> we can improve the situation instead of working around it?

I think we are doing that and the conversation with upstream hasn't
come to an abrupt end. We have to address our outstanding issues,
though, and the POC is a way forward in doing so.

> Is there not
> prior art for this? Is the approach that we'd return false for the call
> when screen is off incorrect, or plain impossible?
>

It's obviously not plain impossible, but we have to carefully evaluate
the implications of "just" returning false. According to the EGL spec,
eglSwapBuffers waits at most eglSwapInterval frames (or vblanc
cycles). The behavior in case of the screen being turned off is not
explicitly stated (see [1] and [2]). We currently interpret screen off
as "no vblanc" -> no frame -> eglSwapBuffers blocking indefinitely.

> If we start saying "use QML everywhere, except don't, 'cause it's not
> going to get events when screen is off", that's really changing the
> message, and we should not do that lightly.
>

Hmmm, I think our lifecycle policy never stated that an application is
even running when the screen is off. In addition, I think we should
make sure that we distinguish between two things here:

(1.) eglSwapBuffers behavior when the screen is turned off.
(2.) All event processing on Qt's UI thread being implicitly throttled
by vblanc.

(2.) is something that we should document for application developers,
together with examples for demonstration how an app developer can
ensure  that event processing can happen independent of the UI thread.

Cheers

  Thomas

[1] http://www.khronos.org/registry/egl/sdk/docs/man/xhtml/eglSwapBuffers.html
[2] http://www.khronos.org/registry/egl/sdk/docs/man/xhtml/eglSwapInterval.html

> --
> Michał (Saviq) Sawicz <michal.sawicz@xxxxxxxxxxxxx>
> Canonical Services Ltd.
>