Mobile/Powersaving: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 20: Line 20:
** Availability: Probably Meego. Android lacks it in the Java API (but other signals are present, so perhaps it will be added), perhaps using the NDK it is possible though?
** Availability: Probably Meego. Android lacks it in the Java API (but other signals are present, so perhaps it will be added), perhaps using the NDK it is possible though?
** Benefit: Straightforward, simple to implement, guarantees the best results.
** Benefit: Straightforward, simple to implement, guarantees the best results.
** Status: Working proof of concept for 'suspending/freezing' the content process as desired.
* Messy option: Add separate options throughout our codebase to allow things to be temporarily frozen - JavaScript, animations, plugins, etc. etc.
* Messy option: Add separate options throughout our codebase to allow things to be temporarily frozen - JavaScript, animations, plugins, etc. etc.

Revision as of 00:02, 22 May 2010

Overview

On mobile devices we want to use the least amount of power, so the device's battery will last as long as possible. Users will likely notice what browsers are better in this and prefer them.

Metrics

  • # of wakeups/second, that prevent the CPU from sleeping. See powertop. Relevant in low CPU load.
    • Fennec currently has 1.5 wakeups/second when idle.
  • CPU %. Relevant in high CPU load.
  • Disk usage (tools: iostat, atop).
    • Relevant config setting: browser.sessionstore.interval

Ideas

  • 'Nuclear option': Use OS-level operations to make processes sleep or use low CPU % when they should. On Linux this can be done with SIG_STOP, SIG_CONT (see e.g. cpulimit).
    • Uses:
      • Put background tabs to sleep (requires one process per tab).
      • Force plugins to use low CPU % (Flash etc.)
      • Put all tabs to sleep when idle (sort of like a screensaver)
    • Availability: Probably Meego. Android lacks it in the Java API (but other signals are present, so perhaps it will be added), perhaps using the NDK it is possible though?
    • Benefit: Straightforward, simple to implement, guarantees the best results.
    • Status: Working proof of concept for 'suspending/freezing' the content process as desired.
  • Messy option: Add separate options throughout our codebase to allow things to be temporarily frozen - JavaScript, animations, plugins, etc. etc.