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
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
