6 ms·

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 wou

• Pxtl 12y ago
  I would hope that the browser would parse all CSS transforms and then use this particular attribute just for Javascript-based transforms.
  • IgorPartola 12y ago
    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.
    • Pxtl 12y ago
      I was thinking of animations that are applied declaratively in the HTML/CSS itself, not javascript - things like hover.
      • IgorPartola 12y ago
        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.
    • dmmalam 12y ago
      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.
      • IgorPartola 12y ago
        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.
• troels 12y ago
  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.
  • bgirard 12y ago
    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.
    • dmmalam 12y ago
      The problem isn't technical, this is a perfectly fine solution to the question of how to remove a certain class of jank. It's adding more stuff to the already bloated web specs, having them supported forever and then the mental load of wondering what browsers will actually do given that's it's an implementation detail. I can easily see this leading to more unintended hacks as for example WebKit may be less aggressive than say blink in weighting the hints, and so web developers will then add back the 3d transform hacks in addition to will-change. The target audience is also web developers many of which are inexperienced and I guarantee that even given all the warnings someone will apply it blindly to *. Hence any production implementation would have to have heuristics to catch abuse; again more complexity that will have to exist forever. While I'm willing to give the to the benefit of doubt - these guys are super smart and it's got broad support - it just feels so heavyweight to actually change the spec for what seems like a relatively niche problem that can be mostly mitigated. Also by the time it's supported everywhere (ios9?) mobiles will be 2-4x faster.
• Swizec 12y ago
  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.
  • dmmalam 12y ago
    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.
• bgirard 12y ago
  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.
• wvenable 12y ago
  Live profiling is not the panacea you seem to think it is. The purpose of this is to allow the browser to chose the optimal layout for an element before that layout is required. In other words, before any code you might live profile is actually run. That's the point.
• ender7 12y ago
  Style properties such as transforms can be changed at runtime by JavaScript (and frequently are for things like dragging operations). There is no practical way for the profiler to detect which styles of which elements your JavaScript will attempt to modify.
  • Smudge 12y ago
    In such cases -- where it is JavaScript's responsibility to mutate the CSS at runtime -- it seems like the 'will-change' property should also be added/activated using JS. However, most of the CSS transforms I write are pre-defined in the CSS and activated by simply adding/removing classes using JS. This seems like something the browser should be perfectly capable of predicting without my help, since the JS isn't actually mutating the CSS.
    • ender7 12y ago
      This reduces to the same problem mentioned above (which is essentially the halting problem). The browser has no way of predicting which elements you will add or remove these classes from. Automatic preparation would be possible for transforms/animations that are applied in pseudo selectors such as :hover, but not in any other cases.
• nostrademons 12y ago
  Live profiling wouldn't work for social reasons. When a frontend engineer demos to his executive, or a startup CEO displays a MVP to a prospective customer, they usually get a link on a cold browser, and if the transition is janky, they're like "Nope, don't want." So every frontend engineer worth his salt will continue to use the null transform hack to keep things smooth even on the initial transition. I was one of the Blink team's initial "reference customers" within Google for this, and we were pretty adamant that if there's any jank at all between when the user taps on a link and when the transition starts firing, it was a no-go for us. We've had launches canceled because they added to user-perceived latency instead of subtracting from it.
  • dmmalam 12y ago
    But couldn't you apply the same argument to many things which cause an initial slowdown (and possibly janking), such as static assets (which won't be cached and may need DNS resolved) and JS which will be interpreted until it is jitted. Also the cpu caches will still be cold. Why is this different?
    • nostrademons 12y ago
      Savvy web-developers employ techniques to eliminate those sources of jank as well, eg. static assets are base-64 encoded as data: URLs and inserted via inline JS after the page layout has loaded (note: this technique may not be necessary under SPDY), and JS is late-loaded via the defer attribute with clicks captured and replayed once the JS to service them is available. This is the reason for the jsaction library that Google recently open-sourced. The reason it's different from cold CPU caches is that all these sources of jank can cause a user or potential customer to say "Nope, I want a native app that loads instantly." You should care about sources of latency that are perceptible to the user, not ones that are invisible. We ran a number of tests and found that the time required to render a texture to GPU VRAM was user-perceptible on mobile devices.