stylo: use invalidation framework to handle restyles needed in response to content insertion/removal

NEW
Assigned to

Status

()

enhancement
P2
normal
2 years ago
5 months ago

People

(Reporter: heycam, Assigned: emilio, NeedInfo)

Tracking

(Blocks 3 bugs)

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 wontfix)

Details

(Whiteboard: [qf:p2:responsiveness])

Reporter

Description

2 years ago
Currently we respond to content modifications needing to restyle elements due to slow selector flags by posting restyles.  For example, when we append a new element to a parent that is marked as having a child that needs :last-child matched, we'll post an eRestyle_Subtree on the old last child.  It seems like we should be able to use invalidations to do more targeted restyling.
Yes, indeed! I thought about this before, and this would allow us to avoid the selector_flags_map, and the flags_setter, which is nice.
Assignee

Updated

2 years ago
See Also: → 1407022
Assignee

Updated

a year ago
See Also: → 1443066
So I thought a bit more about how to do this, and of course it's not an easy fix, but it's not impossible either.

The problem is that we can't invalidate style synchronously during the DOM mutation, because that can get out of sync with class changes and what not.

So the proper way to fix this, I think, is to teach the snapshot stuff about positional pseudo-classes. For that, we could make the snapshots have an "old next / prev" sibling, that would allow us to reconstruct the old sibling chain.

So it'd be something like, for positional pseudo-classes, snapshot the prev and next siblings on DOM insertion / removal. Then the invalidation machinery would take over and invalidate other stuff if needed as it does for attribute changes.

For :empty / :-moz-only-whitespace it's a bit more annoying, because we need to snapshot the parent, but I think it's not much harder than that / making the snapshot aware of whether it was empty.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #2)
> For :empty / :-moz-only-whitespace it's a bit more annoying, because we need
> to snapshot the parent, but I think it's not much harder than that.

Hmm, well, it might, because we'd need to compute accurately whether :empty / :-moz-only-whitespace have changed...
I think the only way to fix this in a sane way is either snapshotting previous parent / siblings of the DOM element, or just ditching the "invalidate during the traversal" stuff and do it sync. But that's kind of a pity.
Blocks: layout-perf
Assignee

Comment 5

11 months ago
A somewhat mixed alternative would be to collect the invalidations sync, and invalidate during the traversal... That may be a good trade-off I guess.
Assignee

Comment 6

10 months ago
I have better ideas I think...
Assignee

Comment 7

10 months ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=134f68176227a35007c081873dc34abbbf6caee7 is the try run.

https://treeherder.mozilla.org/perf.html#/compare?originalProject=mozilla-central&newProject=try&newRevision=025022534e4252dd20852d76af2a7ef161e6ea2a&framework=1&selectedTimeRange=172800 is the talos push.

I didn't remove the selector flags setters and stuff but I should... I left them just in case they were needed to make stuff faster, though so far talos hasn't showed anything ridiculous.

This should fix bug 1480477 & co. There's a bunch of tricky invalidation test-cases I want to land.

Also I think I haven't handled :empty invalidation yet, but that should be trivial compared to :nth-child & co.
Assignee: nobody → emilio
Blocks: 1480477
Assignee

Comment 8

10 months ago
Also, some more cleanup can be done too afterwards.
Assignee

Comment 10

10 months ago
Looks like I have some perf work to do if I really want to get rid of the slow selector flags... Stylebench isn't happy about this:

  https://treeherder.mozilla.org/perf.html#/comparechooser?newProject=try&newRevision=e0bc980ed752fdc00a810ad09ac942351f35cd22
Assignee

Updated

10 months ago
Depends on: 1481155
Assignee

Updated

10 months ago
Depends on: 1481156
Assignee

Updated

10 months ago
Depends on: 1481162
Assignee

Comment 11

9 months ago
Boris, friendly ping regarding your feedback on the style invalidation? Let me know if you don't have cycles to look into it and I'll just write patches :P
Flags: needinfo?(bzbarsky)
Assignee

Comment 12

9 months ago
(Adjusting priority since it blocks bug 1480477)
Priority: P4 → P2
Sorry, I've been on unexpected PTO most of this week...  I won't really be back to work until Tuesday morning.  I will definitely try to look at this then.
Whiteboard: [qf:p1:f64]

--> retriaging as [qf:p2:responsiveness] since qf:p1 is now reserved for pageload, and it sounds like this bug is mostly about reacting to dynamic changes.

Whiteboard: [qf:p1:f64] → [qf:p2:responsiveness]
You need to log in before you can comment on or make changes to this bug.