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•22 years ago
|
||
->Misc Code
Assignee: attinasi → misc
Component: Layout → Layout: Misc Code
QA Contact: petersen → nobody
![]() |
Assignee | |
Updated•22 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•7 years ago
|
Product: Core → Core Graveyard
Updated•7 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
•