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...
суббота, 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/0fc8fd1a-5d29-4462-86b0-62a7e009db8an%40chromium.org.
