Re: Intent to ship: CSS will-change
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) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS will-change
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. On Fri, Oct 31, 2014 at 3:10 PM, L. David Baron dba...@dbaron.org wrote: 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) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS will-change
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. On 2014-10-31 3:36 PM, Benoit Girard wrote: 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. On Fri, Oct 31, 2014 at 3:10 PM, L. David Baron dba...@dbaron.org wrote: 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) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS will-change
That's a good idea. Filed bug 1092320. On Fri, Oct 31, 2014 at 3:48 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: 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. On 2014-10-31 3:36 PM, Benoit Girard wrote: 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. On Fri, Oct 31, 2014 at 3:10 PM, L. David Baron dba...@dbaron.org wrote: 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) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
