Considerations for CSS3 Transition Performance

Considerations for CSS3 Transition Performance

You have to be careful with this, as it can alter the z-index of the element it's applied to, but adding:

-webkit-transform-style: preserve-3d;

To the element you're applying the transition to, can speed animation up considerably, as it forces the hardware to use hardware acceleration for the animation.

If you do encounter layout bugs, you can just switch your 2d transitions to 3d values, so:

-webkit-transform: translate(100px, 100px)

becomes:

-webkit-transform: translate3d(100px, 100px, 0px)

You can see a demo of how this helps speed things up, at http://stickmanventures.com/labs/demo/spinning-gears-Chrome-preserve-3d/#

If after applying this to the element, you see it or elements around it blink upon use, then use:

-webkit-backface-visibility: hidden;

To the element, and that should correct the problem.

These tips have helped me to produce fast, efficient CSS transitions, hope they help. :)

Improving CSS3 transition performance

Before the will-change directive, you couldn't do this in the same literal way that you can in other languages. The browser (or at least Webkit) dealt with rendering the page by drawing various layers. It should in theory be intelligent enough to work out the layers for you, but sometimes it was a good idea to force something into its own layer.

Sometimes that worked, sometimes it didn't, depending on exactly what's going on.

Anyway.

In CSS, one way to force something into a layer is to transform it using a 3D transform. A common strategy is to add either:

transform: translateZ(0);

or the equivalent:

transform: translate3d(0,0,0);

or the slightly crazy:

transform: rotateZ(360deg);

or the translate ones combined with:

-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;

if things are flickery.

These create a new layer as that's what the spec defines. From http://www.w3.org/TR/css3-transforms/#transform-property,

"Any value other than ‘none’ for the transform results in the creation
of both a stacking context and a containing block."

These all need careful testing, and aren't something to just always bung on anything that might need it – sometimes it's better, sometimes it's no different, and sometimes it's worse!

Good luck!

CSS3 transform transition stutters when value changes frequently (not performance related)

Saw your post on CodeMentor. The issue is that every time the value changes, it stops the transition that is currently happening and starts another of the same (long) duration. If this is done in rapid succession, it doesn't look like it's doing much of anything because it is trying to ease in constantly and never gets very far into transition, causing the stutter.

You instead need to make the transition depend on the distance to be traveled, not just the time like you currently are. There are many ways to do this, a couple are as follows:

• Every time the value changes, calculate how far the pointer needs to move and create a transition for it based on some speed and easing inputs.
• Logarithmically approach the new target each time the value changes. This would mean that every nth of a second you would move towards the target something like 1/k of the way (so long as the distance is at least a pixel), where k is some constant like 2. So, if you transition the element half way every 0.05 seconds, it would near the target fairly quickly. The hard part about using this approach is getting an alright looking starting ease, I'm not sure how that'd work exactly, it'd likely require some playing around.

The other option (which I'd likely do personally) is just make the transition duration much shorter, something like 0.1s seems to work pretty well, when dragged. You could change the transition duration on dragstart to this shorter value and toggle it back on dragstop, leaving a longer transition duration for clicks.

Performance of transition CSS on *:link,*:visited,*:hover,*:active,*:focus

First of all I want to know why you want to use that, do you want that each and every element on your page should be assigned transition for color, border-color on :hover, :active state....? Because this will be applied to all the elements, when hovered, focused, where as link and visited will be applied to a tags.

If you want to apply the above styles to the link, you should be using

a:link, a:visited ...

Also, when you are using *, it is going to be an expensive selector for your webpage. So use it only if required.

<sup>1. Good Read For Selector Performance

2. Testing Page Efficiency</sup>

---

Performance will surely be degraded, using specific(not over specific) selectors will be a much better option compared to *, though I still feel the selector you will be using is not what you need, you must be targeting a element and not ALL elements.

Are CSS3 keyframe animations smoother than property transitions?

This is not a transition vs. animation question - this is a transform vs. property change question.

Content can be moved around a screen in multiple different ways: the most common two are position property (left, top, margin-left, scroll-position etc.) changes and transforms. On iOS, now in version 5, position property changes are done in pixel increments on the CPU - there is no sub-pixel tweening, so the movement, particularly on older non-retina displays is jerky.

In contrast, transforms - notably 3D transforms are done on the GPU, so you get very smooth movement and sub-pixel tweening.

(Note that some desktop browsers do GPU accelerated position property changes - like IE9 - so there is no difference visually between the two approaches)

CSS3 IE 10 Page Fade In Transition/Animation

Found a nice clean and easy way of doing this:

HEAD

body
{
   opacity: 0;
   transition: all 1s ease;
}

.loaded
{
   opacity:1;
}

BODY

<body onload="document.body.classList.add('loaded');">

CSS performance - how to evaluate - animation (transition) of floating button size on scroll (transform scale vs height/width)

I believe you are missing the point, Chris: the reason why no other property but transform and opacity should ever be animated is because they don't trigger a repaint in anything else, even if the element is in the document flow (and because you can basically do anything with these two alone in like 95% of the cases).

From the "hit-on-performance" point of view, there are two types of animations:

• those that trigger a repaint in other elements than the animated element
• those that do not.

That's the main reason behind recommending animations by transform, opacity or position:relative;left|right|top|left. Because they don't actually move the element in flow, thus not triggering a repaint to every single other element in flow after the one being animated.

Now, if the said parent was positioned absolute (which I assume to be the case), it wouldn't have triggered a repaint to the rest of DOM anyway so the differences between that method and transform would have been minor. Inconclusive, as you put it. In theory, repainting two elements instead of one should be slower.

If you need to test, make 10k clones and trigger animation on all of them, with each method.

That will be conclusive.

---

If you really want to min-max this (as in spend absurd amounts of time on hardly noticeable improvements, as I do) you will find plenty of resources that will recommend:

• replacing any .animate() with .velocity()
• never animating anything but transform or opacity, although Velocity claims they animate anything without a hit on performance (i find that debatable/arguable, at best) - but it's a net improvement over .animate()
• sticking to CSS transitions, if possible (basically if you don't need chains)
• using Web Animations API

Personal advice: never count on synced CSS animations, especially when you have many of them. If you change tabs or the system does something extremely resource heavy for a while, your animations will be way off. If you need chains, chain.

Skipping to end of CSS3 transition

You can "stop" the animation by adding a class before starting the original animation and then removing it when you want to stop it:

Demo: http://jsfiddle.net/SO_AMK/LXqcz/2/

CSS:

#block {
    position: absolute;
    width: 100px;
    height: 100px;
    background: #ff0000;
}

.animate {
    transition: left 2s;
    -moz-transition: left 2s;
    -webkit-transition: left 2s;
    -o-transition: left 2s;
    -ms-transition: left 2s;
}​
​

jQuery:

$("#block").on("click", function() {
    $(this).addClass("animate").css("left", "300px");

    $(this).off("click");
    $(this).on("click", function() {
        $(this).removeClass("animate");
    });
});​

Note: I simplified code for the demo, complete "fixed" code is here: http://jsfiddle.net/SO_AMK/LXqcz/

CSS3 Transition Polyfill

It is possible to detect supported CSS properties, provided you're aware in advance of what browser vendor prefixes you need to sniff for. I've written a gist for the mechanism:

https://gist.github.com/1096784

cssSandpaper is a JS library that aims to parse CSS and dynamically implement polyfills for various CSS3 effects:

http://www.useragentman.com/blog/csssandpaper-a-css3-javascript-library/

There is also a jQuery library that operates in reverse order, and silently implements transitions where possible when you call $.animate():

https://github.com/louisremi/jquery.transition.js

---

Related Topics