ubuntu-phone team mailing list archive

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

On Thu, Mar 27, 2014 at 10:49 PM, Michal Hruby
<michal.hruby@xxxxxxxxxxxxx> wrote:
> On 27/03/14 19:30, Thomas Voß wrote:
>>
>> 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.
>
>
> Just let Qt know that the shell window is obscured, that's when the render
> thread stops.
>

Sure, raising ExposeEvents will surely be integrated. I think I
mentioned that earlier in the thread.

Thomas

> Michal