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

21–30 of 64 posts

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

#21

Post by eli »

resu_nimda wrote: post #8
eli wrote: post #7

Earlier quoted context omitted.

The web doesn't require it either--we've made it this far, after all. I bet every platform has developers who wish they had simple tools to boost performance.

The web doesn't require it either--we've made it this far, after all. That is a perfect encapsulation of the "OK-ness" he's talking about. Yeah, it works just fine. Yeah, the web doesn't "require" a smart graphics processing engine, it probably didn't "require" videos or the canvas or CSS transitions at all. But "really good" modern platforms have these capabilities, and IMO there's nothing wrong with wanting or tryi…

I get that sentiment in general, but what does it have to do with a new hinting feature? Would hinting look different without legacy baggage? Would it not be needed? I don't see how it's possible to create an ideal browser that is fast at everything and also memory efficient. And there are always legitimate reasons to want to juice the most performance out of your pages.

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

#22

Post by talmand »

jhherren wrote: post #14

Putting performance optimization hints in my presentation code feels wrong. I think I'd use a separate css file for will-change.

By what I'm reading you shouldn't have the property in a style sheet at all. The author implies that every usage of the property requires resources that are never released as long as the property is still active. The property in a style sheet will mean that the resources are never released.

Thus, the suggestion to use the property through javascript so that it can be applied and then removed. That just seems totally weird to me.

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

#23

Post by Steuard »

untog wrote: post #15
gren wrote: post #11

I'm a bit skeptical about this new property. In this basic example, .element:hover { will-change: transform; } .element:active { transform: rotateY(180deg); } it seems very predictable. I don't get why the browser couldn't guess (with some heuristics) what to prepare. Also I feel we will misuse this feature and tend to make the performance worth than if the browser would detect what are the "will-change"s.

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.

Is there a way to make this a JS-only interface or property, then? Heck, the article made it sound like using it directly in stylesheets would often be a bad idea anyway.

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

#24

Post by bgirard »

Steuard wrote: post #13

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). A…

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.

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

#25

Post by Steuard »

Steuard wrote: post #13

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). A…

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).

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

#26

Post by IgorPartola »

Pxtl wrote: post #17
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 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.

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

#28

Post by Swizec »

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.

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

#29

Post by Steuard »

bgirard wrote: post #24
Steuard wrote: post #13

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). A…

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 than a JS one?

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

#30

Post by untog »

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`)

It is an unreasonable requirement in places, though. Before now I've made things like swipable elements that track the user's touch - i.e., you touch down, pull your finger left and the box follows you. That's not possible to do in pure CSS.
Post reply on HN