4 ms·

I hadn't heard about this before; I'm clearly out of the loop these days. With buy-in from smart people at Webkit and Mozilla, I've got to assume that it really

by Steuard 12y ago

I hadn't heard about this before; I'm clearly out of the loop these days. With buy-in from smart people at Webkit and Mozilla, I've got to assume that it really will be an improvement over the status quo. But, boy, it feels awkward at first sight. To my eye, it's weird to see what is essentially a low-level optimization instruction as part of CSS (which is usually all about presentation rather than implementation). Also, the article makes it clear that there are a lot of ways that people could mistakenly use this property in unhelpful ways. And I'm still not entirely clear on what they mean by "It’s not possible to remove will-change if it is declared in the style sheet": is this really a CSS property that can be turned on without scripting but never turned off without it? That makes me uncomfortable. So why isn't this a case where we just need browsers to get smarter? In the same sense that an optimizing compiler can in most cases produce better performance than a human writing machine code by hand realistically could, can't we expect browsers to gradually get better and better at spotting these rendering optimizations? (To take an example from the article, couldn't the browser recognize that there's a transform rule for :active and automatically enable something equivalent to will-change for :hover itself?)

bgirard 12y ago
I made the original proposal for will-change on Mozilla' behalf. I agree with your concerns, we've had them since 2010 and kept pushing back on proposing this. But with HiDPI mobile and 4k desktop it's really difficult without it. It is nearly impossible to predict changes that some page do in perfectly reasonable ways, especially for changes triggered from Javascript. It's true that in some cases a will-change can be inferred from the style sheet but there are still too many changes triggered from JS events. You wont lose any performance by not using will-change and we will continue improving how we infer them. Once an element is declared as will-change the browser will be able to weight the hint and the platform specific costs of various possible optimization like layerizing the element and ignore it if it isn't suitable for the device. If we can't predict the change then we're left trying to be ready to change a new element within one vsync interval to avoid any latency. This is fine if you're dealing with a small element but large elements like a fullscreen CSS page flip triggered from JS is going to be nearly impossible to perform without a frame or more of latency. In the case of HiDPI mobile you typically have 2 millions pixels (8 MB) to deal with on a 1GB/s memory bus with a frame time of 16ms. That means that if you touch 16 MB, or twice the size of the screen, then you have zero chance to perform that change without introducing delays. And this is without even considering the CPU/GPU cost require to perform the change. The situation may also get tough on 4k desktop without a discrete GPU if you have 31MBs per fullscreen surface on a 10GB/sec bus. These are all theoretical throughput maximums. In practice on Android and Firefox OS where a style change occurs on large and complex elements where rasterization is difficult you can't use SIMD to rasterize the page at memory bandwidth speeds, you instead are bottlenecked on rasterizing complicated content. It's typical to see these complex change cause 100ms latency. Once the rasterization is made then the animations can continue smoothly but you're still left with animations skipping at the beginning.
- Steuard 12y ago
  Thanks for the thorough reply: I appreciate it! Was there any consideration of making this feature JS-only? From the linked article (and some of the discussion here), it sounds like using this in an actual stylesheet may not be easy to do well (and is often not recommended). And from what you've said here, it's JS changes that are hardest to predict from within the browser. So why expose this as a CSS feature rather than a JS one?
  - bgirard 12y ago
    Using them in the CSS style sheet is perfectly reasonable. Here's how b2g/ffos uses them carefully to make the most of low end hardware: http://mxr.mozilla.org/gaia/search?string=will-change http://mxr.mozilla.org/gaia/search?string=will-change Imagine you're writing something that does fullscreen page flips in a native app vs. a web app. An example is the android homescreen vs the ffos homescreen but I see web pages that often have a similar effect. * In a native app you're going to have to decompose your page into texture that you will animate (your widget toolkit will likely make this easier). * Without will-change you're going to hope that the rendering engine will infer your animations in a reasonable amount of time getting bad performance while you wait and hope that it doesn't fall off that optimization path. * With will-change on the b2g homescreen we just have to add a one line change.
Steuard 12y ago
Heck, the browser could even do a lot of things that wouldn't even be an option via CSS. For a transition set to occur on :hover, the article suggests that a human might want to add a will-change attribute to :hover on the containing element (which could potentially be quite large). But the browser could in principle trigger the equivalent will-change optimizations just for a small buffer region surrounding the element with the transition. Or if you wanted to be really ambitious, the browser could even trigger only when the mouse is nearby and actually moving toward that element. I couldn't do any of that via CSS (and I shouldn't have to be the one to do it via JS).

by Steuard 12y ago

bgirard 12y ago

I made the original proposal for will-change on Mozilla' behalf. I agree with your concerns, we've had them since 2010 and kept pushing back on proposing this. But with HiDPI mobile and 4k desktop it's really difficult without it. It is nearly impossible to predict changes that some page do in perfectly reasonable ways, especially for changes triggered from Javascript. It's true that in some cases a will-change can be inferred from the style sheet but there are still too many changes triggered from JS events. You wont lose any performance by not using will-change and we will continue improving how we infer them. Once an element is declared as will-change the browser will be able to weight the hint and the platform specific costs of various possible optimization like layerizing the element and ignore it if it isn't suitable for the device. If we can't predict the change then we're left trying to be ready to change a new element within one vsync interval to avoid any latency. This is fine if you're dealing with a small element but large elements like a fullscreen CSS page flip triggered from JS is going to be nearly impossible to perform without a frame or more of latency. In the case of HiDPI mobile you typically have 2 millions pixels (8 MB) to deal with on a 1GB/s memory bus with a frame time of 16ms. That means that if you touch 16 MB, or twice the size of the screen, then you have zero chance to perform that change without introducing delays. And this is without even considering the CPU/GPU cost require to perform the change. The situation may also get tough on 4k desktop without a discrete GPU if you have 31MBs per fullscreen surface on a 10GB/sec bus. These are all theoretical throughput maximums. In practice on Android and Firefox OS where a style change occurs on large and complex elements where rasterization is difficult you can't use SIMD to rasterize the page at memory bandwidth speeds, you instead are bottlenecked on rasterizing complicated content. It's typical to see these complex change cause 100ms latency. Once the rasterization is made then the animations can continue smoothly but you're still left with animations skipping at the beginning.

Steuard 12y ago
Thanks for the thorough reply: I appreciate it! Was there any consideration of making this feature JS-only? From the linked article (and some of the discussion here), it sounds like using this in an actual stylesheet may not be easy to do well (and is often not recommended). And from what you've said here, it's JS changes that are hardest to predict from within the browser. So why expose this as a CSS feature rather than a JS one?
- bgirard 12y ago
  Using them in the CSS style sheet is perfectly reasonable. Here's how b2g/ffos uses them carefully to make the most of low end hardware: http://mxr.mozilla.org/gaia/search?string=will-change http://mxr.mozilla.org/gaia/search?string=will-change Imagine you're writing something that does fullscreen page flips in a native app vs. a web app. An example is the android homescreen vs the ffos homescreen but I see web pages that often have a similar effect. * In a native app you're going to have to decompose your page into texture that you will animate (your widget toolkit will likely make this easier). * Without will-change you're going to hope that the rendering engine will infer your animations in a reasonable amount of time getting bad performance while you wait and hope that it doesn't fall off that optimization path. * With will-change on the b2g homescreen we just have to add a one line change.

Steuard 12y ago

Heck, the browser could even do a lot of things that wouldn't even be an option via CSS. For a transition set to occur on :hover, the article suggests that a human might want to add a will-change attribute to :hover on the containing element (which could potentially be quite large). But the browser could in principle trigger the equivalent will-change optimizations just for a small buffer region surrounding the element with the transition. Or if you wanted to be really ambitious, the browser could even trigger only when the mouse is nearby and actually moving toward that element. I couldn't do any of that via CSS (and I shouldn't have to be the one to do it via JS).