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/1cc8542e-22a7-45d6-9b86-3f45d86bf1b2n%40chromium.org.
