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/CAHOQ7J-ejC%2BBho4TuVFpv5yjuTUa2tnLA6N7euj_35dUKZBaXQ%40mail.gmail.com.
