I am in the process of building a website full of SVG illustrations that have animated components that are being animated with Bodymovin.
But the backgrounds are also sometimes animating to show movement (a runner SVG with his arms & legs moving and a background SVG moving right to left showing progress).
Am I right in trying to limit using Bodymovin to the complex animations for the characters so I can use CSS transform3d animations for the simple background movements?
I'm trying to make things animate smoothly whilst being easy on everyone's browsers!
I would usually install GSAP and animate stuff with that, but that would mean adding a second JS animations library for the backgrounds as the client has a designer generating the Bodymovin animations.
Any advice would be welcome. Thanks
Bodymovin appears to be lagging with multiple animations on a page, so I ended up animating the backgrounds with CSS animations to keep the browsers' workload to a minimum.
And through animating translate3d, the css animations were smooth, too.
Related
I need help with animation performance on RETINA display
I have a swiper slider and on slideTranasitionStart I'm animating a mask (covering the whole slider).
Codepen link here.
The animation is very smooth in all browsers. I'm using an external monitor for work but as soon as I drag the browser window to my retina display (MacBook Pro -Retina, 13-inch, Early 2015, macOS Mojave) the animation looks is very laggy (lowest fps is around 5-6!) !
I tried 2 main options to do the animation:
Adding classes to transform the mask (and only using the most performant css properties transform and opacity on the animated elements). For this option I tried adding will-change property on the animated elements, I replaced translateX with translate3d, I only added transition on the transform property.
Using greensock morphSVG plugin to achieve the transforming of the mask (in the codepen demo I'm using this option as it's way less code)
Unfortunately both options are still laggy on retina display.
Nothing seems to improve the performance on the retina display and I'm running out of options.
I'd be very grateful if someone can help out!
Thank you
I have a simple blog that i'm developing using create-react-app (using react-scripts#next to get CSS Modules support).
Repo
Demo
The problem i'm having is the CSS hover transitions are very laggy and slow. I previously implemented this interface using Node EJS templates and everything was snappy and fast.
I'm thinking the problem maybe has to do with the PostSummary component receiving new props and re-rendering constantly, but all the props appear to be static once they're loaded.
I checked the Chrome performance tab and it said the majority of the cycles were being used by paint time (and not load time).
Very confused, anything I can test to resolve the issue?
When you have animations that you know will fire, it's good practice to use the will-change rule, to help the browser be more efficient.
Adding the following rule improves performance in Chrome substantially:
will-change: transform, box-shadow, z-index;
Also, check out this article. It provides AWESOME tricks to help improve the performance and animations on your website.
https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108
One thing I see is that on hover you're changing the z-index. That has a possibility of slowing things down, so just be mindful when using any of the positioning rules. The transform: translate rules are much more performant than top, left, right, bottom, z-index. Not sure if you can get around using z-index or not with your design, but it's good to keep it in mind anyways.
Animating large images will cause performance issues. The first image in your example is: width: 5264px; height: 3393px;. Optimize the images for web and they should load quicker and animate smoothly.
Consider animating text and pure HTML elements, but try to avoid animating large images.
When you resize an image by transitioning it has to render the image multiple times during the transition and is very "expensive".
I am developing a website using parallax. Just a brief note on what I did so far.
I used the skrollr plugin for generating the parallax effect. With this plugin I was successfully able to move elements with different scroll speeds. However, there are a few major issues I really to resolve.
Given your understanding and guidance I look forward to get through them.
Here is what I am trying to address:
1) The site that I developed is not responsive with parallax. Data attributes for elements are written inline (and thats how so far I think they are written: inline). So because of that even on screen resize, the inline styling of data attributes remains intact. Hence, the responsive stuff for parallax (on desktop version) is not able to produce same effect on mobile versions.
2) I checked the sony website. Link : http://www.sony.com/be-moved/
They have used parallax and the site is responsive.
Parallax websites are based more on the imagery content. So, how does the site load faster when the images are of huge sizes. (Running into MBs). The sony website has very heavy images (size running into MBs). How do images of such heavy sizes load so fast?
3) Again, coming back to the sony website. On scrolling the user is shown various perspectives / angles of sony products. So, how are the multiple perspectives of every product captured for scrolling.
How is such precise sequential image with varying perspective for every product shown on scroll?
Its the entire background image that changes perspective. So, how is that done? Thats not just plain parallax, right?
I am mentioning this site because its implemented in a differenet way from other simple parallax websites. Sony's implementation is what I am interested in!
4) What would be best to do? Changing background images on scroll(like the way its done on sony) or changing the position of single elements using data attributes?. (like its done on www.numero10.ch)
I have been asked to implement parallax in two ways:
a) only move the elements within the background. Like if its a sky image with two clouds on the right. Then just consider moving the two clouds to the left on scroll.
or
b) Have different background images with the two right clouds moving to the left. So, that means I will have a volley of images for just moving the clouds from right to left; with every image having two clouds shifting towards left by pixel positions.
Looking forward for a reply. :)
Thanks for your patient reading.
I think this will lead you to the right direction: https://ihatetomatoes.net/sonys-be-moved-website-deconstructed/
It explains in detail exactly how the Be Moved website is constructed.
2) I believe they use something called "Lazy Loading" which is displaying a "fake" lighter image until all the HTML,CSS,JS is loaded to then load the real images and replace them.
3) That is not mere parallax , they are using the canvas element ( How exactly I don't know but check the page source )
4) It is better to leave an image as a fixed background and work with smaller elements.
I think that site is not just parallax layered scrolling, It is a combination of a sequence of video clips triggered on scrolling. I have not inspected the element of site but I think so. But site is loading tremendously fast compared to other such sites because of your cache in your system and implementation of lighter images in the starting and heavier images at last
Webpage is - http://schnell.dreamhosters.com/spriteanimate.html
Just go to the page and 'View Source' and you'll see all the code.
Right now it's pretty simple. Right arrow key makes X go right, left arrow key makes him go left. He does a running animation in the proper direction and the actual image element moves in the same direction.
The major issue I have with this right now is optimization. If you play around with it a little you'll notice that the running animation isn't always smooth and for the first few seconds it feels very laggy, like it's still loading something. The animation for going left is particularly guilty of this. Another problem is with the .animate() from jQuery. It does a sort of stop-and-go motion and you can tell. The movement of the image element is jerky and not very smooth.
The .animate() from jQuery can be tweaked with easing and such, but I'm not entirely sure if that's the answer and that still leaves me with the occasional running lag or something. So does anyone have any suggestions?
Use image preloading for the sprite images, or better still, use one image as a sprite, and instead of swapping the image file, shift the position of the image file. You need to set the image as a background image and shift the background position to achieve this.
Also, use linear easing, otherwise it will default to swing, which enters and exits slowly.
Have you considered using CSS3 transitions rather than standard jQuery animations. In doing so you'll have dramatically better performance but lose some cross browser compatibility. Here's an example which only works in Chrome but shows the power
http://girliemac.com/sandbox/matrix.html
and more about CSS3 animations
http://css3.bradshawenterprises.com/
I'm working on a web page with an animated background. I'm using MooTools to crossfade a series of images that are of a decent size (like 1100px x 750px).
I think since the browser is having to do so much rendering work crossfading these images, when you make the page fullscreen, the crossfade animation will become choppy.
In looking for ways to overcome this, I'm already planning on rewriting the slideshow in the most efficient JavaScript I can muster.
Does anyone have any other ideas on how to have the animated background run smoothly at large browser window sizes?
Crossfade effect is expensive and you'll get very low frames per second at that resolution. Instead of a crossfade I'd try a slide up/down/left/right or wipe effect. I'm a big fan of the jQuery tools Scrollable plugin.
AS you said yourself, this is probably a rendering issue, and not really an issue with the speed of your javascript, especially since there is a performance difference between fullscreen and non-fuulscreen.
I doubt optimizing your js will have any real effect.