On Thu, Mar 27, 2014 at 10:49 PM, Michal Hruby <michal.hr...@canonical.com> wrote: > On 27/03/14 19:30, Thomas Voß wrote: >> >> On Thu, Mar 27, 2014 at 6:53 PM, Michal Hruby >> <michal.hr...@canonical.com> wrote: >>> >>> On 26/03/14 07:33, Thomas Voß wrote: >>>> >>>> On Wed, Mar 26, 2014 at 12:05 AM, Michał Sawicz >>>> <michal.saw...@canonical.com> 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.marde...@canonical.com> 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. >>> >>> >>> Why isn't anyone considering returning true instead of blocking? The app >>> will be sigstopped anyway, no? Also the UI thread isn't really throttled >>> by >>> vblanc, this happens only when the UI thread posts a sync event to the >>> render thread. >>> >> The problem would then arise in the shell, with the render thread just >> spinning. >> So Gerry is investigating into decoupling the render thread from the >> UI thread to ensure >> that events still get processed. > > > Just let Qt know that the shell window is obscured, that's when the render > thread stops. >
Sure, raising ExposeEvents will surely be integrated. I think I mentioned that earlier in the thread. Thomas > 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
