On Wed, Oct 22, 2008 at 3:34 PM, <[EMAIL PROTECTED]> wrote: > On Wed, 22 Oct 2008, Deepak Saxena wrote: > >> I would like to present a short session and faciliate the follow up >> discussion on and dealing with the memory constraints on our system >> at an application framework level. >> >> From my understanding, there are two situations we are running into >> with low memory that need separate solutions: >> >> 1) A single running application, Browse for example, chews up lots >> of memory. The only real solution I can think of to this is to >> make the applications and underlying libraries leaner and smarter. :) >> >> 2) End users run multiple applications or multiple instances of the >> same application, quickly chewing up system resources. >> >> I would like to primarilly focus on dealing with (2). >> >> I've done a bit of reading on how other low memory systems (cell phones >> for example) handle running multiple tasks and would like to propose we >> borrow some of these ideas for Sugar. In Android for example, when a user >> switches between tasks, the framework will tell switched out task to save >> enough state such that it can handle being killed while in the background. >> The user does not know that a background application is dead and on task >> switch back to that application, the framework will restart the application >> and tell it that it should restore state and not do a cold startup. I need >> to read more of the Android and Sugar docs before I can have a detailed >> proposal but at a high level my proposal is to add similar smarts to our >> framework. This includes, but is not limited to: >> >> - Adding Sugar APIs to handle cold activity start vs restart from saved >> state and modifying activites to support these APIs. >> >> - Make the Sugar framework (or some other system component) talk to the >> kernel's OOM interface (/proc/<pid>/oom) to manage what tasks should be >> killed and ensure the foreground process does not get killed. >> >> What I'm proposing is a form of cooperative multitasking managed at >> the application framework level instead of the core OS level. > > how can the user tell the system that they are switching away from the > browse to another window becouse they know that browse will take 2 min to > download and display the page and they want to do other useful stuff in > the meantime? having the system suspend browse when you switch away from > it is doing exactly the wrong thing. > > that being said, having some signal that means 'you don't have the users > eyeballs right now, don't waste time on animations/etc' could be useful, > the problem would be defining what NOT to do when in this mode.
This info is already available via X, I believe. You're right; the HIG doesn't have a section on proper behaviors for this case yet. I have a ticket open on that, but I haven't had a chance to touch the HIG in months. - Eben > David Lang > _______________________________________________ > Devel mailing list > [email protected] > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
