ubuntu-phone team mailing list archive

[Kevin Gunn <kevin.gunn@xxxxxxxxxxxxx>]

@Michal Hruby -  We are working on a solution that unblocks the GUI
thread's event handling & avoids the race (between eglswapbuffer & the side
channel expose event). However, we're not going to return true when that's
not the case, that would be naughty, what if that one frame was _the_ most
important frame?...in general we need to solve while staying within the egl
interface per spec. And I think we have a potential solution to chase...see
below

@Gerry - yes, i think our current proposed plan of solving will address
avoiding potentially stale data in the pipeline upon resuming of the render.

For those not directly involved, "what is the current plan?" you ask?
We've reviewed the EGL specification and the most appropriate way forward
is to return EGL_FALSE  with the EGL error set to EGL_CONTEXT_LOST since
this is a power management event. This approach will unblock the GUI
thread, however does have a cost that the EGL client has to account for by
destroying/creating EGL context (thankfully surfaces are treated
seperately, not part of the egl context). It seems to me there is room for
another egl error state that doesn't involve contexts, like EGL_NO_DISPLAY,
but alas we have to work within the API. At the moment this means reworking
Mir's current handling of the power management event as well as a matching
patch to Qt to handle the error on the client side.

Again, as Thomas stated in the original mail, this is somewhat a complex
topic.
We _think_ this is the most appropriate way forward, so your input is still
welcome.
br,kg


On Thu, Mar 27, 2014 at 7:31 PM, Gerry Boland <gerry.boland@xxxxxxxxxxxxx>wrote:

> On Thu 27 Mar 2014 22:42:33 GMT, Michal Hruby wrote:
> > On 27/03/14 22:18, Michał Sawicz wrote:
> >> On 27.03.2014 22:49, Michal Hruby wrote:
> >>> Just let Qt know that the shell window is obscured, that's when the
> >>> render thread stops.
> >> Problem here is that's racy - by the time the expose event reaches
> >> whatever it needs to reach, the render thread might already be blocked
> >> in eglSwapBuffers.
> >
> > I didn't back off from my suggestion to stop blocking and just return
> > true there. It's not like turning off the display disallowed us from
> > copying a buffer.
> >
>
>
>
> One worry I have about eglSwapBuffers blocking is what happens at
> unblock. It blocks when powering down the display. Unblock happens when
> the display is powered back up, however the GL pipeline still contains
> the commands for rendering the last frame before the screen was powered
> down. So at display on, the first frame rendered will be a
> before-display-off frame - which is bad.
> Is there something I'm missing?
> -G
>
> --
> 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
>