My knowledges about chromium code base don't let me to investigate it properly way. I see you have written that string about Composite Layers, this means you may know reasons when Composite Layers appears in dev-tools. So my curiosity is why does mousemove cause appearing Composite Layers unlike mouseclick. Nowhere in the internet about it hasn't written.
By the way in first respond, you wrote: "*One of the steps of the rendering update is "see if we should make any changes to the set of composited layers" -- that is the "Composite Layers" step. Even if the answer is "no, the current set of composited layers is fine", we will *still* show that step in the performance data (but it should be very fast).*" - it's confusing. From this it follows that this Composite Layers bar must appear in every frame but it is not that. So there are conditions when you don't display that bar. And turns it out that events mousemove and mouseclick are different. I would like to know why one of them is cause of appearing Composite Layers unlike of another one. воскресенье, 7 августа 2022 г. в 02:58:48 UTC+10, Stefan Zager: > On Fri, Aug 5, 2022 at 11:36 PM Maxim Vaarwel <[email protected]> wrote: > >> I noticed that mousemove events are dispatched at the beggining. I've >> done the test with only clicks and I did not saw Composite Layers bars. >> Hmm... >> > > If you would like to investigate further, this is the place in the code > where the Composite Layers item is generated: > > > https://source.chromium.org/chromium/chromium/src/+/main:cc/trees/proxy_main.cc;drc=e38344e4c69d8d0ce782b17b0609e2508928da58;l=346 > > >> >> суббота, 6 августа 2022 г. в 15:16:53 UTC+10, Stefan Zager: >> > The confusion may be this: mousemove events are always dispatched at the >>> beginning of a rendering update, that's why it looks like the Composite >>> Layers item is associated with the mousemove event. Click events are >>> dispatched separately from rendering updates. I would guess there are >>> Composite Layers items in the clicking profile, but just not adjacent to >>> the event handlers. >>> >>> On Fri, Aug 5, 2022, 8:05 PM Maxim Vaarwel <[email protected]> wrote: >>> >>>> Stefan Zager, you are a little bit didn't understand me. You wrote: "*if >>>> you're clicking quickly -- let's say 5 times per second -- at 60Hz, that >>>> still means the browser can skip 55 out of a possible 60 rendering updates >>>> per second*". But these 5 clicks don't do Composite Layers unlike >>>> mousemove events. What a sense? >>>> суббота, 6 августа 2022 г. в 07:25:30 UTC+10, Stefan Zager: >>>> >>> On Fri, Aug 5, 2022 at 12:41 PM Maxim Vaarwel <[email protected]> wrote: >>>>> >>>>>> Hello, Stefan Zagar. Could you explain then to me one thing? If >>>>>> dev-tools shows bars named as Composite Layers every time when we use >>>>>> display's hardware. Then why don't I see them when I hold my mouse >>>>>> pointer >>>>>> on one point and do clicks? Also why I don't see Composite Layers bars >>>>>> when >>>>>> I do nothing? That moment need to clarify. >>>>>> >>>>> >>>>> The browser will skip doing rendering updates entirely if nothing is >>>>> happening on the page and it's not receiving input events. Even if you're >>>>> clicking quickly -- let's say 5 times per second -- at 60Hz, that still >>>>> means the browser can skip 55 out of a possible 60 rendering updates per >>>>> second. But when you move the pointer, a mousemove is generated for >>>>> *every* >>>>> rendering update opportunity, so the browser will keep doing rendering >>>>> updates. >>>>> >>>>> >>>>> >>>>>> >>>>>> P.S Thanks for your respond. >>>>>> >>>>>> суббота, 6 августа 2022 г. в 03:40:07 UTC+10, Stefan Zager: >>>>>> >>>>>>> On Fri, Aug 5, 2022 at 10:05 AM Maxim Vaarwel <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Nowadays rendering chrome engine has been changed. >>>>>>>> >>>>>>>> For demonstrating new confusion moment: >>>>>>>> 1. Open a blank tab >>>>>>>> 2. Open dev-tools, next open Perfomance tab and run a recording >>>>>>>> performance >>>>>>>> 3. In process of the recording performance just doing moves by >>>>>>>> mouse on the blank page during 3sec or less (whatever you want) >>>>>>>> 4. Stop the recording performance >>>>>>>> 5. Look at the recorded data. >>>>>>>> 6. Find multiple Composite Layers bars >>>>>>>> >>>>>>>> What does mean Composite Layers now? Why is it invoked by chrome >>>>>>>> render engine if page absolutely clear? >>>>>>>> Why do Update Layers Tree (already it is Pre-Paint) also change? >>>>>>>> What does it actually do? >>>>>>> >>>>>>> >>>>>>> The biggest change since 2019 is that we have completed the >>>>>>> CompositeAfterPaint (CAP). The Life of a Pixel slides refer to CAP; >>>>>>> anything in the slides that says "this will be different when we finish >>>>>>> CAP" is now working the CAP way. >>>>>>> >>>>>>> Every time you move the mouse, we have to figure out whether to >>>>>>> dispatch a mousemove event. To do that, we have to do a hit test to >>>>>>> determine what DOM object is under the mouse pointer. To do that, we >>>>>>> have >>>>>>> to make sure the rendering information is up-to-date at least as far as >>>>>>> the >>>>>>> Pre-Paint step. That's why you see a sequence of [ Pre-Paint, Hit Test, >>>>>>> Event: mousemove ] in the performance recording. >>>>>>> >>>>>>> If you're using display hardware with a refresh rate of 60Hz, we >>>>>>> attempt to do a full rendering update every 16.7ms. One of the steps of >>>>>>> the >>>>>>> rendering update is "see if we should make any changes to the set of >>>>>>> composited layers" -- that is the "Composite Layers" step. Even if the >>>>>>> answer is "no, the current set of composited layers is fine", we will >>>>>>> *still* show that step in the performance data (but it should be very >>>>>>> fast). That is what you're seeing. >>>>>>> >>>>>>> >>>>>>>> пятница, 26 июля 2019 г. в 02:51:34 UTC+10, [email protected]: >>>>>>>> >>>>>>>>> Hi Prashant, >>>>>>>>> >>>>>>>>> The terminology in devtools timeline items is somewhat misleading. >>>>>>>>> >>>>>>>>> *Update Layer Tree* is currently measuring two things: >>>>>>>>> >>>>>>>>> - Blink compositing update (decides which PaintLayers should be >>>>>>>>> composited, allocates or clears their CompositedLayerMapping, creates >>>>>>>>> and >>>>>>>>> sets geometry and other properties of GraphicsLayers) >>>>>>>>> >>>>>>>>> - prepaint tree walk (issues paint invalidations on the layout >>>>>>>>> objects, and builds paint property trees) >>>>>>>>> >>>>>>>>> *Update Layer* is measuring some of the bookkeeping that occurs >>>>>>>>> in between paint and commit (PictureLayer::Update). I think the main >>>>>>>>> thing >>>>>>>>> this is doing is copying paint ops out of the DrawingDisplayItem >>>>>>>>> (which was >>>>>>>>> created during paint) and into the PictureLayer's RecordingSource (so >>>>>>>>> that >>>>>>>>> the commit can transfer them into the PictureLayerImpl's >>>>>>>>> RasterSource). >>>>>>>>> >>>>>>>>> *Composite Layers* is actually the time that the main thread >>>>>>>>> spends waiting for the commit to finish on the compositor thread. I >>>>>>>>> agree >>>>>>>>> it should instead be named "Commit Layers". >>>>>>>>> >>>>>>>>> At least this is what I have gathered from inspection; others who >>>>>>>>> know more may correct me. >>>>>>>>> >>>>>>>>> Some of this will change with the launch of CompositeAfterPaint. >>>>>>>>> >>>>>>>>> On Tue, 23 Jul 2019 at 22:04, Prashant Palikhe <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I am a frontend dev trying to understand the guts of Blink/Chrome >>>>>>>>>> in order to get a grasp on how the code that I write gets converted >>>>>>>>>> into >>>>>>>>>> pixels on the screen. >>>>>>>>>> >>>>>>>>>> I have read several Chromium docs like >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://www.chromium.org/developers/design-documents/compositor-thread-architecture >>>>>>>>>> >>>>>>>>>> https://chromium.googlesource.com/chromium/src/+/master/docs/how_cc_works.md#raster-and-tile-management >>>>>>>>>> >>>>>>>>>> and watched the brilliant talk by Steve Kobes on Life of a pixel >>>>>>>>>> <https://www.youtube.com/watch?v=w8lm4GV7ahg> >>>>>>>>>> >>>>>>>>>> I am trying to correlate the findings from these sources with the >>>>>>>>>> findings from my own experiments. I have been able to do so for most >>>>>>>>>> of the >>>>>>>>>> things except for >>>>>>>>>> >>>>>>>>>> 1. Update layer >>>>>>>>>> 2. Update layer tree >>>>>>>>>> 3. Composite layers >>>>>>>>>> >>>>>>>>>> These are my understanding so far. And I would like to be either >>>>>>>>>> validated or corrected. >>>>>>>>>> >>>>>>>>>> *Update layer* >>>>>>>>>> >>>>>>>>>> Not really sure what's going on here. Seems like part of >>>>>>>>>> painting. But what does it really mean? >>>>>>>>>> >>>>>>>>>> *Update layer tree* >>>>>>>>>> >>>>>>>>>> To me it seems like this is when the impl side layer tree changes >>>>>>>>>> are applied onto the layer tree on Blink. E.g. after scroll or >>>>>>>>>> pinch/zoom >>>>>>>>>> interactions. >>>>>>>>>> >>>>>>>>>> But if I read Paul's tweet from a while ago, >>>>>>>>>> https://twitter.com/aerotwist/status/498878547378053120?lang=en >>>>>>>>>> >>>>>>>>>> I am not so sure anymore. What is exactly happening here? >>>>>>>>>> >>>>>>>>>> *Composite layers* >>>>>>>>>> >>>>>>>>>> To me this is really confusing since composition is no longer >>>>>>>>>> main thread concept. So why does it even appear in main thread time >>>>>>>>>> line. >>>>>>>>>> >>>>>>>>>> To me it seems like this is when the main thread layer tree is >>>>>>>>>> committed to the compositor. This is initiated by the CC with the >>>>>>>>>> main >>>>>>>>>> thread blocked. >>>>>>>>>> >>>>>>>>>> If this is true, it seems like "composite layers" is not a right >>>>>>>>>> name. It would make more sense to have "commit layers" e.g. >>>>>>>>>> >>>>>>>>>> But maybe my assumptions are wrong. >>>>>>>>>> >>>>>>>>>> Hope to get clarity on these subjects. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to [email protected]. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/58b2a915-7a7d-453f-8196-7867cc58892d%40chromium.org >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/58b2a915-7a7d-453f-8196-7867cc58892d%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4349db93-593c-43f8-87ec-374206cc9b1an%40chromium.org >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4349db93-593c-43f8-87ec-374206cc9b1an%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/88c34aeb-c3fc-498f-b428-a215a1aab865n%40chromium.org.
