Closed
Bug 55967
Opened 24 years ago
Closed 21 years ago
[FIX]handling of "align" attribute change is slow
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla1.6beta
People
(Reporter: buster, Assigned: bzbarsky)
References
()
Details
(Keywords: perf)
Attachments
(2 files)
|
2.75 KB,
text/html
|
Details | |
|
1.57 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
currently, we always reframe when an [img|object|table] has it's align attribute changed via the DOM (as with javascript, or in the editor.) we should be smart enough to only reframe when going from [no align attribute] to [any value for align attribute] or vice versa. we should just reflow if the align attribute already exists and we're just changing it's value, ie "left" to "right" This is spun off of bug 55250
operation is infrequent enough that this isn't a dogfood or rtm issue. marking future. strictly a performance improvement.
Comment 2•24 years ago
|
||
If "align" is set to an invalid value, for example "no", then I believe (untested) that we just treat it as if the align attribute is missing. Thus when doing this optimisation, we should make sure that we reflow if the value changes to a valid value, and reframe if it changes to an invalid value or is removed altogether. (This all assumes that I am right about our handling of invalid values, of course.)
Comment 3•23 years ago
|
||
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: ASSIGNED → NEW
Comment 4•21 years ago
|
||
->Misc Code
Assignee: attinasi → misc
Component: Layout → Layout: Misc Code
QA Contact: petersen → nobody
| Assignee | ||
Updated•21 years ago
|
OS: Windows NT → All
Priority: P3 → --
Hardware: PC → All
Target Milestone: Future → ---
| Assignee | ||
Comment 5•21 years ago
|
||
We haven't pointlessly reframed on "align" changes since dbaron fixed bug 211308. Now we compute the new style context and only reframe if the style difference says to. On the other hand, it looks like nsStyleDisplay::CalcDifference will reframe when float changes from left to right. I'll attach a patch to fix that, I guess.
Is that safe?
| Assignee | ||
Comment 7•21 years ago
|
||
| Assignee | ||
Comment 8•21 years ago
|
||
| Assignee | ||
Comment 9•21 years ago
|
||
Comment on attachment 135454 [details] [diff] [review] Possible patch David, what do you think?
Attachment #135454 -
Flags: superreview?(dbaron)
Attachment #135454 -
Flags: review?(dbaron)
| Assignee | ||
Comment 10•21 years ago
|
||
Taking, I guess.
Assignee: misc → bz-vacation
Priority: -- → P3
Summary: handling of "align" attribute change is slow → [FIX]handling of "align" attribute change is slow
Target Milestone: --- → mozilla1.6beta
| Assignee | ||
Comment 11•21 years ago
|
||
I'm not sure it's safe, to be truthful... I haven't been able to break it so far, though... and I don't believe we differentiate between left and right floats in the frame tree, only during reflow. Does nsBlockFrame cache left/right stuff somehow?
Attachment #135454 -
Flags: superreview?(dbaron)
Attachment #135454 -
Flags: superreview+
Attachment #135454 -
Flags: review?(dbaron)
Attachment #135454 -
Flags: review+
| Assignee | ||
Comment 12•21 years ago
|
||
Checked in. This makes the testcase I posted about 30% faster.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•