Intent to ship: CSS Will Change

[Ali Juma]

Contact email

aj...@chromium.org

Spec

http://tabatkins.github.io/specs/css-will-change/  (Note that the CSSWG has approved [1] publishing this spec as a First Public Working Draft, so this will soon be moving to w3.org).

Summary

This adds a will-change CSS property, that can be used to signal that a particular property is likely to be changed in the future, or that an element’s content is likely to change.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/M62y2nKZ-gE

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

Compatibility risk

Mozilla has implemented will-change behind a flag [2] and has a tracking bug for enabling will-change by default [3]. Mozilla has already enabled will-change for Firefox OS system apps [4].

will-change is “Under Consideration” by Microsoft [5].

OWP launch tracking bug

http://crbug.com/356186

Link to entry on feature dashboard

http://www.chromestatus.com/features/5954199330226176

[1] http://lists.w3.org/Archives/Public/www-style/2014Apr/0016.html

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=940842

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=961871

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=977757

[5] http://status.modern.ie/csswillchange

[Darin Fisher]

LGTM

[Rik Cabanier]

On Mon, Apr 14, 2014 at 11:42 AM, Ali Juma <aj...@chromium.org> wrote:

Contact email

aj...@chromium.org

Spec

http://tabatkins.github.io/specs/css-will-change/  (Note that the CSSWG has approved [1] publishing this spec as a First Public Working Draft, so this will soon be moving to w3.org).

Summary

This adds a will-change CSS property, that can be used to signal that a particular property is likely to be changed in the future, or that an element’s content is likely to change.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/M62y2nKZ-gE

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

Compatibility risk

Mozilla has implemented will-change behind a flag [2] and has a tracking bug for enabling will-change by default [3]. Mozilla has already enabled will-change for Firefox OS system apps [4].

Reading the mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=961871), they are limiting the number of elements where will-change is honored to a certain buffer size. Looking at the reviews in blink, it doesn't seem like it constrains this at all so it's up to the capabilities of the running browser [1]. 

There really should be some sort of guideline so an author could make an informed decision if his use of 'will-change' is actually going to improve performance.

Mozilla is also flagging 'display' as a hint that creates a stacking context, but blink is not.

 

will-change is “Under Consideration” by Microsoft [5].

OWP launch tracking bug

http://crbug.com/356186

Link to entry on feature dashboard

http://www.chromestatus.com/features/5954199330226176

 

1: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/M62y2nKZ-gE/oa3phKQtqxMJ

[Elliott Sprehn]

The display case sounds like a bug, we need to make sure browsers are consistent there. The limits are fine to be per browser, the hints are purely advisory.

On Monday, April 14, 2014, Rik Cabanier <caba...@gmail.com> wrote:

On Mon, Apr 14, 2014 at 11:42 AM, Ali Juma <aj...@chromium.org> wrote:

Contact email

aj...@chromium.org

Spec

http://tabatkins.github.io/specs/css-will-change/  (Note that the CSSWG has approved [1] publishing this spec as a First Public Working Draft, so this will soon be moving to w3.org).

Summary

This adds a will-change CSS property, that can be used to signal that a particular property is likely to be changed in the future, or that an element’s content is likely to change.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/M62y2nKZ-gE

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

Reading the mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=961871), they are limiting the number of elements where will-change is honored to a certain buffer size. Looking at the reviews in blink, it doesn't seem like it constrains this at all so it's up to the capabilities of the running browser [1]. 

There really should be some sort of guideline so an author could make an informed decision if his use of 'will-change' is actually going to improve performance.

Mozilla is also flagging 'display' as a hint that creates a stacking context, but blink is not.

 

will-change is “Under Consideration” by Microsoft [5].

OWP launch tracking bug

http://crbug.com/356186

Link to entry on feature dashboard

http://www.chromestatus.com/features/5954199330226176

 

1: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/M62y2nKZ-gE/oa3phKQtqxMJ

[Ali Juma]

Reading Mozilla's code (http://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPropList.h?from=nsCSSPropList.h#1594), it does not seem to be the case that they create a stacking context for will-change:display. Note that there is no "CSS_PROPERTY_CREATES_STACKING_CONTEXT" in that part of the code (where 'display' is defined). Is there contradictory code somewhere else?

[Adam Barth]

On Mon Apr 14 2014 at 1:28:44 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Mon, Apr 14, 2014 at 11:42 AM, Ali Juma <aj...@chromium.org> wrote:

Contact email

aj...@chromium.org

Spec

http://tabatkins.github.io/specs/css-will-change/  (Note that the CSSWG has approved [1] publishing this spec as a First Public Working Draft, so this will soon be moving to w3.org).

Summary

This adds a will-change CSS property, that can be used to signal that a particular property is likely to be changed in the future, or that an element’s content is likely to change.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/M62y2nKZ-gE

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

Compatibility risk

Mozilla has implemented will-change behind a flag [2] and has a tracking bug for enabling will-change by default [3]. Mozilla has already enabled will-change for Firefox OS system apps [4].

Reading the mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=961871), they are limiting the number of elements where will-change is honored to a certain buffer size. Looking at the reviews in blink, it doesn't seem like it constrains this at all so it's up to the capabilities of the running browser [1]. 

There really should be some sort of guideline so an author could make an informed decision if his use of 'will-change' is actually going to improve performance.

Mozilla is also flagging 'display' as a hint that creates a stacking context, but blink is not.

That sounds like an important issue to resolve before shipping the feature.

---8<---

If any non-initial value of a property would create a stacking context on the element, specifying that property in will-change must create a stacking context on the element.

--->8---

Maybe Firefox supports a value for the display property that creates a stacking context?  Hum...  I wonder if this requirement will cause us problems in the future because we won't be able to add new property values that create stacking contexts without breaking existing content that specifies will-change for that property.

Adam

[Ali Juma]

On Mon, Apr 14, 2014 at 4:44 PM, Adam Barth <aba...@google.com> wrote:

Mozilla is also flagging 'display' as a hint that creates a stacking context, but blink is not.

That sounds like an important issue to resolve before shipping the feature.

---8<---

If any non-initial value of a property would create a stacking context on the element, specifying that property in will-change must create a stacking context on the element.

--->8---

Maybe Firefox supports a value for the display property that creates a stacking context?  

I double-checked (testing in Firefox Nightly, with will-change enabled in about:config) that Firefox does not create a stacking context for "will-change:display". So there's no difference in behavior for this. 

[Adam Barth]

On Mon Apr 14 2014 at 1:44:26 PM, Adam Barth <aba...@google.com> wrote:

On Mon Apr 14 2014 at 1:28:44 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Mon, Apr 14, 2014 at 11:42 AM, Ali Juma <aj...@chromium.org> wrote:

Contact email

aj...@chromium.org

Spec

http://tabatkins.github.io/specs/css-will-change/  (Note that the CSSWG has approved [1] publishing this spec as a First Public Working Draft, so this will soon be moving to w3.org).

Summary

This adds a will-change CSS property, that can be used to signal that a particular property is likely to be changed in the future, or that an element’s content is likely to change.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/M62y2nKZ-gE

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

Compatibility risk

Mozilla has implemented will-change behind a flag [2] and has a tracking bug for enabling will-change by default [3]. Mozilla has already enabled will-change for Firefox OS system apps [4].

Reading the mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=961871), they are limiting the number of elements where will-change is honored to a certain buffer size. Looking at the reviews in blink, it doesn't seem like it constrains this at all so it's up to the capabilities of the running browser [1]. 

There really should be some sort of guideline so an author could make an informed decision if his use of 'will-change' is actually going to improve performance.

Mozilla is also flagging 'display' as a hint that creates a stacking context, but blink is not.

That sounds like an important issue to resolve before shipping the feature.

---8<---

If any non-initial value of a property would create a stacking context on the element, specifying that property in will-change must create a stacking context on the element.

--->8---

Maybe Firefox supports a value for the display property that creates a stacking context?  Hum...  I wonder if this requirement will cause us problems in the future because we won't be able to add new property values that create stacking contexts without breaking existing content that specifies will-change for that property.

I talked this over with Tab.  Apparently this issue is already understood to be a cost of implementing will-change and that folks view benefits the feature as outweighing this loss of future flexibility.

[Rik Cabanier]

you're correct. the CSS_PROP_DISPLAY macro confused me. (I wonder why position:sticky was called out for 'position')

It seems Blink and Firefox are in agreement on what creates stacking contexts. 

[Eric Seidel]

Would the behavior be to warn (in the console?) when authors exceed
the browser-specific limit for will-change elements?

Warning on bad usage of a performance hit does seem like a useful
feature to try and help authors achieve good performance of their
pages.

[Rik Cabanier]

On Mon, Apr 14, 2014 at 2:28 PM, Eric Seidel <ese...@chromium.org> wrote:

Would the behavior be to warn (in the console?) when authors exceed
the browser-specific limit for will-change elements?

From the comments, it seems that they decided that 'will-change' will be ignored once the limit is reached. This does not seem to be implemented though.

 

Warning on bad usage of a performance hit does seem like a useful
feature to try and help authors achieve good performance of their
pages.

Yes, if there were some sort of profiling tool that reports how much memory was used on layers, informed authors could use that to optimize their web pages.

[Eric Seidel]

Even just a console log:
WARNING: CSS property "will-change" applied to more than N elements,
matches beyond N will be ignored.

I agree that without a tool to div down and see who is using what it
might be difficult to debug.

[Ali Juma]

On Mon, Apr 14, 2014 at 6:14 PM, Eric Seidel <ese...@chromium.org> wrote:

Even just a console log:
WARNING: CSS property "will-change" applied to more than N elements,
matches beyond N will be ignored.

I agree that without a tool to div down and see who is using what it
might be difficult to debug.

Note that in the discussion on the Mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=961871), they dropped the idea of having a fixed limit on the number of will-change layers (on the grounds that there's really no ideal choice for the value of the limit). Instead, they settled on the idea of having a device-dependent total-layer-size budget; all composited layers (not just will-change layers) would count against the budget, and will-change would be ignored when the budget runs out. They haven't implemented this idea yet.

[Rik Cabanier]

their proposal:

The ideal implementation would let authors specify appropriate will-change and not have to think about what hardware the device will run. Having JS conditional logic would be a big failure IMO. Therefore I suggest that the browser engine allot a layers budget appropriate for that device. This budget could be 'no more then 5 Megapixel of layers, no layers smaller then a page in size before of high draw overhead in this platform'. We then give priority to the normal active layers and the remaining will-change. If we run out then the will-change layers wont fit first and we might even skip active layers if we're constraint. This also solve our problem with getting too many active layers on mobile where we currently limit a container layer to 10 children which is a terrible band-aid.

and:

I vote we (1) Implement a page layer budget, (2) distribute the budget between LAYER_FORCE_ACTIVE (and never disallow), LAYER_ACTIVE, will-change in that order, (3) then focus on better detecting cases where layering an element is a performance regression on that device.

Getting this feature used the right way in the world is the tricky part. I like what Eric suggested about a warning in the console if blink suspects that the feature is being used too much. (The "too much" limit could be raised as hardware and the logic in blink get better.)

[Nat Duca]

I am very wary of the spec deciding how to handle overpromotion, partly because it starts making assumptions about how the browser manages memory and renders, but also because there is an incorrect assumption that will-change: left,top  on a thousand elements is an incorrect thing. Developers should set will-change on things that **will change** ... they should not think about layer memory. If they do, then its just because our implementation isn't quite right.

With this in mind, three parted response.

Part 1: layers != memory

------

Its really important when discussing defense schemes against will-change to consider our existing architecture and its existing capabilities wrt hostile content. We have many many systems in place becuase, frankly, lots of people overpromote already, using translatZ. Impl side panting [1] and hybrid ganesh rasterization, especially phase 2, and layer squashing [for which I lack a link] all come into play here.

Summarizing, memory managment in these contexts is VERY different from the mental model of "will-change creates layers that create memory." Rather:

- the mapping of will-change to layers is goverened by the squashing algorithm. i don't really understand this too well, but the key piece for here is that will-change is not a forcing reason for creating a layer. so, multiple change divs can in theory be put into one layer if we so choose.

- layers are diced into tiles, tiles are prioritized, and memory is given out to those tiles already using a complex pooling scheme

- we have global memory manager that looks at the per page requirements based on those tiles and balances across those pages

- we do demand rasterization of any tiles that didn't get memory. This kills perf but keeps us to a fixed memory budget while correctly drawing the scene.

With phase 2 of ganesh mode, we can opt to draw any layer into the backbuffer directly using the GPU, effectively consuming no memory. In this context, will-change is more of a hint to other parts of the system than to layer creation.

Part 2: will-change is auditable

---

Consider

   *{will-change: left}

This looks wrong... except when you put harlem shake on your page. Then suddenly its absolutely correct! How many elements are changing is completely content dependent. Thats a VERY good thing.

What is WRONG is when someone says something is going to change and then doesn't. But, whats cool is that we can audit this!

* Warning: div.foo said will-change: left but hasn't changed left in ~100 frames

The reverse is true auditable as well:

* Warning: div.bar changed width in the last 4 frames, but did not have will-change: width

To reiterate, if you have 1000 divs and they're all moving around randomly with top/left, then will-change: top, left is absolutely *correct*.

We want our architecture able to scale in many ways in the face of such content. First and foremost we want it to produce the right picture [works fine in impl side painting] and then second, we want it to pick the optimal mix between caching primitives and just-in-time rendering primitives to match the current memory and cpu/gpu capabilities.

That optimal mix is NOT determinable by the user, or by authoring tools. Nor should it be. Every computer is different. Memory amounts are different. GPUs are different. The right layer<->div+changehint mapping is different depending on these and many factors.

Part 3: developers should think about change, not layers

------

When putting down will-change as a content author, the correct mental model is that developers put will-change on things that will change, and dont put it on things that won't. Its really that simple, and to think of there being budgets is mainly a bug in our implementation.

Authoring tools have great knowledge of the future. Developer tools can track the past and point out mistakes based on the change hints. Telemetry type tools can audit this on waterfalls. Maybe we could someday add window.performance mechanisms for js-side unit testing.

That we think that "will-change" is about layers is an artefact of today's technology, and what is slow today. As we fix jank on the main thread, and as we speed up rasterization using the GPU, new and probably different things will become slow. Hinting about will-change can be used throughout the pipeline, for instance we could change the way we build renderobjects when we know they're going to get blown away next frame.

Or, there is no point in laying out the offscreen parts of a div if it is marked will-change: width, or will-change: contents.

We need to keep the future in mind as we discuss will-change. will-change is about using the hints about the future to make the browser make better choices about what to optimize. Be it power, fps or memory consumption. Its *not* about layers.

$0.02

- N

[1] http://www.chromium.org/developers/design-documents/impl-side-painting

[2] https://docs.google.com/a/chromium.org/document/d/1Vi1WNJmAneu1IrVygX7Zd1fV7S_2wzWuGTcgGmZVRyE/edit#heading=h.7g13ueq2lwwd

[Alex Russell]

Thanks for the incredibly thorough context. LGTM!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Adam Barth]

LGTM2

[Eric Seidel]

LGTM3

[Antonio Gomes]

+blink-dev (excluded by accident)

Answered. Thanks Nat.

On Thu, Apr 17, 2014 at 2:52 PM, Nat Duca <nd...@chromium.org> wrote:
> Simple. By then it would be too late.
>
> The browser needs to know whether something will change *in advance* of it
> changing in order to apply the optimizations necessary to keep it moving
> smoothly. If we know in advance that it will move, then we can set up the
> rendering system to be prepared for it to move so that the second it starts
> moving it'll be cheap. If the will change hint is set wrong, and something
> does change, then the penalty is huge --- sometimes several hundred ms of
> work tryying to convert the element from stationary mode to moving mode.
>
> We do actually try to infer will-change from a lot of things. For instance,
> when a css animation is running, thats obviously will change of various
> forms. The places where we cannot know the future in advance are things like
> these:
> - something that will eventually get an animation attached to it [e.g. from
> script]
> - people moving things around from script using inline style [eg jquery]
>
> There are some things that are really tricky to infer automatically. If you
> have a flexbox and you animate the flex basis of one element, that may cause
> some element deep in another part of the flexbox to change its height.
> Technically we could do computation to realize that the height of that
> affected element will change. But, this is computationally prohibitive when
> we studied this problem so while we might do it someday, it'll require a ton
> of finesse to make sure this "automatic" stuff doesn't slow down content
> that is cpu bound to begin with: our first priority is to make it *possible*
> to make a fast animation. That's not possible, imo, without will... once
> we've got that, we can try for more.
>
> Wdyt given that?
>
>
> On Thu, Apr 17, 2014 at 11:19 AM, Antonio Gomes <toni...@gmail.com> wrote:
>>
>> Hi Nat. Nice explanation. One question below. Cheers,

>>
>> On Mon, Apr 14, 2014 at 11:01 PM, Nat Duca <nd...@chromium.org> wrote:
>> >
>> > Part 2: will-change is auditable
>> > ---
>> >
>> > Consider
>> > *{will-change: left}
>> > This looks wrong... except when you put harlem shake on your page. Then
>> > suddenly its absolutely correct! How many elements are changing is
>> > completely content dependent. Thats a VERY good thing.
>> >
>> > What is WRONG is when someone says something is going to change and then
>> > doesn't. But, whats cool is that we can audit this!
>> > * Warning: div.foo said will-change: left but hasn't changed left in
>> > ~100
>> > frames
>> >
>> > The reverse is true auditable as well:
>> > * Warning: div.bar changed width in the last 4 frames, but did not have
>> > will-change: width
>> >
>> > To reiterate, if you have 1000 divs and they're all moving around
>> > randomly
>> > with top/left, then will-change: top, left is absolutely *correct*.

>> > (...)
>>
>> So essentially you said, "will-change is auditable” and described how
>> elements that are incorrectly tagged with will-change can be
>> identified. Why not have the browser then automatically tag? In this
>> case there’s no need to let the content author worry about
>> will-change.
>
>



--
--Antonio Gomes

[Dimitri Glazkov]

LGTMTOO