ubuntu-phone team mailing list archive

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

On Thu, Mar 27, 2014 at 6:53 PM, Michal Hruby
<michal.hruby@xxxxxxxxxxxxx> wrote:
> On 26/03/14 07:33, Thomas Voß wrote:
>>
>> 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.
>
>
> Why isn't anyone considering returning true instead of blocking? The app
> will be sigstopped anyway, no? Also the UI thread isn't really throttled by
> vblanc, this happens only when the UI thread posts a sync event to the
> render thread.
>

The problem would then arise in the shell, with the render thread just spinning.
So Gerry is investigating into decoupling the render thread from the
UI thread to ensure
that events still get processed.

Thomas

> Michal
>
>
> --
> 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