On Wed, Aug 08, 2012 at 11:41:08PM +0200, Vincent Bernat wrote: > ❦ 8 août 2012 22:00 CEST, Vincent Bernat <[email protected]> : > > > Please, have a look to: > > > > http://www.red-team-design.com/wp-content/uploads/2011/11/css3-slick-progress-bars-demo.html > > > > With Conkeror, I get a 20% CPU use of this page when the buffer is > > displayed and 10% when it is not. > > > > With Firefox, I get a 20% CPU use but 0% when the page is in another > > tab. > > > > I think Conkeror is missing something to tell XUL that the buffer is not > > displayed so that it does not play useless animations. Maybe this is > > related with requestAnimationFrame(). I am not familiar enough with > > this. > > > > Those kind of animated progress bars are becoming popular and if you > > have a few tabs with them, you'll get a lot of wasted CPU use. > > > > I am using xulrunner 15b3 (from mozilla.debian.net). > > OK, I wasn't able to sleep with this unresolved. :) So I have digged a > bit and I have found that we can tell the browser object if a buffer is > active or not. I have came up with this patch. I know _nothing_ about > XUL and Gecko, so this is just an idea. > > Also, maybe there are other places where this could be applied (when > Conkeror window is iconified? Or not visible?). > > Tell me if you want me to file a proper bug for this. >
> From 7804cfa8318e4efb43addbc0c9cdb1d02bec461d Mon Sep 17 00:00:00 2001 > From: Vincent Bernat <[email protected]> > Date: Wed, 8 Aug 2012 23:33:50 +0200 > Subject: [PATCH] buffers: make a buffer inactive when switching away from it > > When a buffer is not visible, it can still eats CPU due to animations > and Javascript still running. Gecko has some mechanisms to mitigate > this (don't play CSS animations, run timers less often, ...) to avoid > eating CPU for something not displayed but we must tell the browser > object if it is active or not. > --- > modules/buffer.js | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/modules/buffer.js b/modules/buffer.js > index 06f4a56..a362a8f 100644 > --- a/modules/buffer.js > +++ b/modules/buffer.js > @@ -449,6 +449,7 @@ buffer_container.prototype = { > // Save focus state > old_value.saved_focused_frame = old_value.focused_frame; > old_value.saved_focused_element = old_value.focused_element; > + old_value.browser.docShell.isActive = false; > > old_value.browser.setAttribute("type", "content"); > }, > @@ -467,6 +468,7 @@ buffer_container.prototype = { > this.window.focus(); > > // Restore focus state > + buffer.browser.docShell.isActive = true; > buffer.browser.focus(); > if (buffer.saved_focused_element) > set_focus_no_scroll(this.window, buffer.saved_focused_element); > -- > 1.7.10.4 > That's very interesting. Will have time to investigate it next week. Meantime, if anybody else wants to research this, provide citations and arguments - is this the right thing to do? I'll be very interested. -- John Foerch _______________________________________________ Conkeror mailing list [email protected] https://www.mozdev.org/mailman/listinfo/conkeror
