What are "Update layers", "Update layer trees" and "Composite layers" in Chrome devtools

[Prashant Palikhe]

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

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

[Steve Kobes]

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.

--
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.

[Maxim Vaarwel]

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?

пятница, 26 июля 2019 г. в 02:51:34 UTC+10, sko...@chromium.org:

[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.

 

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.

[Maxim Vaarwel]

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:

[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.

[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:

[Stefan Zager]

On Fri, Aug 5, 2022 at 11:36 PM Maxim Vaarwel <palo...@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:

[Michal Mocny]

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.

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.

[Maxim Vaarwel]

My knowledges about chromium code base don't let me to investigate it properly way. I see you have written that string about Composite Layers, this means you may know reasons when Composite Layers appears in dev-tools. So my curiosity is why does mousemove cause appearing Composite Layers unlike mouseclick. Nowhere in the internet about it hasn't written.

By the way in first respond, you wrote: "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)." - it's confusing. From this it follows that this Composite Layers bar must appear in every frame but it is not that. So there are conditions when you don't display that bar. And turns it out that events mousemove and mouseclick are different. I would like to know why one of them is cause of appearing Composite Layers unlike of another one.

воскресенье, 7 августа 2022 г. в 02:58:48 UTC+10, Stefan Zager:

[Maxim Vaarwel]

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:

[Maxim Vaarwel]

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.