← Back to team overview

ubuntu-phone team mailing list archive

Re: Qt 5.2 - Events are queued when rendering blocked

 

On Tue, Mar 25, 2014 at 8:25 PM, Ted Gould <ted@xxxxxxxxxx> wrote:
> On Tue, 2014-03-25 at 20:19 +0100, Thomas Voß wrote:
>
> Right now, we are considering the second alternative as it is much
> less intrusive. In the shell, we will leverage Mir's input event
> filter chains and offload reacting to certain kind of input events to
> a thread independent of Qt's UI thread. For the music player app, the
> issue will be solved when the media hub lands. The music player app
> will just "offload" music playback and playlist iteration to the media
> hub and we can expose the music player app to the usual application
> lifecycle (right now, it is granted an exception and is allowed to run
> when not focused).
>
> Please also note that the solution for the shell might serve as a
> reference for app authors who want to process events (such as sensor
> readings) at a higher rate than vblanc, and for that decouple their
> processing from the UI thread.
>
> The overall topic is quite complex and we might have missed something
> in evaluating the different alternatives, so consider this mail an
> early heads up together with a summary of our approach and ideas.
> Gerry is working on a POC for Unity8 right now, and we will keep you
> posted on the progress of that work.
>
>
> For the indicator-datetime case we were trying to send a notification to the
> shell and it appeared that the DBus event was held up by the UI thread.
> Could we also put QtDBus events into the non-UI thread?
>

We certainly should investigate into that direction, but let's first
finish the POC and take it from there.
Thomas

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


Follow ups

References