Consider flushing layout in a more fine-grained way in getComputedStyle.
Categories
(Core :: CSS Parsing and Computation, enhancement, P3)
Tracking
()
People
(Reporter: emilio, Assigned: emilio)
References
(Regressed 1 open bug)
Details
(Keywords: perf)
Attachments
(8 files, 1 obsolete file)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1404140 - Return early when trying to flush to get the style of a disconnected element. r=heycam
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
I happened to be reading some more Blink code today, and I think we could borrow another of their getComputedStyle optimizations. In particular, we could borrow [1] without too much effort I think. Instead of flushing layout from the beginning, we should consider flushing frames instead first, and then: * Only flush layout if the element has a primary frame. * Don't flush layout for properties if the property is fixed (in a per-property / per-frame basis). They don't use this for stuff like width / height which may be affected by other properties like max-width / max-height. Not sure how worth it really is, I guess it depends on the content, but seems worth looking into. [1]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/CSSComputedStyleDeclaration.cpp?l=195&rcl=dc902f206d55e0d226fb7072ad383d1c2974073f
Assignee | ||
Updated•7 years ago
|
Updated•7 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 2•6 years ago
|
||
Did ^ because I _think_ we're back to using [qf] again, but let me know if not.
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
One situation where this would be valuable is when setting the dimensions of multiple elements using jQuery's .height() and .width().
Depending on the value of box-sizing, its setters can read padding and border-width, so doing this thrashes in Firefox and IE but not Safari or Chrome.
Assignee | ||
Comment 4•5 years ago
|
||
(In reply to mattheww from comment #3)
One situation where this would be valuable is when setting the dimensions of multiple elements using jQuery's .height() and .width().
Depending on the value of box-sizing, its setters can read padding and border-width, so doing this thrashes in Firefox and IE but not Safari or Chrome.
Just reading height thrashes layout though, doesn't it? (If the element is actually displayed, I mean)
Do you have a test-case I could profile? That'd be immensely useful to justify me working on this :)
I worded that confusingly, sorry!
When you call $("#myElement").height(1234)
, jQuery will:
- Read
box-sizing
(fine in all browsers) - Sometimes read
padding-top
/padding-bottom
(depending on box-sizing) - Write
height
I ran into this while rewriting some slow code that lined up two separate tables by copying row heights from one to the other. I uploaded a test-case doing the same thing to https://wartmanm.github.io/debugger-benchmarks/jquery-height.html.
I can imagine someone testing in only one browser, and stopping at copyHeights2, without realizing they hadn't solved the problem. But that didn't happen in this case, and I don't have any evidence that it's ever happened. Plus, I didn't spot it until now, but the documentation specifically warns that .height() can be slow: https://api.jquery.com/height/#entry-longdesc
So I don't know if this purely hypothetical scenario is worth it, really :(
Assignee | ||
Comment 6•5 years ago
|
||
I think we should fix this. transform
can have an even nicer optimization which Blink and WebKit don't have, which is that we don't need to update layout if the transform doesn't have any percentage...
Over to the queue.
Assignee | ||
Comment 7•5 years ago
|
||
Assignee | ||
Comment 8•5 years ago
|
||
Depends on D40250
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D40293
Assignee | ||
Comment 10•5 years ago
|
||
Depends on D40294
Assignee | ||
Comment 11•5 years ago
|
||
Depends on D40295
Assignee | ||
Comment 12•5 years ago
|
||
We just don't return a styles for them anyway, and this simplifies the following
patches a bit.
Depends on D40296
Assignee | ||
Comment 13•5 years ago
|
||
We still don't optimize out the second based on the results of the first, but I
plan to do that in a bit. That's what this bug is about anyway.
Depends on D40297
Assignee | ||
Comment 14•5 years ago
|
||
Depends on D40298
Assignee | ||
Comment 15•5 years ago
|
||
Depends on D40299
Comment 16•5 years ago
|
||
Comment on attachment 9082390 [details]
Bug 1570721 - Add a content viewer API to emulate color scheme. r=bzbarsky
Revision D40250 was moved to bug 1570721. Setting attachment 9082390 [details] to obsolete.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 17•5 years ago
|
||
Assignee | ||
Comment 18•5 years ago
•
|
||
Err, wrong bug, but it also contains these patches so oh well.
Comment 19•5 years ago
|
||
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/2c3c8a5e1c74 Fix non-unified build bustage in nsComputedDOMStyle.cpp r=heycam https://hg.mozilla.org/integration/autoland/rev/6c76dadbf66b Cleanup initialization of nsComputedDOMStyle::mFlushedPendingReflows. r=heycam https://hg.mozilla.org/integration/autoland/rev/517527a3c682 Rename nsComputedDOMStyle::NeedsToFlush to NeedsToFlushStyle. r=heycam https://hg.mozilla.org/integration/autoland/rev/c4e1b1cdd8ce Factor out getting the outer and inner frame. r=heycam https://hg.mozilla.org/integration/autoland/rev/e4797359e806 Return early when trying to flush to get the style of a disconnected element. r=heycam https://hg.mozilla.org/integration/autoland/rev/43ac67d814d4 Refactor nsComputedDOMStyle::UpdateCurrentStyleSources so that it happens in two flushes, not one. r=heycam https://hg.mozilla.org/integration/autoland/rev/b568a2a21f56 Don't flush layout for layout-dependent properties if we know that it won't affect the result. r=heycam https://hg.mozilla.org/integration/autoland/rev/abe0d15df80f Remove the GetCSNeedsLayoutFlush flag, as it is unneeded now. r=heycam
Comment 20•5 years ago
|
||
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/dedea6ad59f9 followup: Avoid busting GCC base toolchain jobs which warn about a debug-only variable.
Comment 21•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2c3c8a5e1c74
https://hg.mozilla.org/mozilla-central/rev/6c76dadbf66b
https://hg.mozilla.org/mozilla-central/rev/517527a3c682
https://hg.mozilla.org/mozilla-central/rev/c4e1b1cdd8ce
https://hg.mozilla.org/mozilla-central/rev/e4797359e806
https://hg.mozilla.org/mozilla-central/rev/43ac67d814d4
https://hg.mozilla.org/mozilla-central/rev/b568a2a21f56
https://hg.mozilla.org/mozilla-central/rev/abe0d15df80f
https://hg.mozilla.org/mozilla-central/rev/dedea6ad59f9
Updated•2 years ago
|
Description
•