Hi Alive, I've been sidetracked by other issues so here's my late answer...
On 01/09/2014 12:23, Alive wrote: > The searchBar is part of the system app, but the search app window is not. > > If system app does send the search window to background correctly when > it is not invoked, is this still an issue? That's a good question. Some time ago the search app window was considered always in the foreground but now it's properly moved to the background once it's dismissed so that seems to work fine. > We are *highly* willing to move the audio competing policy from gecko to > gaia… > > because there is still something needs to be determined by system app > but now in gecko we are handling it badly. Right now as far as the process priority manager is concerned this is fairly straightforward, we just check if the PID is playing something: http://hg.mozilla.org/mozilla-central/file/738469449872/dom/audiochannel/AudioChannelService.cpp#l496 Where you thinking of moving the AudioChannelService into Gaia? I'm not very familiar with how that code works so I can't really comment. > I am not sure how difficulty about exposing the wake lock and system > message, I'd keep wake-lock information handled at the Gecko level. It's really simple there (the priority manager is just waiting for notifications) and it's important to guarantee quick reaction times in important situations. For example grabbing the high priority lock in the dialer is only a few C++ calls away from having all other applications downgraded to the last priority level. This has proven to be critical for not missing incoming calls in loaded scenarios. Also see bug 874353 [1]. > * Launch related apps required by system message event(open-app) The system message situation is already improving IIRC, see bug 1046033 [2]. One important aspect regarding starting applications however pertains to the visibility state. If we could inform the priority manager that an app needs a healthy CPU boost at the very beginning of its launch process we might gain something compared to the current situation where we have to wait for it to become visible. > For activity chaining, we are doing it by force all apps involved in the > chaining to be foreground, and this is definitely not good. Yes, this is why I was considering using an LRU arrangement for foreground apps. > I was +1 to this idea from long time ago. > > get/get Priority/Nice value…or something like that. OK, so here's a concrete proposal. The visibility information is the first thing we could consider replacing with more direct control in the system app as well as special-casing of apps. Let's say we add a "priority" field to the DOMApplication object with an associated permission to manipulate it which would be given only to the system app. To keep things simple this field would support 5 priority levels which would correspond to the current BACKGROUND, BACKGROUND_HOMESCREEN, BACKGROUND_PERCEIVABLE, FOREGROUND_KEYBOARD, FOREGROUND. We don't need to call them that way naturally. Once this is done we'd have the system app set them to match the current policy and we'd simultaneously remove the visibility information and homescreen/keyboard special-casing from the priority manager and replace it with the assigned priority level. What do you think? I'd like to start simple because I feel we should be removing as much complexity as possible but do so in a gentle, incremental way. Gabriele
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
