kViewTransitionPseudoElement was needed for the same purpose (making layers identifiable) and might be a good pattern to copy (e.g., see view_transition_shared_element_id).
On Monday, November 14, 2022 at 2:35:51 PM UTC-8 Pea Wyllie wrote: > I did do that for testing and how I knew to use the Compositing Reasons; > but for my use case I need these layers to be specifically identifiable, so > I was using the attribute. > > On Monday, November 14, 2022 at 1:49:15 PM UTC-8 Philip Rogers wrote: > >> Would it work to just add "will-change: transform;" (either in the html, >> or as an implementation detail in blink itself)? This can change paint >> order because it causes a stacking context, but it's the simplest way to >> ensure a cc::Layer is created that it set up for moving content. >> On Monday, November 14, 2022 at 11:48:41 AM UTC-8 Pea Wyllie wrote: >> >>> Hello, I've got a use case in which I need to get certain DOM elements >>> into their own layer. I've added a new HTML attribute for this purpose, and >>> added a new Compositing Reason to the layers that have this attribute. >>> However, when I go to a test site on my Chromium build running with >>> --show-composited-layer-borders, I do not see my elements in their own >>> compositing layer. Is there an allowlist elsewhere that is necessary to >>> pick up those changes? Or is compositing reasons just for metrics or >>> something and the actual logic resides elsewhere? 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/64da7ef3-9219-46dd-9a6c-5bd7148c4fd6n%40chromium.org.
