Re: CSS Engine Style Invalidation Strategy

On 7/28/13 9:19 PM, François REMY wrote:
>   * Each element has three sets of invalidating flags:
>   * Each set of invalidation flags contain four different flag sections:
>       o 64bits for IDs
>       o 64bits for Classes
>       o 64bits for Attributes
>       o 32bits for States (hover…)

So just to make sure: this is at least 84 bytes per element just for 
these flags, right?  (In practice, various state stuff doesn't actually 
fit in 32 bits; you need 64, so it would actually be 96 bytes.)

How does this handle DOM insertions and removals?

>   * Very efficient for things like “abc:hover def” when there’s no “def”
>     inside an “abc” because the “abc” will never be asked for
>     his “:hover” state from a child

Browsers already optimize this case; in the case of Gecko and WebKit by 
just having a single "is impacted by :hover selectors" flag.

>   * Very efficient at finding whether we should update the element
>     itself, its descendants or its whole sibling world

At the cost of having to keep track during selector matching exactly how 
the element you're matching right now is related to the subject of the 
selector, plus the significantly increased memory usage from those flag 
sets, right?

>   * Is ineffective for documents with a lot of unused selectors

Which are fairly common, actually.

>   * Potentially triggers a lot of memory writes during selector matching
>     (is that an issue?)

It sure can be if you want to parallelize selector matching; have to do 
it in a smarter way.

>   *  From the memory point of view?

Unclear.

>   *  From the efficiency point of view?

Possibly.

>   *  From the setup requirements point of view?

Not sure what you mean.

-Boris

Received on Tuesday, 30 July 2013 00:00:18 UTC