902418 - Add more tools to debug layerization

Status: RESOLVED WONTFIX

(Core :: Graphics: Layers, defect)

Description

[Nicolas Silva [:nical]]

Safari has good tools to inspect the way a given web page is layerized. We should improve our own tools in this area. Right now we only have (on OMTC platforms) an option to display the layer and tile borders. Web devs are interested in having more information like for each layer how much memory it represents and why it has been been layerized.

A quick way to improve the situation could be to improve the MOZ_DUMP_PAINTING code that lets us dump the layer tree in a html file and make it easy for developers to trigger a dump of the current page's layer tree.

In the long run should do some proper devtools integration for things like that.

Comment 1

[Nick Cameron [:nrc]]

I had a patch for doing some fancy things kind of like this (a better MOZ_DUMP_PAITING). The idea was to dump JSON for each layer (tranform, opacity, etc.) and a PNG of the layer. Then I had a web page which assembled it all back together. I was going to add things to highlight all kinds of info about the layers. The nice thing was you could (theoretically) run it for the content thread so you could see if a bug was there or on the compositor. I thought it would be of much more use for Gecko devs than web devs though. If anyone wants to look at this I can dust off my patches (I never got round to finishing it because I thought it was too low priority and got the info in other ways).

Anyway, I'm not convinced how useful more layers is for web devs. Memory per layer would be great, but I'm not sure what it really means or how we would calculate it - do we have any concept of which DOM elements or JS memory is associated with a layer? We layerise so little that I'm not sure how useful reasons are. And more to the point, the number of cases where people should care is pretty small.

If we want to provide useful feedback about gfx stuff for web devs we should focus on info about reflow and other layout stuff - which matters a lot more.

Comment 2

[Nicolas Silva [:nical]]

The kind of stuff I hear a lot about from Gaia devs is cases where the UI generates too many layers, and they try to reduce it.
Today it was the everything.me stuff that contained too many layers and Vivien was trying to reduce it. Another problem they are having is icons in everything.me that go back and forth between being layerized and merged back into the background thebes layer as you scroll. It makes scrolling a bit janky. The layer border helps seeing that stuff is going on but sometimes they need to understand why things get layered.
Web apps and Gaia tend to have more layers than typical web pages.

I agree about layout stuff, but I know that Gaia guys need to optimize at the layer level too.

I don't think we have concepts of which DOM nodes are associated with which layers (webkit devtools do, and Rik from the Gaia team told me he would love to have similar features), but it would not be too hard I think to categorize the different heuristics for layerization and pass a flag to the layers when we create them saying which heuristic caused its creation (without referring to DOM elements which would mean a lot more work).

That's a low enough hanging fruit that we can do it, if only for web apps people.

Comment 3

[Nick Cameron [:nrc]]

(In reply to Nicolas Silva [:nical] from comment #2)
> The kind of stuff I hear a lot about from Gaia devs is cases where the UI
> generates too many layers, and they try to reduce it.
> Today it was the everything.me stuff that contained too many layers and
> Vivien was trying to reduce it. Another problem they are having is icons in
> everything.me that go back and forth between being layerized and merged back
> into the background thebes layer as you scroll. It makes scrolling a bit
> janky. The layer border helps seeing that stuff is going on but sometimes
> they need to understand why things get layered.
> Web apps and Gaia tend to have more layers than typical web pages.
> 
> I agree about layout stuff, but I know that Gaia guys need to optimize at
> the layer level too.

This scares me.

> 
> I don't think we have concepts of which DOM nodes are associated with which
> layers (webkit devtools do, and Rik from the Gaia team told me he would love
> to have similar features), but it would not be too hard I think to
> categorize the different heuristics for layerization and pass a flag to the
> layers when we create them saying which heuristic caused its creation
> (without referring to DOM elements which would mean a lot more work).
> 

Sorry, the DOM node stuff was with reference to having memory per layer, which I don't think we can do. It doesn't affect outputing reasons for layerisation, which I think we can do.

> That's a low enough hanging fruit that we can do it, if only for web apps
> people.

This is probably true. I fear that the underlying reasons might just be that our layerisation algorithm is not optimal for web apps and we need to tweak it. Encouraging web devs to hack around this is going to make things worse in the long run. Probably that should not stop us doing this in the short run, I guess. It is as you say, low hanging fruit.