ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Sun, Oct 27, 2013 at 5:50 PM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> On 10/25/2013 08:48 PM, Thomas Voß wrote:
>> One thing that strikes me: Instead of trying to solve the problem a
>> lot of "won't work" statements are made in this thread, going along
>> with a request for removing all of the lifecycle policies. And to be
>> clear: With strict policies in place, it is always possible to find an
>> example that breaks. So I think we can stop collecting breaking
>> examples here.
>
> I think that Ubuntu should strive to do *better* than other platforms,
> not equal or worse. So, given that we are at the early stages and we are
> still in a position to correct the design and improve the
> implementations, we should spend some time to think of use cases which
> we don't support with the current design, and address them.
>

Sure.

> Especially given that it might not be easy to change this stuff in the
> future.
>

That I fully agree with, and for that, we should be very careful about
which features and capabilities we grant to applications.

>>> Yes and no. As I wrote before in this thread, in some cases it's
>>> possible to detect when an application will need to run or can be
>>> killed. We don't have to allow all applications to run in the
>>> background. But why not let a navigation application declare in its
>>> manifest file that it wants to be left running if it's defocused while
>>> the GPS is on?
>>
>> Because that is an open invite to any app developer to leverage that
>> way out, too. We do not do install time application permission
>> verification by the user for a good reason.
>
> I think we are misunderstanding; I'm not saying that the user should be
> asked (at install time or at run time) for granting a permission. There
> would be a policy groups "background_gps", "background_music" which the
> app developer can declare in its manifest file. Then, if the application
> is defocused while it's using the GPS or playing music, it wouldn't be
> stopped. If it's not using the GPS or playing music, it will be stopped.
> It seems much simpler to me, and I don't see what could go wrong here.
>

What prevents every app from just doing that? One example: When iOS
had the policy of an app playing music not being suspended, a lot of
applications just looped a whitenoise sound file to not be suspended.

>>> As for GPU resources, Qt can release all of them when the window is not
>>> exposed, if told to.
>>
>> Hmmm, people said that about cooperative multi-tasking, too: Sure, the
>> app will happily give up its timeslice (tm).
>
> You are right that we cannot depend on this. But the display server can
> know the amount of GPU resources that each application is using, and
> kill those which use more of them; in this way, an application which
> properly releases all the GPU resources would probably be saved.
> Anyway, I now realize that this is actually not the issue we were
> discussing (this is about killing, while the discussion is about
> stopping), so we can forget about this second topic. :-)
>

Sure, we can be clever about graphics resources, but at some point, we
would need to destroy the apps egl context and require toolkits/apps
to be EGL context robust and being able to handle that case. Of
course, this is not a blocker, just something we do not have right now
and which would require effort to implement.

Thomas

> Ciao,
>   Alberto
>
> --
> 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