I'm attempting to create an animation by moving a sprite image across a div. The sprite image contains each frame of the animation. The size of the "canvas" is 600px by 624px. Each frame on the sprite sheet is positioned every 600px and I'm moving the image 600px at a time.
Here is what I have so far...
voyced.com/crownacre/www/demo/sprite.html
I'm using the following JavaScript to move the image across the screen...
(function myLoop(i) {
setTimeout(function() {
defImg.css({
right: '-=600'
});
if(--i) myLoop(i); // decrement i and call myLoop again if i > 0
}, 60) // delay ms
})(114); // number of frames in the sprite
I've used several sprites all floated left as the total width of sprite sheets in 69000px, which causes even more issues if I use just one image! Hence why I have 4 at the moment.
So... The problem I am having is that the animation pauses briefly several times. It seems fine in Firefox (for me), but you notice it in Chrome and you can't miss it in IE.
It also always stutters every 16200px, making me think this is related to moving 1 sprite into the next on the screen.
Ideas please people?
Thanks in advance!
Have you tried using a sprite animation plugin?
http://www.spritely.net/
Does what you want, seems to run well on their demo.
Let me first say: The huge images you're trying to display as a sprite isn't exactly what sprites/animations are used for. You can better look into a real <canvas> solution (especially when looking at your animation), but that would require some more complex JavaScript skills.
Anyway, the problem with the stutter is because you're using several images that are all floated to the left, and position the slider with the right property. Each time another image needs to be displayed, a stutter can be noticed. This might have something to do with the browser engine, needing to paint the actual image (which is hard, since they're pretty big).
So, instead of using several images, you could also use one (take note, you might want to make this a .JPG or .GIF since they tend to be more compact than .PNG) and use actual CSS sprites with background-position.
Here's an example that uses your code, and one single image. Good luck!
Thanks again for the feedback guys. I used a combination of your tips that have helped me solve the issue I was having.
Spritely has helped immensely. Essentially it is doing the same as what #marcoK suggested, and adjusting the background-position property. This plugin also provides a fool proof way of controlling each frame of the sprite, as well as creating callbacks when it reaches a specified frame - awesome!
The other issue was the huge sprite. Mobile safari won't allow anything larger than 3MP so the max size I could make the image was 4800x624. I have 15 of these each as a separate animation that calls the next when it reaches the last frame. I was very sceptical about this working smoothly, but it does, and in all browsers.
I'm not overly happy with the number of request it makes but after optimising the pngs the file size isn't too bad if I add a pre-loader.
Really pleased with the outcome... http://www.crownacre.voyced.com/ and one more reason not to use Flash!
Related
I'm building a parallax scrolling website (aren't we all) that amongst other things, reveals an image as the user scrolls.
I've done the 'reveal' by putting the image in the background, and placing a solid filled div on top. I then animate this div from 100% height to 0% height based on the scroll position, thus revealing the background image.
I'm doing this kind of thing multiple times and unfortunately I'm getting slow down.
Using Chrome's built in Timeline feature, I can see that most of this slow down is from Image Decodes. For the above reveal, it's re-Decoding the image every frame, which takes 22ms per image per frame.
Does anyone know when the browser needs to do Image Decode and when it doesn't? It seems obviously to me that it would need to if I resized the image, but not that it would need to when I just half cover the image?
Thanks for your help.
I've battled with this problem a lot also. As yet I have not found anything concrete and my proposed solution does not seem to work in ALL cases and I have not been able to ascertain why.
Anyway...
It appears that when you animate a solid element over the top of an image, chrome forces a recode of the image.
There are two things I have tried and for the most part they have been successful.
If you add -webkit-transform : translate3d(0,0,0) to the covering element, you should find most, if not all of the image decodes disappear.
If adding the above CSS to the covering element itself does not help, try adding it to the image instead, or indeed try adding it to both elements.
My understanding is that using the 3d css property pushing the image into its own composite layer which is cached and handled by the GPU rather than the browsers software renderer.
90% of the time I have found one of the above combinations successful. I hope it helps.
How do you animate the property? I think you may have plenty of alternatives to just animating the height (which is some sort of resize of the container).
Maybe it's less intensive to just 'clip' the background image with another element. I found a thread about it on StackOverflow with some suggestions. If you animate with javascript, unfortunately pseudo elements are no option...
Clip/Crop background-image with CSS
Is it possible to count how many times an animated gif has played with javascript/jquery?
Nope, that's not possible.
However, you could create an interval using setInterval with the duration of the animation which increases a counter.
As #ThiefMaster says, You can't do this with a GIF anim.
However, you can achieve what you want using a javascript animation.
Rather than saving the frames of the animation in a GIF anim, save them in a single PNG file, in a row (ie so it looks like a reel of film) either horizontally or vertically.
Display the image in an element on the page that is sized so you can only see one frame of the animation at a time, and then use Javascript to adjust the CSS offset of the image at regular intervals using setInterval or setTimeout.
This technique is known as CSS Sprite animations. It's easy to do, and it's basically the standard way of doing spot graphic animations on the web now (GIF anims are soooo 1998).
Google will give you plenty of resources to help you find out more: https://www.google.com/search?q=css+sprite+animations
You might also want to read the accepted answer to this question: Why not animated GIF instead of animated CSS sprites?
In recent trends I've seen people animating CSS sprites using JavaScript instead of using animated GIFs?
Ex:
http://www.google.com/doodles/eadweard-j-muybridges-182nd-birthday (in fact, Google used this technique in other Doodles too)
https://everyme.com/ ('me' logo)
and many more...
Is that all just to show or experiment with technology or are there any benefits out of it. I m interested in knowing the benefits, if there. The reason I m asking is that I couldn't figure out as in both cases we need to generate the intermediate frames (mostly using tweening technique).
Control
You have no control over animated GIFs. You can't start them, you can't stop them. They just animate as soon as they load.
With sprites, you can control the animation. You can start, stop and react to browser events, pan through the animation. For example, Google Doodles usually activate when you click on them.
A nifty GIF control system can be found in the 9gag. You can start them by appending them to the DOM, and stop them by removing them and swapping them with a pre-generated "first-frame view". But that's as far as GIFs go.
Independent Instances
When you load multiple instances of the same GIF, all these instances use the same image across the page and move at the same time. If you have a row of dancing unicorns GIFs, they'd be dancing at the same time. Synchronized dancing!
But with sprites, even if you are using the same images, the animation relies on the underlying script. So if one sprite is animated by one script and another by another script, both animations can run independently, and differently from one another.
This saves you from creating another GIF and it's easy to modify since you are only changing the script.
Ensuring smooth animation
Animated GIFs just animate while loading, and when the internet is slow, the animations freeze up until more of the image gets loaded.
In contrast, the advantage of sprites is you can pre-load them, ensure all images load beforehand. This makes sure that the resources used for that animation are already loaded prior to animation to make sure it animates as smooth as possible.
However, GIFs are still images. You can dynamically load them off the DOM and listen for a load event before you append them to the DOM.
Partial rendering
With PNG sprites, you can do "partials" in the animation, breaking an animation scene to parts. For example, when a character stands still, but the arms are waving. You don't need to animate the entire character, or the entire scene. You can place an element depicting the sprite of the character's body in a "freeze" state while the arms are a different element that is animating. This conserves space and size of the sprite sheet. A good example for this was the 2012 Mother's Day Doodle by Google.
In contrast, most of the time, every frame in a GIF animation is whole image, and animates whether or not anything in it moves. The more frames, the bigger the size of the GIF.
GIFs just don't scale
GIFs were meant for icons. The ratio of file size to image size don't scale up that well in GIFs as compared with PNG and JPG.
On top of Joseph the Dreamer's answer...
As far as I know, or atleast it used to be that, GIF files are NOT true colour, another reason to use a JPGs/PNGs as a css sprite.
I created a webgl animation using scenejs library (start it by clicking the button at the bottom left, note it plays music as well which you can't currently disable).
The problem I am encountering is that the floor/plane in the middle starts flickering and continues to flicker/blink through out the animation. Only towards the very end does the flickering lower and by the end stops completely (when the plane is about to end).
If I reduce the size of the plane to 10% of its size (from ~26000 to ~2600), it does not flicker at all.
I've tried adjusting the texture scales, has no effect. Lowering the fps didn't seem to have an effect either. Does WebGL have problems rendering large objects? Are there any work arounds this?
Could probably make the plane static, and have the texture of it moving, but it certainly would make a lot more things trickier, especially when more elements are added to it.
Setting the requestAnimationFrame had no effect, nor did removing the flash video. The only time it works fine is when the plane is significantly smaller, or when it is reaching the end of it.
Scene looks fine to me - what happens when you remove the Flash?
PS. Share this on a jsFiddle if you like..http://jsfiddle.net/
Also, what happens when you use the requestAnimationFrame option for the render loop?
Example here:
http://scenejs.wikispaces.com/scene#Starting
Simple question, really. I just don't have the knowledge to do this with JavaScript, and to also make sure it works with (almost) all browsers...
I am going to design a set of images of a person pointing with one hand in several directions. (Up, down, left, right, diagonal, etc.) Basically, this puppet will be pointing at the location of the mouse. To do so, I want to use an animated GIF file to contain all the images and then use JavaScript to bring the right image to the front, based on the position of the mouse in relation with the image.
My knowlegde of Javascript is very limited, though. Before I even start creating the GIF images, I want to know if it's possible and if there's a solution that would work on any web browser. (Unless it doesn't support JavaScript, of course.)I know it's possible to delay an animated GIF from JavaScript but is it also possible to modify the exact image that needs to be displayed?
As far as I know, this is not possible.
Stuff like this is usually done using the "CSS sprites" technique, where the various stages are glued next to each other into one giant image. That image will then be used as background-image in a smaller element. background-position will determine which image is shown.
Whether this works for you will depend on whether your images are all the same size or not. It has the advantage of working reliably in all browsers, even IE6.