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.
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/00d5a4ef-7529-4cc6-94ef-df7a89741852n%40chromium.org.
