← Back to team overview

ubuntu-phone team mailing list archive

Re: Power management policy

 

On 07/19/2013 09:32 AM, Zisu Andrei wrote:
"let the user decide" is one of the reasons why foss fails with inexperienced users, plus, you really don't want that extra level of complexity on a phone.

The game doesn't really need to run in the background when it is not being played. You will just do design your game loop around that, but, in a server - client architecture, the update loop is on the server most of the time, so... No problem there.

I guess the only valid argument is the one with the loading browsers. Modern browsers don't repaint inactive tabs anyway, but javascript still runs and eats cycles you'd really wanna keep. If Ubuntu's gonna have something for that, it's gonna be a big plus.

On Friday, July 19, 2013, Mike Bybee wrote:

    On 07/19/2013 09:04 AM, Thomas Voß wrote:

        On Fri, Jul 19, 2013 at 5:51 PM, Mike Bybee
        <mbybee@xxxxxxxxxxxxxxx> wrote:

            On 07/19/2013 08:45 AM, Josh Leverette wrote:

            The spec looks very promising.


            On Fri, Jul 19, 2013 at 10:06 AM, Thomas Voß
            <thomas.voss@xxxxxxxxxxxxx>
            wrote:

                Hey there,

                you might be interested in:

                   *
                https://blueprints.launchpad.net/ubuntu/+spec/client-1303-add-app-model-and-lifecycle-to-platform-api
                   * and the corresponding spec in:

                https://docs.google.com/a/canonical.com/document/d/1ij8RtPsR_eYMW3mys8Gu1Y2CVFZpjXdMpdIjIGZ1SCA/edit#

                In summary: We will implement a very strict lifecycle
                policy, too, and
                one that seamlessly adapts and extends to different
                form-factors.

                Thanks,

                   Thomas

                On Fri, Jul 19, 2013 at 4:46 PM, Zisu Andrei
                <matzipan@xxxxxxxxx> wrote:

                    Hey guys,

                    What I find interesting in the iPad (I just have
                    one because I need it
                    for
                    work) and recently in Mac OS Mavericks is their
                    power managent policy.

                    Put simply, in iOS, except a few very special
                    cases, you applications
                    will
                    be stopped when they go into background. So the
                    foreground app gets full
                    reign of both memory and CPU. This also has a very
                    beneficial effect on
                    battery life - in Android, apps running in the
                    background still eat
                    cputime.

                    What OS X Mavericks is doing is taking this idea
                    further into a
                    noteboook
                    environment [1] with their application nap and
                    timer coalescing. You
                    really
                    only get the most out of your battery.

                    While this might not totally work in an
                    environment like Ubuntu, would
                    it be
                    possible to throttle the foreground application
                    and slow down the
                    background
                    ones?  What would this imply? Is it do-able in the
                    current state of
                    Ubuntu
                    Phone, or do we need extra things at kernel level?

                    [1]
                    http://www.apple.com/osx/preview/advanced-technologies.html



            --
            Sincerely,
                 Josh



            So, using a common example of an IM client or media player
            - would we assume
            that would stay in "unfocused" state? You mention that
            only core apps can
            run as background - that would mean it's not a valid state
            for a normal 3rd
            party app.

        Even core apps will not be allowed to run in background. We
        have an
        exit strategy in terms of the flag described in the document,
        but we
        will most likely not use it. However, we will provide services
        within
        the system (media playback, downloads, alarms) to allow apps to
        describe specific background operations. We will extend the
        list of
        supported operations over time.

        HTH,

           Thomas



    I would suggest that we want to fall closer to Android's app model
    than Apple's - or perhaps let the user decide how heavily it
    policies background apps. A mobile can get by with very limited
    background apps - but a tablet will not. My android tablet
    frequently has multiple apps running that I switch between
    regularly, from allowing a slow website to load while I'm writing
    a doc to a game that I pause so I can look up a hint.
    Let's not paint ourselves into a corner before we even start.

-- Mailing list: https://launchpad.net/~ubuntu-phone
    <https://launchpad.net/%7Eubuntu-phone>
    Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
    Unsubscribe : https://launchpad.net/~ubuntu-phone
    <https://launchpad.net/%7Eubuntu-phone>
    More help   : https://help.launchpad.net/ListHelp



--
Zisu Andrei

By "let the user decide" I don't mean we should confront people with it - I just mean it should be available for adjusting, much like swapiness is. Most people will never touch it, but it is nice to have. I think we really need to just go for the policy of "least surprise", right? If you want to swap between apps, they need to be able to behave as you'd expect them to. Especially with a tablet.

I mean, what if you want to copy/paste something between your password keeper and an app - you wouldn't want either one to "crash" or "vanish", nor the clipboard to vanish.

So my specific questions were directed to how we want to manage that - since a hard sigstop when an app switches would be equivalent to a crash to almost every current app in the app store. Obviously, lots of apps will be created *for* touch, but the point all along has been that it should be trivial to migrate existing QT apps back and forth - and overly aggressive killing of apps will hinder that.

Follow ups

References