Each layer type goes through a process during a transaction that's something like (i) update content; (ii) paint to target. Instead of the second step, shadowable layers instead prepare to forward themselves to their shadows. It would be useful to measure the time taken for each step. More interesting numbers can be cleaned by taking advantage of the layer tree structure. From that, we could create a profiler-style tree of "self" and "total" times for each subtree.
This would be a killer feature in combination with layerscope.
I agree. If we make this generic enough this data could also be picked up the profiler similar to how it picks up GC/CC events.
Hi I am new to Mozilla development and am interested in working on this bug. Could I get it assigned to me and some guidance on resolving it?
What part of the CORE code base would I need to work in for this bug?
Hey, is this still a bug? If yes can I work on this. I'm a beginner. So can u please guide me through this?
Sorry this is probably not a good bug since it's 6 years old and the scope is fairly vague unless someone wants to jump in an mentor. The good first bug tagged should of been cleaned up given how old this bug is. But maybe mstange can chime in since he's working on perf tools ATM.
Whiteboard: [good first bug]
Hi George, thank you for your interest in working on this. However, I recommend you find a different bug, because I don't think we still want this. We currently don't have a good way to expose tree-like timing information to the profiler. We're working on adding that infrastructure, though, so we can revisit this bug once we have that. That said, I find it hard to believe that having per-layer timing information is useful when debugging performance problems. Usually all you need is the total time spent in layer forwarding, and maybe the number of layers.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.