Intent to ship: CSS will-change

[Benoit Girard]

As of next week I intend to turn will-change on by default on all
platform. It has been developed behind the
layout.css.will-change.enabled;true preference since Firefox 31 and
has been enabled for certified FirefoxOS apps since 1.4[1] [2]. Blink
has already shipped this [3], IE lists the feature as
'under-consideration [4] with 163 votes [5].

Our MDN page for the feature is being finalized [6].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=977757
[2] http://comments.gmane.org/gmane.comp.mozilla.devel.gaia/6463
[3] https://groups.google.com/a/chromium.org/d/msg/blink-dev/LwvyVCMQx1k/R_cPDxwEtEYJ
[4] https://status.modern.ie/csswillchange?term=will-change
[5] https://wpdev.uservoice.com/forums/257854-internet-explorer-platform/suggestions/6261294-css-will-change
[6] https://developer.mozilla.org/en-US/docs/Web/CSS/will-change

- Benoit Girard

[L. David Baron]

On Friday 2014-10-31 14:17 -0400, Benoit Girard wrote:
> As of next week I intend to turn will-change on by default on all
> platform. It has been developed behind the
> layout.css.will-change.enabled;true preference since Firefox 31 and
> has been enabled for certified FirefoxOS apps since 1.4[1] [2]. Blink
> has already shipped this [3], IE lists the feature as
> 'under-consideration [4] with 163 votes [5].

Have we implemented protections to deal with overuse of will-change
(e.g., just ignoring all will-change uses in a document that uses it
too much, for some definition of too much)?

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Benoit Girard]

Yes, it's implemented in part 1-4 of my patch queue in bug 961871.

Here's how it works -but is subject to change at any time-:
- The following are all in untransformed CSS pixel unit. This makes
the implementation *much* simpler[1] and more predicable for web
authors[2].
- We look at the scrollport area (the bounds of the visible area) of
the document that will-change is used within to set the budget. This
is multiplied by some constant which is currently 3 times but I'll
open a discussion to change that to perhaps as high as 9 times within
the Firefox 36 time-frame.
- When a frame is seen that uses will-change the area of the frame is
added to the budget for that document.
- If the total usage for that document is in budget then all
will-change optimizations are performed. Otherwise none are performed.

[1] We need to decide the will-change budget at the end of the display
list phase which is too early to know the will-change costs in layer
pixel which happens in the follow layer building phase. Using CSS
pixels prevents us from requiring a second pass in some cases to
properly implement the will-change budget in terms of layer pixels.
[2] If layer pixel were used an author could lose their will-change
optimizations because we decided to re-rasterize a scaled layer at a
higher resolution. This happens seemingly unpredictably from an
author' point of view.

[Ehsan Akhgari]

Can we make sure to log something to the web console when we choose to
dishonor will-change? That will help web developers to be able to
reason about why will-change doesn't give them the performance benefits
that they expect.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Benoit Girard]

That's a good idea. Filed bug 1092320.