Closed Bug 407767 Opened 18 years ago Closed 15 years ago

add a method to tell when rendering and network are quiescent

Categories

(Firefox :: General, defect)

All
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: jg, Unassigned)

Details

(Whiteboard: [CLOSEME 2010-11-01])

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11 Build Identifier: Here's the one small hook Mozilla can implement quickly that will make a huge difference to a huge numberchildren.... On the XO, we can leave the screen on while suspending the rest of the machine (with or without wireless). We've implemented what we call "ebook mode" in our book viewer (based on evince), so that as soon as the page has been rendered, we can turn off the rest of the computer. Our system can already wakeup in under 1 second (we believe the hardware is good to about 50ms). We do this on page by page viewing, and the application knows when the machine is safe to suspend. We don't have to wait for some arbitrary timeout to suspend the machine. This makes a huge difference in battery life. Rather than 3-5 hours life, you can get upwards of 13 hours. It would not surprise me that over the life of OLPC, this could translate to 10-20% of the costs; or, to put it differently, 10-20% more kids can get some education. But much of the content is HTML/DHTML/Web based; the browser, even when there is no network connection, it is a major viewer for content. Wee'd like the browser to be able to implement the same sort of behavior we've been able to get in evince. The browser is the #1 application, according to the teachers. Having a callout that mozilla makes to tell us when its threads reading from the network and rendering arecomplete will work way better than the user idle heuristic Chris Ball has implemented initially. Let me make this concrete and immediate now that deployment is no longer hand waving, but absolutely concrete with contracts and letters of credit in place: Based on the information Oscar Becerra of Peru just gave us, *fifty-five thousand* of the laptops going to Peru starting in February are going to schools with _no_ power grid. What is more, some of the schools take *twenty* days to travel to. At those schools, the teacher travels for one month, teaches for one month, and then returns to civilization; the laptops are to enable them to learn not just while they have a teacher, but the other two months they do not. We'll be using solar (but using needing more watt hours means more panels and batteries), and generators (but the fuel cost is extreme in some cases) for power; reducing the watt hours consumed to the minimum possible is *really* important. So this feature request can make a bigger difference to more kids than almost anything else we can ask for or which we can do anywhere else in the OLPC project overall; it translates directly into cost of deployment (solar cells needed; batteries for storage etc) which constrains how much of the money results in laptops going to kids to learn with, and in operating costs (in the case of using generators that need fuel supplied, and amortization costs of any solar infrastructure). Reproducible: Always
Summary: Need a way to determine with Xulrunning is idle...Here's the one small hook Mozilla can implement quickly that will make a huge difference to a huge number children.... Need a way to determine with xulrunner is idle. → add a method to tell when rendering and network are quiescent
I know that you can tell when a page finishes loading. That's a classic DOM signal that everyone hooks into these days. But that doesn't tell you when you're done rendering a page. There's also a big problem here with the way that a lot of modern sites work. Even when they are done loading and rendering a doc, they can wake up and contact the server to look for new mail or posts, change the DOM and cause re-rendering to occur. So while we can help with the problem a bit we certainly won't be able to get it right 100% of the time.
This is a mass search for bugs that are in the Firefox General component, are UNCO, and have not been changed for 1000 days and have an unspecified version. Reporter, can you please update to Firefox 3.6.10, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the bug, please update this bug. If the issue is gone, please set the resolution to RESOLVED > WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.