Closed
Bug 46298
Opened 24 years ago
Closed 23 years ago
Reflows not batched properly?
Categories
(Core :: Layout, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
mozilla0.9.5
People
(Reporter: selmer, Assigned: waterson)
References
()
Details
(Keywords: perf)
2000-07-24-08 (and almost every prior build I can remember) I've been hoping that some optimization would fix this, but it never goes away. On the bugzilla query page, scroll down to the products menu (which is actually labeled "program:") and click on some product. Notice that all the menus next to the product menu start whizzing around, up and down, expanding and shrinking until finally the whole page is different and all the menus are finally drawn. It seems like all those reflows should have been batched into a single reflow so the page can redraw just once. On 4.x, the equivalent action results in an immediate paint of the proper screen. My suspicion is that these events are not being batched because the source of the changes is from javascript as it removes all the old menu items and then inserts all the new ones. Something about this is preventing batching, possibly just the time it takes the javascript to execute...
Reporter | ||
Comment 1•24 years ago
|
||
Adding 4xp, pages like this should not perform so drastically worse than 4x.
Assignee: clayton → waterson
Keywords: 4xp
Yes this reflow also 'breaks' the other menus, in that the options get messed up and you can't select properly from them. (Linux build 2000071910)
Assignee | ||
Comment 3•24 years ago
|
||
This is a dhtml issue; nisheeth: you may want to add this to your growing list of "dhtml optimization tasks". Futuring for now.
As I just commented on bug 27233: The problem here seems to be that we are causing lots of reflows by calls to nsGenericHTMLElement::GetPrimaryFrame(), which calls nsHTMLDocument::FlushPendingNotifications. In the case of bugzilla query page component switching, these calls are coming from nsHTMLOptionElement::GetSelected(). In the case of loading test8 (although it doesn't account for as much of the time there), they're coming from nsHTMLTextAreaElement::HandleDOMEvent and nsHTMLSelectElement::HandleDOMEvent. GetPrimaryFrame does take an extra argument (with a default value of PR_TRUE) for whether to flush notifications, but that may or may not be the correct solution. For that matter, I'm not sure why form controls should store any of the state described in the DOM spec in the frame model -- that should be part of the content model (according to the DOM spec).
This patch fixes the flickering (in just this one specific case, of course), but actually doesn't do that much to help performance. Perhaps that's just a case of GetPrimaryFrameFor being slow? Index: nsHTMLOptionElement.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/content/src/nsHTMLOptionElement.cpp,v retrieving revision 1.60 diff -u -d -r1.60 nsHTMLOptionElement.cpp --- nsHTMLOptionElement.cpp 2000/12/23 10:56:19 1.60 +++ nsHTMLOptionElement.cpp 2001/01/14 15:10:38 @@ -212,7 +212,7 @@ *aValue = PR_FALSE; nsIFormControlFrame* formControlFrame = nsnull; - GetPrimaryFrame(formControlFrame); + GetPrimaryFrame(formControlFrame, PR_FALSE); if (formControlFrame) { PRInt32 indx; Any thoughts on whether we should get rid of the default argument on GetPrimaryFrame / GetPrimaryFrameFor? I've been bitten by it before (for flushing notification when I shouldn't), and it would be good to make people think about a little for performance, too...
Linux build 2001040105. This problem is still there, and it looks worse ever. The reflows take whole seconds to redraw.
OS: Windows NT → All
Reporter | ||
Comment 7•23 years ago
|
||
nom catfood, this appears to affect a lot of the net. Is there already a separate bug for the slowness of GetPrimaryFrameFor?
Keywords: nsCatFood+
Bug 63890 - GetPrimaryFrame could still be faster, and more space efficient
Comment 9•23 years ago
|
||
The reflows are now being suppressed thanks to rods's checkin last week, however selecting a Product still takes eight seconds and more between selection and final response from the browser.
Comment 10•23 years ago
|
||
*** Bug 87778 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
Is nobody working on this? I'd like to stress how bad this is for QA who have to query over and over bugzilla - it also makes reporters lazy when doing queries to bugzilla - a lot of dupes are generated by reporting without querying, but hey, it 's hard to query if it takes 10 seconds just to select a product.
I think rod fixed some of the problems as part of bug 53165. We should re-profile to see where the time is spent now. (Last time I checked with my patch above, a lot of time was spent in the script security manager.)
Comment 13•23 years ago
|
||
linux, build 2001070209 Rendering apparently is done in a single reflow now, but it is very very slow. Mozilla hangs for a few seconds after selecting a program. This bug really hampers QA, i will therefore nominate it for mozilla1.0, although I would much prefer having it fixed for 0.9.3.
Keywords: mozilla1.0
Assignee | ||
Updated•23 years ago
|
Target Milestone: Future → mozilla0.9.3
Comment 14•23 years ago
|
||
*** Bug 89354 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 15•23 years ago
|
||
This has improved since the latest bugzilla update and it shouldn't be an issue anymore. Are all possible reflow batching /dhtml issues filed as seperate bugs? In this case I suggest marking this bug INVALID or WORKSFORME.
Comment 16•23 years ago
|
||
While bugzilla updates may make this issue less painful, it is a problem in mozilla and has to be addressed. We cannot afford rendering certain pages 4x slower than Netscape 4.77 if we ever want people to make the switch and use mozilla instead.
Comment 17•23 years ago
|
||
I'm marking this WORKSFORME based on the bugzilla update based on my work on bug 96534, and also based on rjesup's bug on select insertion optimization for 97345. Reporter, keep an eye on that bug, and file another (more specific, or clearly stated) report for additional problems.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 18•23 years ago
|
||
It's definitely worlds better in the 8/31 build!
You need to log in
before you can comment on or make changes to this bug.
Description
•