On Sat, Aug 7, 2010 at 19:33, Tomeu Vizoso <to...@sugarlabs.org> wrote: > On Sat, Aug 7, 2010 at 19:31, Bernie Innocenti <ber...@codewiz.org> wrote: >> El Sat, 07-08-2010 a las 18:14 +0200, Tomeu Vizoso escribió: >> >>> So we would have a periodic wakeup? The test would be the amount of >>> free memory plus buffers and caches? >> >> A polled design is clearly inferior to a proper notification system, but >> it has the advantage of being simple and not requiring a particular >> kernel. Once this is done, switching to a better solution should not >> require extensive changes to the UI code. >> >> BTW, looking at top, it seems that Sugar and other processes wake up >> quite frequently when the system is supposed to be completely idle. It >> may be background checks for updates, NetworkManager updates or the >> presence service. Plus, there are a bunch of cron jobs that run in the >> background, inclding the ds-backup and olpc-update. >> >> All these things drain battery power and cause the UI to become jerky, >> so we should try to limit them if possible. > > NM is particularly active when there are more than a few APs > available, wonder if it would be possible to tune it to group updates > in batches.
On a second thought, Sugar should probably only listen to events relevants to what is being currently displayed. This would display outdated data for a short while and would mean significant rework but may be a worthy goal for the future. Regards, Tomeu > Regards, > > Tomeu > >>> > Or, maybe, we could make this a manual process: pop up a notification >>> > when memory is short and ask which activity should be closed. >>> >>> I would just close one of the background activities, the LRU or the biggest >>> one. >> >> +1. >> >> This, however, makes non-sugarized activities more dangerous to deal >> with. One more reason to demand proper sugarization. >> >> -- >> // Bernie Innocenti - http://codewiz.org/ >> \X/ Sugar Labs - http://sugarlabs.org/ >> >> > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel