As I understand hardware acceleration on iOS devices is enabled when using translate3d(). So why this test on jsperf shows that using css left/top is faster?
I have used translate3d extensively on iOS in lieu of CSS left/top, and I can say one thing:
It is truly faster for animating things (which jsperf does not seem to do.) My guess is, left/top is faster when benchmarking since nothing is animated and I don't think anything is displayed either.
It is when used in conjunction with transition (or -webkit-transition) that translate3d works its magic.
Related
When using scaling to change the size of an HTML element containing text, the text jitters during the animation, but only if being animated with JavaScript libraries.
The jittering is most visible when the animation is slower and the text is smaller. I can't seem to figure out what causes it or how to get rid of it.
This jittering does not occur during CSS animations or animations using the fairly new JavaScript Web Animations API. It also doesn't seem to occur in some browsers. (On my iPhone)
To easily compare the different methods of animating the scaling of an element and how they appear, I made a CodePen for convenience. Before checking it out, note these points:
All the animations are using some form or imitation of the CSS property transform: scale(num); for the animation and have the same easing and duration so they can be compared more easily.
Although the jittering appears on macOS too, it is almost impossible to see on Macs with retina screens because of the high resolution.
The results I got are a reflection of the appearance of the animations on a Windows 10 machine in Google Chrome 59, although for me Microsoft Edge also showed the same results.
So my question is this: How can I prevent the text from jittering or becoming blurry when animating a scale property with JavaScript? How can I make the text in my JavaScript scale animations appear just as smooth as they do when using CSS?
You may be wondering why I don't just use CSS. The answer is because I'm frustrated with how limited CSS animation is. I would like to use advanced easing functions beyond the capabilities of a simple bezier curve (like Robert Penner's bounce and elastic functions), and use different easings on hover when the mouse enters and exits the element. This s completely my own opinion, but so far the only painless way I've found to do this is with JavaScript libraries. Besides their functionality relating to easing, most seem to offer many other capabilities which make animating much more effortless. If you know of a better way to get all the functionality I need please let me know!
What you are encountering are differences in a browser's layerizing strategy. You'll find that all the examples appear smooth in Firefox. That's because Firefox detects when script is changing a property that can animated using layers and creates a layer in response.
Although all browsers create layers when needed for declarative animations (CSS animations, CSS transitions, Web Animations API animations, and even SVG SMIL animations in some cases) not all browsers do it for Javascript animations. So, for those browsers you need to try to trick the browser into creating a layer (or, you could just file a bug on the browser, since it really should do this for you!).
Until recently, using will-change: transform was the recommended approach to get a browser to create a layer. However, Chrome changed its rendering strategy and now will-change: transform can produce very blurry results with scale animations in Chrome. Some people have succeeded in tricking Chrome to layerize at a higher resolution initially and then scaling their element down before animating. This is really unfortunate to have to do this and I can only encourage you to petition Chrome to fix this.
Also, the examples using "with HA" are not accurate. The CSS animation in (1) will also use hardware acceleration in every browser I know of--there's no need to add perspective in. Unfortunately, there is a lot of misleading information in this area (e.g. some articles claim animations can run on the GPU but that's simply not true). At the risk of self promotion, you might find an article I wrote on this last year helpful.
I was running something which does number scrolling using ScrollerJS. It supports two modes : CSS transition and DOM animation. When I was using the DOM animation mode, I find sometimes the scrolling is not smoother than that of CSS transition.
So I am wondering whether CSS transition performs better than DOM animation generally? Is there any proof or testing that shows this?
CSS transition : CSS3 transition/transform property which transforms an element
DOM animation : Traditional DOM animation which changing the CSS top property continuously.
In short, yes. Doing it in CSS allows the browser to optimize it, e.g. using hardware acceleration.
If you manipulate the DOM, the browser generally has to re-render the content, which is usually slower.
DOM manipulation is typically used to support older browsers where CSS animation is not supported (or poorly implemented).
From http://scrollerjs.pixelstech.net/#about
If CSS transition is supported in a browser, CSS transition will be
the preferred option for animation.
If in old browsers where CSS transition is not supported. DOM
animation will be chosen automatically.
However, note that as usual, things are never completely straightforward, and no generalization is completely true... There are javascript animation libraries out there that can rival or sometimes even outperform CSS-based transitions/animations, and they are usually more flexible. Here's some light reading:
http://davidwalsh.name/css-js-animation
https://css-tricks.com/myth-busting-css-animations-vs-javascript/
This question isn't too hard to answer.
A DOM animation uses your CPU for it's calculations and since an animation is quite heavy on the CPU it'll sometimes 'lag' which is when you see artefacts on the screen.
CSS3 transitions however are able to use hardware acceleration which uses the GPU of your computer (if it has one ofc :D). Since your GPU is much stronger and better at doing things like animating, you'll barely notice any lag if any.
This question is not easy to answer because in different cases some kind of animation performs better than the other.
I think this article could be more than interesting if we are talking (seriously) about performance between CSS and DOM animations.
If you are going to work a lot with animations and you are worry about the performance I suggest to try a more professional library like GSAP, they also have a scroll plugin.
Why does this example run slower when the position is set by translate3d(x,y,z)?
My guess is that every change to the CSS requires a recalculation of the style, which is less expensive when the element isn't being sent to the GPU. Is there a way to do the dynamic transitions that I need without recalculating the style?
I'm interested in running in a WebView on iOS and Android. Is CSS3 the only option for accessing the GPU? Is there a way to use the GPU to increase performance here?
A good way to use the GPU for accelerated drawing on mobile webviews is via the <Canvas> element. This similar example is able to move four times as many particles at a similar framerate:
Canvas Particles
On a web page, I'm scaling an <img/> tag.
To this end, I use the css3 transform scale function linked through jquery .animate method (https://github.com/louisremi/jquery.transform.js). All in all, result is good on Firefox and IE9. But under webkit browser (notably chrome 21), there's a big performance cost and the animation isn't looking good.
So, I take a look at the chrome devtool timeline. And the problem is definitly caused by the repaint of the <img/>, the time taken to repaint the image is incredibly long.
Just so you know, we don't access dom to often (never while animating), and we use requestAnimationFrame. The trouble really seems to live in the algorithm used by webkit to resize images. We added css -webkit-transform-style: preserve-3d;, this helped a bit, but not so much.
Do anyone have a hint on this ?
I'm using jQuery .scrollTop to scroll image within a div. It works great in Firefox - scrolling is very smooth and fast. In IE 8 scrolling is very slow and glitchy - image scrolls once in about a second - two seconds. Image size is on average between 2000 * 2000 and 4000 * 4000 pixels.
Is there a way to improve this for IE 8?
Performance in IE 7 is slightly better, but still not good enough.
Thank you
Edit: I believe that an issue is in how scrolling is implemented in IE 7 and 8. I have enabled both scroll bars (overflow-x and overflow-y), and I have tried scrolling an image using these scroll bars. Issue is exactly the same. I've tried running this on a fairly underpowered PC - pentium dual core few years old with 2 GB of RAM as well as Core i7 desktop with 2.8GHz CPU 1600Mhz RAM and the results are nearly identical. FireFox scrolls a lot faster, however its CPU usage on average is 10% higher than IE CPU usage. This leaves me puzzled...surely Microsoft would have addressed this issue by now?
Another thing that I have found slightly odd is that scrolling ran faster on a Core 2 Duo laptop. I'm wondering whether this has anything to do with graphics card drivers...does IE 7/8 even make a use of GPU?
Excuse me if any of this sounds silly, but I'm really interested in solving this problem...IE can't be that bad..
jQuery's .scrollTop() is notoriously slow in ie, and if the markup is even slightly complex or large, you'll never get it to perform well.
The solution is to not use the jQuery .scrollTop() function, but build your own based on the native properties .scrollHeight and .scrollTop.
The reason is the way ie computes offsets, which is the base of jquery's .scrollTop() slowness - you have to walk up the DOM tree and calculate offsets for every parent in ie.
jQuery does this the best it can, but you will always be able to do it faster since you know the markup in advance and can optimize this - you can even do the offset calculations in advance most of the time and just use a constant as modifier.
All that said, this might not be jQuery's fault - it can simply be a problem with ie's rendering pipeline - depending on how you made your marklup and styling of it, a scroll might force ie to completely rerender/repaint the page for every pixel you scroll, and that will slow it all down to a crawl.