Layer scrolling can be rather expensive -- for example, scrolling gmail with 100 conversations per page is ca. 6ms, which is currently not accounted by timeline.
Created attachment 168931 [details] Patch
Comment on attachment 168931 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=168931&action=review r- for didScroll vs didScrollLayer > Source/WebCore/ChangeLog:8 > + - added timeline instrumentation for scrolling of a layer; What does it give to the user? Is there a way to address scrolling slowness? > Source/WebCore/inspector/InspectorInstrumentation.h:147 > + static void didScrollLayer(Frame*); What is the difference with didScroll ? > Source/WebCore/inspector/InspectorTimelineAgent.h:111 > + void willScroll(Frame*); Nit: we should come up with more dense way of instrumenting simple signals. > Source/WebCore/rendering/RenderLayer.cpp:1712 > + InspectorInstrumentation::willScrollLayer(frame); Is there a TRACE_EVENT for this? Should we start with tracing it there and add it into the instrumentation if it proves to be valuable?
(In reply to comment #2) > (From update of attachment 168931 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=168931&action=review > > r- for didScroll vs didScrollLayer > > Source/WebCore/ChangeLog:8 > > + - added timeline instrumentation for scrolling of a layer; > > What does it give to the user? It just closes the instrumentation gap -- we show where we spend considerable amount of time. > Is there a way to address scrolling slowness? There may be, but I imagine it's an effort of a different magnitude. I think there's still value in adding instrumentation for this first. > > Source/WebCore/inspector/InspectorInstrumentation.h:147 > > + static void didScrollLayer(Frame*); > > What is the difference with didScroll ? didScroll is for scrolling a view, while didScrollLayer is for scrolling a layer. The code paths appear to be somewhat different. It would be trivial to instrument both, but so far I failed to create a scenario where scrolling a view would be sufficiently slow, so the idea was to instrument only what we know to be slow. > > Source/WebCore/inspector/InspectorTimelineAgent.h:111 > > + void willScroll(Frame*); > > Nit: we should come up with more dense way of instrumenting simple signals. Totally agree. I do have some ideas for that, but I see this as a separate issue. > > Source/WebCore/rendering/RenderLayer.cpp:1712 > > + InspectorInstrumentation::willScrollLayer(frame); > > Is there a TRACE_EVENT for this? Should we start with tracing it there and add it into the instrumentation if it proves to be valuable? I did have it internally before adding inspector instrumentation. Will add to the patch as well.
Created attachment 168955 [details] Patch
Comment on attachment 168955 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=168955&action=review > LayoutTests/inspector/timeline/timeline-enum-stability-expected.txt:32 > + Scroll : "Scroll" ScrollLayer
Committed r132088: <http://trac.webkit.org/changeset/132088>