User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; nl; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; nl; rv:1.9.2) Gecko/20100115 Firefox/3.6 This week I almost switched to Chrome (or Iron for that matter). It feels faster. Until I remembered an old setting for Mozilla: nglayout.initialpaint.delay I put it to 50 ms, and instantly, Firefox (3.6) feels as speedy as Chrome/Iron. Maybe the default value should be something like 50 instead of 250. It is a very old value, based on old hardware, and slower connections. It used to make sense when my computer couldn't render that fast. But now that Dualcore @2Ghz and Megabit-connections is common, the repaint delay makes Firefox look slow. Even if the complete page would indeed be painted faster with a higher value (which was the original reason for setting it to 250 ms.) Reproducible: Always Steps to Reproduce: I notice a speed difference with Google Chrome/Iron. Ffx feels slower when surfing. Actual Results: It doesn't have to feel that way. Set nglayout.initialpaint.delay to 50 and it feels the same. Expected Results: nglayout.initialpaint.delay set to 50 by default or maybe 100, but not 250
I wonder if you do people a favor by painting the page earlier, when most relevant info and objects are not yet received, parts of pages that you are reading are nervously jumping to other spots while the page is rearranging itself. Maybe an extension like Fasterfox is what they want?
A quick search didn't turn up a duplicate, so confirming for consideration. Though there are at least two bugs for the opposite.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2) > Though there are at least two bugs for the opposite. I did another search and this exactly was not what I found in the database, so my memory was wrong about this. Some people do have problems with resizing tables and objects changing positions while loading but generally they don't see more paint delay as a solution.
Just found this bug already filed - had the same experience as the initial poster. Tested Chrome 5 the last days and it feels way faster on a fast system (Phenom II X2 555, 18MBit DSL) than Firefox. Since I remembered Gecko shouldn't be so much slower than WebKit I tried to tweak some FF-settings. Lowering nglayout.initialpaint.delay to 50 FF feels at least as fast as Chrome. Even if Gecko's rendering on paper is as fast as Webkit - it simply feels much slower on a fast system (usually owned by a very performance aware person).
(In reply to comment #3) > (In reply to comment #2) > > Though there are at least two bugs for the opposite. > > I did another search and this exactly was not what I found in the database, so > my memory was wrong about this. Some people do have problems with resizing > tables and objects changing positions while loading but generally they don't > see more paint delay as a solution. seems like setting it too low might be causing issues like bug 579421.
Also see bug 180241 which set it to 250 down from 1200. I think improvements in the browser and internet speeds might allow a lower value now, but it mainly used to stop too many reflows.
I was just about to file a new bug related to nglayout.initialpaint.delay until I found this. I created the pref in about:config (because it didn't exist) and set it to 0. I love the new found speed and Firefox now feels faster than Chrome (which it didn't before). Problem is I'm on a 10Mbps broadband package and that could be something other users don't have. Is there anything that could be done to feel fast for us "fasties" while compensating for the people on slower Internet connections?
(this is a more specific ask than the original. Patching on the original)
Assignee: nobody → glind
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 180241
a year ago
Duplicate of bug: 1283302
You need to log in before you can comment on or make changes to this bug.