One more difference, which is related the the points Stefan makes: - MouseMove events always dispatch once per vsync, as the first step of a rendering task (before requestAnimationFrame callbacks). It seems like the act of having a registered MouseMove event listener forces scheduling a whole rendering task (because these are rAF-aligned events and need to fire here). - However, discrete events, such as click, run eagerly in their own task. If the click handler *does not change the page visually* (i.e. does not apply changes to dom/styling), we will not need to schedule a new rendering task at all. So, there will not be a CompositeLayers step in the same task ever, and there may not be one later if you don't actually damage the page.
On Sat, Aug 6, 2022 at 12:58 PM Stefan Zager <sza...@chromium.org> wrote: > On Fri, Aug 5, 2022 at 11:36 PM Maxim Vaarwel <palosh...@gmail.com> 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 <palo...@gmail.com> 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 <palo...@gmail.com> 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 <palo...@gmail.com> >>>>>>> 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, sko...@chromium.org: >>>>>>>> >>>>>>>>> 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 <prash...@gmail.com> >>>>>>>>> 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 blink-dev+...@chromium.org. >>>>>>>>>> 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 blink-dev+...@chromium.org. >>>>>>>> >>>>>>> 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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-ejC%2BBho4TuVFpv5yjuTUa2tnLA6N7euj_35dUKZBaXQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-ejC%2BBho4TuVFpv5yjuTUa2tnLA6N7euj_35dUKZBaXQ%40mail.gmail.com?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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEeF2TfcZ-CmYZJVZA4-_fpQNdZ3w2Wa0%3DD6NUgZKgQdazPxtQ%40mail.gmail.com.
