Kan-Ru Chen (陳侃如): > So in other words, we could do the following: > > (1) Collect the elements that have styles changed by comparing the rule > node or style context. We could report them to devtools and maybe also > list the changed style for each of them.
Yes. There might be some trickiness around keeping the old style context around, if we needed to provide that to devtools too. Providing just a list of elements whose styles changed should be simple. My feeling though is that (2) might help you more than (1). > (2) Record DOM manipulations and the restyle hints they generated via a > specific selector. Then count the element traversed while doing selector > matching. Also count the number of new style context resolved. We can > then sort the report by these numbers. > > Does this make sense? Something like this, although hopefully we can avoid recording what the DOM manipulations are, as there’d be many places in our DOM code we’d need to change. Looking at the restyle code, we do have some information being reported to the profiler. Here is where we record the backtrace for a restyle hint: https://dxr.mozilla.org/mozilla-central/rev/0b69d304f861d0038fb78f1d52b0f5d13ef7c6fe/layout/base/RestyleTracker.h#459 and here is where we report them: https://dxr.mozilla.org/mozilla-central/rev/0b69d304f861d0038fb78f1d52b0f5d13ef7c6fe/layout/base/RestyleTracker.cpp#349 https://dxr.mozilla.org/mozilla-central/rev/0b69d304f861d0038fb78f1d52b0f5d13ef7c6fe/layout/base/RestyleTracker.cpp#398 So maybe we can append the selector traversal counts and style context creation counts to it there. The backtrace should be enough to point at the particular DOM operation in the script that caused the restyle to be added. It looks like the data on the profiler tracing entry, besides the backtrace, is just a string. So I don’t know how feasible it is to report the particular style rules that caused a given restyle hint to be generated on it. Having just the selector traversal and style context creation count data on the profiler tracing entries will help you find which DOM operations caused the most expensive restyles, but they won’t tell you why, unless you know which style rule’s existence caused the particular restyle hint to be generated. Benoit: Does extending the tracing entry here with additional data sound like the right thing to do? Is it possible to attach a pointer to a refcounted object (the style rule) to the tracing entry, so that devtools could say add a link that jumps from the restyle tracing entry back to the rule in the style sheet? If not then I guess we could just serialize the selector and add it to the entry’s string data, which might be enough to go on. (Also I had a feeling we might already report nsRestyleHint values through the profiler somewhere – is that right?) -- Cameron McCormack ≝ http://mcc.id.au/ _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
