In short:
Why is this:
$('body').animate({scrollLeft: 1000});
much much faster than this:
$('body').animate({"margin-left": 1000});
?
Background:
I am working on a website that has a animated scrolling. e.g.: When the user clicks a link I fire a javascript that animates the scrollbar. Something similar to this website:
http://www.fashionphotographer.it/
My first take on this problem was to animate the margin-left using jQuery.animate but this proved to be very slow (my site is very content heavy). After that I tried animating the left of a absolute element, using CSS3 and even the -webkit-transform. All solutions where slow.
My last try was to use jQuery to animate the scrollbar, and this proved to be best solution so far.
My question is: What kind of optimization is the browser (I am using Chrome) doing under the hood that makes animating the scrollbar the best solution?
Changing the scrollLeft property will not force a reflow of the DOM, as you are really just changing which portion of the content is visible at any one time. margin-left, left or other smiliar properties, on the other hand, may cause other elements to resize, which forces the browser to reflow the DOM.
Edit: I believe scrollLeft will force a repaint, however this is much less intensive than a reflow. See http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/ for a good explanation of the difference.
Related
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.
I'm using d3.js to draw a (multi)line graph (with quite a few data-points, 1600 to be exact) on an svg element.
This graph is in a container which has a transition on it.
On a certain event the container gets moved 400px to the top with a CSS3 transition which works fine in Chrome. When trying in Safari and Firefox I noticed that is was really slow. After some checks I can say with 99% certainty that the svg element gets redrawn during the transition (a lot) in Safari/Firefox (and possible other browsers, too).
Is there anyway to prevent the browser redrawing it constantly until the transition is finished? Or maybe other solutions that would make this fluent?
FYI: not drawing the chart in the SVG element makes the issue go away, so I'm certain the slowdown comes from the SVG element.
The simplified html code:
<div id="container" style="transition:margin 0.75s; -webkit-transition:margin 0.75s; ">
<svg id="simple_line" style='height:210px; width:100%;'/>
</div>
Generally speaking, using margin or any other CSS position value to make objects move around the screen is sub-optimum. Try using a transform/translation style to create the movement, which will tell the browser to use graphical optimization methods.
The idea is that a transform tells the browser to move around a block of rendered content, instead of re-calculating the whole layout. Results will still depend on the quality of the browser's implementation -- as you discovered, Chrome has good optimization either way, but this should reduce the browser-to-browser differences.
I made a game where you can walk on a 2d grid world (Pokémon style) and currently you just hop from tile to tile instead of a nice walking animation in between.
I'm right now working on that walking animation, and it all works, except that the browser doesn't reflow/repaints fast enough.
If I closely zoom in on the sprite I can see the sprite moving and doing only half of the replaces he needs to do. This creates a lag feeling, which I obviously not want. So I googled today and learned about reflow and repaints and that the browsers stacks the animations until a certain time and then executes them in batches.
I want to avoid the stacking of animations so I searched on Google, and found a lot of hacks, which are not working for me, unfortunately...
I used hacks like requesting the offsetTop, hiding and showing the element, and some others which are easily to be found online. None of them worked.
I then learned here: http://dev.opera.com/articles/view/efficient-javascript/?page=3#reflow that the browser may reflow in the background, without making it visible. (probably why the hacks weren't working)
Do you have any way so I can make the browser visibly reflow?
In the project I currently work on we experience very strange rendering issue. The worst thing is that this issue emerges completely spontaneously and after several days of testing we haven't managed to find the sequence of actions wich would reproduce this issue. Here is an explanation of how this bug look like. Here is a screenshot of how the page should look like:
But instead of this after some manipulations content block pops up so only the part of the content is visible and its look like:
The most strange thing is that such a position of the block is not based on values of CSS properties as shown by Web Inspector.
As you can see the CSS properties are ok, while the position of the block is not. This fact suggest me that it could be some rendering bug of the WebKit engine
The project is built using Ext JS 3.4 and it is a classical one-page web application. This issue was seen in the last versions of Chrome and Safari on Mac OS 10.7/10.8. Though due to the spontaneous nature of this issue it might be present in other browsers and platforms too.
Any piece of advice on how to debug such issues or how it could arise is welcome.
Please check if any of your code or Ext JS's code is using scrollIntoView method, we have seen similar issue when scrollIntoView is called on any element that does not have overflow set to auto and it is inside an clipped element that is probably placed relatively positioned.
It seems bug in webkit because it scrolls clipped element which is not happening in other browsers.
I also see two elements in same hierarchy which has overflow set to auto. And scrollIntoView is scrolling wrong element.
Chrome and safari on Mac are having problems with scrolling. If the element has been scrolled and the content changes, the scroll position is kept even if the content is not high enough to require a scrolling.
The work around we have found in our application is to resize the container (the one that has the scroll) so that it has the scrollbar (or else you cannot play with the scrolling properties) and then reset the scrolling, and the height.
$(container).css('height',1).scrollTop('1').css('height','');
Here is how we do it in jQuery. You will not even see a flickering :)
I am not sure if it is the problem, but this thing kept us on our feet for a while.
i went through the same problem while working with a sencha touch 2 app and because thats same as ExtJS i have a solution for you
this probably is a bug in the framework and this happens when the ExtJS renders the application before the browser populates mayb the correct window.innerWidth and window.innerHeight and thus the viewport cannot take the correct width and height. this also explains the randomness of the event. This becomes more prominent when used on mobiles probably because of the limited resources and slow response.
the solution that i took to handle this mayb isnt a good one but i couldnt find a better one considering is a glitch in the framework itself
i poll for the correct height and width of the browser for around a sec after every say 100ms for the correct height and width of the window and if i find that the height OR width of the viewport isnt same i re adjust it. because you are working with ExtJS and app would run on high powered systems(as compared to mobile phones) i would recommend a smaller interval and then to be safe a larger time period to which it polls.
heres the code that i use currently edit according to your needs
var aId = setInterval(function () {
if (Ext.Viewport.getWidth() !== window.innerWidth || Ext.Viewport.getHeight() !== window.innerHeight) {
Ext.Viewport.setSize(window.innerWidth, window.innerHeight);
clearInterval(aId);
}
num = num + 1;
if (num > 10) {
clearInterval(aId);
}
}, 100)
i currently use this code inside the launch function of the app. but you can also use this inside the show event of the viewport for which you should keep the interval time to minimum possible to avoid any lags.
with this if you think this app might be used on devices where the window height and width would be changed by the user (like that of mobile browser when the orientation changes or if you think user would change the height and width of the browser window). then just copy & paste the same code piece inside the viewports resize event so that it also polls and resizes viewport when the size of the viewport changes.
Did you try adding a clear:both; block after the toolbar div ?
<div style="clear:both;"></div>
#bjornd it's pretty hard to debug without any code :)
Is the toolbar positioned and has the content an ID that's called in the URL?
In other words: is there some link (e.g.) that triggers #content and has no preventDefault() etc? This would scroll the page probably.
I dunno, this was the first thing that came to mind.
It could also be the toolbar content that is (for some reason) no longer cleared or some change in the content's top position (relative to another changed/removed element?)
Try and create a stripped-down test-case that contains the simplest of code but still triggers the bug. If you post that (through e.g. a Fiddle etc) we can have a proper look.
It might be a css issue;
I've had a similar issue using equal height divs by setting a padding-bottom: 99999px; and margin-bottom: -99999px;. Which workes fine in all cases, except when you use hashtag anchors to jump to a div further on the page. Jump down.
In that case the top of the page clipped and started with the div I wanted to see.
Since you say the problem is pretty hard to track, this might be something to have a look at. The solution was to remove these 2 css lines and use another method of setting div heights.
I have a container div that holds about 20 more divs that float left. When I resize the parent div with a javascript animation using Tween.js the floats don't reflow to the new size unless I mouse over one of the divs.
It seems like something is preventing the page from refreshing.
I'm thinking maybe there is a way through javascript to force the display to update?
UPDATE:
I've put it on JS Fiddle:
http://jsfiddle.net/mattlundstrom/fNUhn/
Click any thumbnail to toggle the animation.
This version uses TweenLite to animate the "Left" CSS of the #project-container. Notice how you must move your mouse after the animation to get the container's contents to reflow.
I get this result in Safari 5+ OSX and Chrome 20+ OSX. Works as expected in Firefox 13.0 OSX.
UPDATE 2
Video of what I'm seeing:
http://f.cl.ly/items/1R1n2s0U3I3c1M3s2K0T/lundstrom_float_issue.mov
I was able to recreate your issue just as you said. It seems that it is an issue with webkit redrawing or measuring the elements after an animation or transition.
This isn't the best solution by any means, but for the time being at least it will work and hopefully what I found will help other people to be able to find out more.
If you add an onComplete to the animation, and trigger the .project mouseleave, it looks to work fine:
function completeAnimate(){
$('.project').trigger('mouseleave');
}
function contract(){
// PROJECTS CONTRACT RIGHT
TweenLite.to($('#projects-container'), .5, {css:{left:"300px", opacity:".5"}, ease:Expo.easeInOut, onComplete: completeAnimate});
}
So here is my jsfiddle which has a few tests and other animation tests so that you can see some of what I tried.
jQuery animate() and css keyframe animations have the same result as the Tween code you are using, HOWEVER, a straight style update works fine.
$('#projects-container').css('left','300px');
No issues with that at all, but of course, no animation either.
Some other things I noticed was that if you take out the .project event bindings, it still doesn't redraw correctly, however if you move you mouse it still doesn't. It simply stays that way.
I also tried forcing an element redraw using a few tricks you can usually use to force a redraw. I tried this oncomplete and at intervals after the animation begins, but had no luck with any of it.
You can also combine the two tweens into one with the properties on both, just an FYI.
Hopefully this will help someone find the true issue that's going on with the webkit transitions.