caseq@ what do you think about removing blink::InspectorLayerTreeAgent or keeping it as another code path besides Performance/Frames/Layers?
The following is copied from my pose to devtools team:
It seems that DevToolsMenu -> More tools -> Layers uses blink::InspectorLayerTreeAgent. I didn't find it because I thought the "Console" menu contains all items of "More tools" and didn't notice that "Layers" is an exception.
The Layers panel seems to have some features that the Performance/Frames/Layers doesn't have, e.g. real time layer tree update and DOM ids. However, I wonder how many people are using the Layers panel and if it can be substituted with Performance/Frames/Layers. If we remove blink::InspectorLayerTreeAgent, we can just have one code path for layer information instead of two. To me Performance/Frames/Layers seems a good substitution of the Layers panel. (Actually I didn't know these features before I started to work on the related code in blink. I always used frame viewer in about:tracing for the same information).
What do you think about removing blink::InspectorLayerTreeAgent?
I think so -- these are not based on the InspectorLayerTreeAgent, execept for some bits of the paint profiler. Not sure how relevant the Paint Profiler is nowadays, considering slimming paint and then GPU rasterization -- maybe Xianzhu can comment on that.
Yes. The main reason is that the Layers panel needs a new implementation of InspectorLayerTreeAgent for CompositeAfterPaint, while Performance/Frames/Layers which is based on cc::LayerImpl works just fine CompositeAfterPaint. Do you have usage data of the Layers panel? If many people are using it, perhaps we'd better keep it. Otherwise we can save some work.
> Not sure how relevant the Paint Profiler is nowadays
I don't perf audit as much as I used to, but paint cost (rasterization cost specifically?) rarely comes up as a bottleneck. So I'm pretty comfortable setting Paint Profiler out to pasture.
> do you think we can nuke the Layers panel?
I do still find a lot of justification for exploring the Layer Tree. "Update Layer Tree" is often quite expensive and comparing DOM against Layers is the only technique I know to reduce cost.
Getting live updates however isn't very important. So I think the Layers panel would deliver all the same value if the user had to request a new snapshot. (It'd also solve the perf issues). With that change to the UX, could the layers panel migrate to cc::LayerImpl, perhaps via capturing a short trace?
I don't think we can remove the useful tool without offering a replacement. I just searched for "devtools layers panel" and found a bunch of useful videos and tutorials. What is the cost of switching it to the cc layers? Can cc layers still be used in an actionable manner to improve rendering performance?
Thanks for replies. Now I know that the Layers panel is still useful and I agree to keep it.
Actually I already have a CL to migrate InspectorLayerTreeAgent to cc::Layer: https://chromium-review.googlesource.com/c/chromium/src/+/1391351 which already works for common cases. Will continue to make it fully work.
cc::Layer and blink::GraphicsLayers are almost 1:1 mapping so they provide the same manner for rendering performance. In CompositeAfterPaint we no longer have GraphicsLayers.
Comment 1 by wangxianzhu@chromium.org
, Dec 26Cc: flackr@chromium.org
Labels: -Pri-3 Pri-2
Owner: wangxianzhu@chromium.org
Status: Assigned (was: Available)