149216 - [DHTML] Style resolution optimization

Status: RESOLVED WONTFIX

(Core :: DOM: CSS Object Model, defect)

Description

[Markus Hübner]

--- from bug 64516 #21 ---
Script is modifying the style attribute via the DOM, which is causing a lot of
extra work since we have to reresolve style on the element, not knowing what
actually changed in the style attribute.

Buster had an idea that maybe we can be smarter about handling changes to the
style attribute, like looking at what has changed and restricting the impact
when possible. For example, if it is just the position of an element chaning we
cna optimize to move the element, and avoid the need to reresolve style and do
the style-change reflow...

Comment 1

[Markus Hübner]

Reassigning ...

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This isn't as simple as you think.

We definitely do need to have the correct data in the style context, but we
might be able to do that with more selective clearing of data (only certain
structs).  This would require that we (at compile time, using macros) build a
map of which structs influence which other structs.

Furthermore, there are cases where moving positioned element offsets does more
than just move things -- consider absolutely positioned elements with a 'right'
and a 'left', or consider absolutely positioned elements inside something with
'overflow: auto' (like the BODY) whose movement would require the extent of the
scrollbars to change.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

-> default owner

Comment 4

[Markus Hübner]

When bug 157681 is fixed this might become easier.
Anyone willing to take this?

Comment 5

[Markus Hübner]

Is part of this covered by the layout architecture rewrite plans?

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is probably best done by keeping the style reresolution, since the children
could be using "inherit" and thus need to get their style reresolved anyway. 
The direction to go would, imo, be to have finer-grained reflow-like hints
(resize, reposition, reflow, maybe?)

Comment 7

[Markus Hübner]

Due to the arch changes in the last month has there been any changes in view 
of this approach?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think trying to do things like this would cause lots of bugs (like we had
before we moved to immutability) and I'm not convinced that the performance of
style resolution itself is a frequent performance problem.

->wontfix