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.
