On the 29th daily reflow testing indicated a big jump in the number of reflows and the number has remained high since. See ftp://ftp.mozilla.org/pub/data/reflows/daily.png. Perhaps coincidentally, the number of leaks counted jumped up dramatically for the same build and has also remained very high. See ftp://ftp.mozilla.org/pub/data/leaks/leaks_results_daily.html.
Why is this assigned to me?
marc or someone in layout land, we need help to take a look at this reflow count problem....
Would that perhaps be: http://bonsai.mozilla.org/showcheckins.cgi?&treeid=SeaMonkey&batchid=500 In that case it was a cache landing but very few layout changes. Could the patch for bug 28220 cause something like this?
Taking to investigate...
Assignee: blizzard → attinasi
Curt, do you have the detailed reflow logs for this? I am interested in one or both of the following: 1) the reflow counts per frame type 2) the reflow counts per URL Basically, total reflow counts don't give us much to focus the search, but if we know what types of frames have more reflows, or if we know which URLs are showing the biggest jumps, then that will really help.
Status: NEW → ASSIGNED
moving to m0.9
Target Milestone: --- → mozilla0.9
can anyone try backing out my rather minor changes to formatting.css? it just added a rule with a ".link" selector: http://lxr.mozilla.org/seamonkey/source/themes/modern/global/formatting.css#173 I don't know enough about testing reflow counts to know how to test this, but I want to make sure it's not me :)
Actually, alec's query has made me wonder just how these tests are run. Using SeaMonkey or and Embed app? Using which skin? What URL's? Is there a description of the test suite available? Thanks. I'm checking my change to nsLineLayout (3.95) to see if that could account for the dramatic change in reflow counts. BTW: Rod Spears posted to n.p.m.performance instruction on how to dump reflow counts for those who want to check their changes for themselves...
Detailed data is available at: http://ftp.mozilla.org/pub/data/reflows/reflow_results_daily.html
detailed information is available for each days tests at http://ftp.mozilla.org/pub/data/reflows/reflow_results_daily.html "Entire output from reflow test" is lengthy, but I believe it has the info you're looking for
This test is only on Linux right? libpr0n was enabled in Linux builds for builds of 3/30, the build that show the increase (or specifically it was enabled at 03/29/2001 23:05). Just a data point.
Just verified with Curt, his automation is only available on Linux right now. So, this is the result of reflow on Linux. Curt built the test automation to use rods reflow count tool to get reflow numbers. cc'ing pav
I'm almost positive this is due to something changing with images. I looked at the reflow comparison chart and noticed that there are some URLs with very small or non-existant reflow count deltas, and some with very large deltas. Examining those URLs I noticed that those URLs with large deltas have many images, and those with small or 0-deltas have few or no images (there is an exception, www.lesechos.fr/index.html, which has many images but a small delta: this needs further examination). The correlation is pretty amazing. At the extreme is the URL base/www.w3.org_DOML2Core/ : this page has no images and has a delta of 0 (no change in reflow counts). At the other extreme, www.zdnet.com_Gamespot.com/ has 162 images and the reflow delta is 9954, or a 343% increase. I'll attach the details for others to examine. I'm still not convinced that this extra reflowing is terrible since the load times are not suffering, but I'm not convinced that it is benign either. Can anyone build from the same source with and without libp0rn and see what happens to the reflows, if it somewhat mirrors the difference between the 3/29 and 3/30 builds? Pavlov?
Priority: -- → P1
Created attachment 29913 [details] TEXTFILE: Comparison of 2/29 vs. 3/30 builds: reflow counts compared to number of images
Over to pav - he says he has this fixed now.
Assignee: attinasi → pavlov
Status: ASSIGNED → NEW
yup, checked in a fix last night
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified fixed with embed build 2001-04-17
Status: RESOLVED → VERIFIED
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.