Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything You Need to Know About the CSS will-change Property

dev.opera.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Everything You Need to Know About the CSS will-change Property

#31

Post by Pxtl »

IgorPartola wrote: post #26
Pxtl wrote: post #17

Earlier quoted context omitted.

I would hope that the browser would parse all CSS transforms and then use this particular attribute just for Javascript-based transforms.

I don't see it. If I create something like this: .wide { transition: width 2s; width: 300px; } but don't apply it to any element, then load a remote JavaScript file that adds that class dynamically, no rendering engine will be able to apply this optimization.

I was thinking of animations that are applied declaratively in the HTML/CSS itself, not javascript - things like hover.

Re: Everything You Need to Know About the CSS will-change Property

#32

Post by bryanlarsen »

troels wrote: post #20
untog wrote: post #15

Earlier quoted context omitted.

Which works fine in a CSS-only environment. But a lot of the time these properties are being set in JS, which is going to be very difficult to predict.

I generally try to not manipulate properties directly through javascript, rather declaring a class for the purpose. Doesn't seem like an unreasonable requirement for proper performance? (I mean, compared to having stuff like `will-change`)

But you still use Javascript to apply the class to the element, right? So how can the browser know that your Javascript might do that?

It seems to me to know that a rule along the lines of "might-add-class: foo;" would get us back most of that separation of presentation and content.

Re: Everything You Need to Know About the CSS will-change Property

#33

Post by frik » 

  only WebKit and Firefox Nightly builds have implemented [it] 
  [...] There is also an intent to ship in Blink too.
(Opera is based on Chromium that uses the WebKit fork "Blink")

Offtopic: first time in years, I see the opera.com website. There was a lot of useful information in their blog posts, when they still worked on their own browser engine.

Re: Everything You Need to Know About the CSS will-change Property

#34

Post by dmmalam »

Swizec wrote: post #28
dmmalam wrote: post #16

Should'nt this be something that the browser should auto-optimise with a smart renderer? In the example given with the element:hover and element:active, it would trivial to parse all possible CSS transforms. Then live profiling of the page would give data on the likelihood of particular transforms. The browser could then optimise as necessary given hardware limitations and current resource constraints. Even transform…

I'm not sure why, but your comment reminds me a lot of all the "Well, if you just had a sufficiently smart compiler ..." arguments that people make.

Basically it is that argument, though in this case it doesn't seem to be too technically difficult especially compared to some of the black magic already done by modern JS engines. And anyway even if it was technically hard, the major browser vendors have the resources and the benefits are obvious. I would much prefer this than yet adding more complexity to the spec

I believe the renderer is where we'll see major innovation over the next year, it really is the next bottleneck. It's amazing (and depressing) how easy it is to jank modern web browsers even on very powerfull hardware.

Re: Everything You Need to Know About the CSS will-change Property

#35

Post by bgirard »

dmmalam wrote: post #16

Should'nt this be something that the browser should auto-optimise with a smart renderer? In the example given with the element:hover and element:active, it would trivial to parse all possible CSS transforms. Then live profiling of the page would give data on the likelihood of particular transforms. The browser could then optimise as necessary given hardware limitations and current resource constraints. Even transform…

I think 'flicker' is the wrong word. What the author means is delay/latency/jank.

'Profiling' or inferring the animation is what engine already do. The problem is as an author you're not getting predictable performance. Imagine making a tweak and then rendering engine X or Y no longer infers the animation and now you have a large performance regression.

Re: Everything You Need to Know About the CSS will-change Property

#36

Post by dmmalam »

IgorPartola wrote: post #26
Pxtl wrote: post #17

Earlier quoted context omitted.

I would hope that the browser would parse all CSS transforms and then use this particular attribute just for Javascript-based transforms.

I don't see it. If I create something like this: .wide { transition: width 2s; width: 300px; } but don't apply it to any element, then load a remote JavaScript file that adds that class dynamically, no rendering engine will be able to apply this optimization.

This would be caught be live profiling. The same way a JS engine can figure out that a particular function is only called with ints, and then create a specialised version.

Admittedly this would run slow the first few times, until the renderer can get enough data.

Re: Everything You Need to Know About the CSS will-change Property

#37

Post by bgirard »

Steuard wrote: post #29
bgirard wrote: post #24

Earlier quoted context omitted.

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 b…

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…

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

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.

Re: Everything You Need to Know About the CSS will-change Property

#38

Post by IgorPartola »

Pxtl wrote: post #31
IgorPartola wrote: post #26

Earlier quoted context omitted.

I don't see it. If I create something like this: .wide { transition: width 2s; width: 300px; } but don't apply it to any element, then load a remote JavaScript file that adds that class dynamically, no rendering engine will be able to apply this optimization.

I was thinking of animations that are applied declaratively in the HTML/CSS itself, not javascript - things like hover.

The animations that are applied dynamically are the interesting thing. They are the ones more likely to end up being used in performance-critical applications.

Re: Everything You Need to Know About the CSS will-change Property

#39

Post by IgorPartola »

dmmalam wrote: post #36
IgorPartola wrote: post #26

Earlier quoted context omitted.

I don't see it. If I create something like this: .wide { transition: width 2s; width: 300px; } but don't apply it to any element, then load a remote JavaScript file that adds that class dynamically, no rendering engine will be able to apply this optimization.

This would be caught be live profiling. The same way a JS engine can figure out that a particular function is only called with ints, and then create a specialised version. Admittedly this would run slow the first few times, until the renderer can get enough data.

Running slowly the first few times is what will-change is trying to avoid. If you read the article, there is an explicit section on applying will-change separately from the actual transformation so that the rendering engine prepares to animate/transform the object ahead of time.

Re: Everything You Need to Know About the CSS will-change Property

#40

Post by bgirard »

troels wrote: post #19
dmmalam wrote: post #16

Should'nt this be something that the browser should auto-optimise with a smart renderer? In the example given with the element:hover and element:active, it would trivial to parse all possible CSS transforms. Then live profiling of the page would give data on the likelihood of particular transforms. The browser could then optimise as necessary given hardware limitations and current resource constraints. Even transform…

My thoughts as well. This is an implementation optimisation - It seems wrong to put this kind of stuff into user space. Especially as it seems like something that should be possible to solve with a smarter rendering engine.

What will-change optimization is used under the covers is an implementation detail. Declaring what types of changes you want optimized is something best suited for the page developer. Letting the rendering engine infer and prepare for changes you want to make is something engines already do. It works but only so well.
Post reply on HN