ubuntu-phone team mailing list archive

[Michal Hruby <michal.hruby@xxxxxxxxxxxxx>]

On 31/03/14 14:24, Kevin Gunn wrote:
> @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

Right, that would workaround the issue in Qt, but do we know how for 
example SDL will deal with eglSwapBuffers blocking? I do not see in the 
spec any mention of indefinite blocking, and afaict it doesn't seem 
expected, afterall the spec does say that eglSwapBuffers implicitly 
performs glFlush which doesn't block. It feels like we're misusing our 
egl implementation to deal with app lifecycle.

Also I didn't suggest to just ignore the frame and return true, as you 
mentioned it might be *the* frame which the user is most interested in, 
so it should be sent to the GPU memory.

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

I also don't think EGL_CONTEXT_LOST is a good idea - it seems to be used 
for cases when GPU wakes up after deep sleep and the (GL) state cannot 
be restored, so everything needs to be rebuilt from scratch.

Michal