ubuntu-phone team mailing list archive

[Kevin Gunn <kevin.gunn@xxxxxxxxxxxxx>]

Maybe the conversation has moved on. But just want to bolster what Thomas
is highlighting.
We're not "working around" we're "working with" the new mechanism.

And the egl driver (or proxy) cannot simply return false without a
corresponding proper error code, which Thomas points out is most
appropriately EGL_CONTEXT_LOST.
If this were handled by Qt, I would advocate for us to use it. And I agree
that sletta (the upstream gentlefolk) seems open to this conversation.

br,kg



On Wed, Mar 26, 2014 at 2:33 AM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx>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.
>
> 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.
> >
>
> --
> 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
>