When using GSAP to perform a transition where an element is scaled equally in both dimensions, there seems to be a choice between using scale, or both height and width.
Which is better, as in will result in a higher frame rate? Or if there are conditions on the element / other transitions / DOM / CSS / browser / processor / GPU (/anything else?) that makes one better over the other, what are these?
One of the differences in using Scale Vs Width/Height is the use of CSS but you have to keep in mind while using Scale it will resize from the center of the object, while using Width/Height it will be from top left. Unless you change the transform Origin.
One major factor is the content of the object you are resizing, if you use Scale and the object has content, it will also scale everything inside, while Width/Height will not.
From what I can understand, what scaleX and scaleY do is that they use CSS's transform in the background and generally, using transforms produces a much smoother result because of sub-pixel rendering. Also, if you add force3D: true on the same element as well, it forces it to render it on its own GPU layer hence, hardware accelerated. And that happens because it adds translate3d: (0px, 0px, 0px) onto the same element. So in my opinion, manipulating transform related properties is much better.
Although, this article by Paul Irish
talks about moving elements (i.e. moving with translate vs top and left), but I believe the same holds true in our case.
Here is a quick jsFiddle for you to play around with.
Related
I have a HTML5 animation that uses a canvas of size 900x520. However ~60% of the canvas is not utilized in the most general case. If some of the parameters of the animation are varied, then the whole canvas is utilized which is the reason why I pegged the maximum canvas size to W:900px and H:520px.
When a user opens the page with this HTML5 canvas, a general case is considered and only 280x280 at the center of the HTML5 canvas is used. As per my knowledge though I'm not using the other 60% of the canvas is not used but is rendered every time which is causing the animation to slow down, especially on tablets and mobile phones (Most of my intended users are tablets / mobile users). So, I would like to know if there are any techniques to render only a set of pixels everytime (say 300x300 at the center of the canvas) ? Are there any workaround solutions ?
I'm already using RequestAnimationFrame (However, I want some more optimization)
First thing i would try is to use the clip() function. It slows down the drawing, but in your case it might be faster to check first against a clip since 60% of the time the clipping will quit the drawing.
Second thing to try is to handle clipping by yourself : handle a viewport object ( center x, center y, width, height ) and exclude unseen object with simple bounding box testing. Rq : Maybe the way you draw your scene allows for easy optimisation.
3) do not define a canvas bigger than the screen : rather define it at max size, and keep track of an offset, like with a viewPort object. And to avoid re-writing all your draw code, just use save/translate/restore before/after your old methods. For the clipping on this canvas, refer to 1) :-)
4) you can reduce graphic strain on mobile by using css scaling. Even if scaling reduces performances, on mobiles it is faster to draw on smaller canvas with a css scale than to draw full resolution with no scale.
So you have to set canvas.style.width and canvas.style.height to some wise values, and you can set canvas.width and canvas.height to the setting that allows for the right performance.
Let's say I want to to move an element from left to the right, I can achieve this by doing
transform: translate3d(200px,0,0);
/*or*/
transform: translateX(200px);
or
transform: matrix3d(x,x,x,x,x,x,x,x,x,x,x,x,200,x,x,x)
or just set left position.
Why is CSS matrix3d rendered faster than just setting a position left/top?
UPDATE:
CSS animation of top/left vs transform in slow-mo.
high performance animations on HTML5
There are 2 factors than are relevant here
1) Because left can potentially affect all the layout in your page, so it forces a recalculate of style and layout. Transforms do not need this step, the transforms do not afect the element neighbours.
see html5 - high performance animations for a better explanation
2) Because most 3d work is handled by the GPU and not by the CPU. The GPU not only can do that much faster, it also frees the CPU to handle better the rest of the work. You will see a lot of times the style
transform: translateZ(0px);
wich obviously does nothing, but that makes the broser use the GPU and accelerates the process. You could try to measure changes to left with this line added and see what the perfomance is.
I am having a performance issue when combining blurred images with some subpixel translate animation (I am using jQuery Transit):
filter: blur(5px);^
On mousemove, blur is recalculated to simulate Depth-of-Field.
When moving, the elements aren't moving as fluid as I would like them to be.
Demo here
Buggy movement appears when you click on a bottle in a -webkit browser
Any idea/tips how I could accelerate this?
I was thinking about pre-calculating every focus step and using opacity but this is the last solution I would use.
It looks like you're translating and scaling the images at the same time, which is causing the jumpiness. Try using translate3d -webkit-transform: translate3d(x,y,z) instead and modifying the z position instead of scaling. This should help quite a bit with performance as your animations will now be hardware accelerated.
My understanding is that CTRL-mousewheel zooms are an accessibility feature, built into the browser in question (I am currently testing in Chrome and Opera, both if which use the CTRL- zoom).
This won't ever really be needed for accessibility, however, as the app will not be for the general public. And CTRL-wheel zoom has a nice benefit out-of-box as compared with standard mousewheel zoom over elements: It seems that Angular ui-sortables work perfectly at any zoom/scale.
Unfortunately, from other answers I've found on SO, there is no way, when using CTRL-wheel, to zoom selectively : the browser can only zoom everything. For me, this includes position:fixed overlays scaling at the same time as the main viewport, which is no good.
So I set up some code for scrolling as per whichever element the mouse cursor is over, eg. scale the main viewport using the mousewheel, only if the mouse if over that viewport element.
The problem is that ui-sortable does not behave correctly, when using it for only a single element. I've used scale with transform-origin set at 50% 50% but still, when I drag the ui-sortables at any scale other than 1:1, they appear way off to the left. Any ideas on how to begin to tackle this?
This isn't a problem in Angular's sortable adaptation, rather it's an issue in the underlying jQuery-ui 1.9.2 positioning functions around line 4000 (_generatePosition or maybe one of the others). I believe that as the browser does not modify the actual dimension values during scale or zoom, and the formulae provided in that library do not account for scaling (that I can see), there is no easy fix, since jQuery ui.sortable needs scale-accurate values to calculate correct displacements. (I tried modifying the formula to account for this, but without success.)
The simplest workaround for the present is to manually change the width() / height() of your individual list elements, as seen here. This may require being selective about just what you scale using width() / height(), and what you change using scale (which is generally easier).
I was wondering if there was any jQuery library that will allow us to change the perspective of an image.
I know that modern browsers already support vendor specific rotate() in CSS but it doesn't quite give the desired result. Most of them just vary the width of the image but doesn't shrink the height of one side and increase the height of one side to produce the effect that you are viewing the image from another angle.
Any more details that you may need, please tell me. Thanks!
EDIT
I already tried transforms but they don't increase the height of the side that is moving towards you and decrease the one that is moving away from you. And I don't do full rotations, i just tilt the image a few degrees so the change in height has to really be there
Have a look at script3D.js
http://minimal.be/lab/Sprite3D/
could be usefull for 3D css animations.
CSS3 has 2D-transforms and 3D-transforms. While the first is well supported (by all browsers, not by all used versions [1]) the second is currently only supported by mozilla and webkit [2]. Both features mostly need vendor-prefixes.
And of course you can animate them with jQuery, if you want to.