ubuntu-phone team mailing list archive

[Zsombor Egri <zsombor.egri@xxxxxxxxxxxxx>]

Guys, I wonder how Jolla will react on this when they move to > 5.1... I
think it would be worth asking them. w00t (Robin Burchell) may be the best
contact from #jollamobile or #nemomobile seems.


On Wed, Mar 26, 2014 at 1: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.
>
> 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(tm), should we not try and discuss with them how
> we can improve the situation instead of working around it? 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?
>
> 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.
>
> --
> 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
>
>