Develop Reference

Flip clock is flipping backwards instead of forward

In the given Codepen below, there is a flip clock on the tomato. Currently, the flip clock is counting down correctly, but the actual flippers are flipping backwards, away from the viewer, rather than forwards. I think that the problem may have to do with z-index switching, or possibly the fact that some aspect of the transform has been rotated 180deg (most likely the former, as the latter would ostensibly affect the whole clock, not just the shadows of the flippers).
Here is the link to the Codepen.

I've had the same problem.
Your CodePen is currently using the minified version of flipclock.css from https://cdnjs.com/, switching to the full css file should fix your issue.

html5 audio FFT real-time canvas drawing without any animation or fade

I want to get realtime fft frequency numbers on specific ranges of frequencies. It must be drawn into canvas without any animation/transition/fadeout effects, switching between frames.
I found some scripts. like
https://github.com/wayou/HTML5_Audio_Visualizer
https://github.com/cwilso/AudioRecorder
I tried to adopt these scripts, but I didn't found the way to remove transitions between bars. I want bar to appear only if currenct level in current ms is "x", no slowly-fading-moving-down, and another animations.
It seems canvas don't support changing fillStyle of already created objects.
I even tried to do it oldstyle without canvas, draw some bars and change opacity, but it don't work on top of video, having non-transparent border.
Using real mic input, as shown in second link, if you stop the sound, they all fading and moving down slowly... Is there any way to avoid this?
Maybe KineticJS will help?
Also, is it possible to lower buffer to minimum for mic input, to avoid delay of processing??
Please help!

Finally I found the answer. It was analyserNode.smoothingTimeConstant, which has high default value. I put it 0 and all went as I want!
Thanks!

Stutter when animating / moving sprite with JavaScript

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!

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.

multiple objects to render on very long area, canvas?

I need to display a very long area (without defined length) with many polygons (simple shapes - circles, squares, some text). Obviously I need only small fragment visible at a time. Main problems are efficient scrolling and handing mouse events. I write in GWT. Things i considered so far:
1) canvas. create a canvas with the size of visible area. Create buffer canvas larger then visible area. Render to the buffer (only changes - if something is changed in the visible area or new parts to the right/left during scrolling). And when required, render proper part of the buffer to visible canvas. This seems to work fast enough. But! I have to implement this smart buffering, decide which part needs to be rerendered and which not. And I need to remember all object to detect mouse clicks and mouseovers (and it should be some nice structure like interval tree or segment tree, as mouseover checks are very frequent - but this is already implemented in the browser, sounds like reinventing the wheel) - this is A LOT OF WORK!
Maybe there is something ready?
2) html (divs/images) - so, the idea is to render all elements with divs and images (images can be generated on canvas first, doesn't metter). Position them absolutely on a long div and use browser scrolling to scroll the div. Works until you reach the end of this long div and you need to reposition everything so there is more space to scroll (and this will freeze scrolling for some time). So maybe it would be possible to render in a second div in the meanwhile and then switch them.. It might work, but this sounds like a hack and it will probably have serious problems with multiple objects visible at a time. Plus for mouse events implemented in the browser.
3) SVG - I haven't tried, but I think I will run into the same performance problems as with html/divs (when scrolling to right/left)
Any ideas? Which approach is the best? Is there anything better? WebGL (it won't work in IE and porting to IE would be hard prob). How should I implement this?

You seem to understand the pros/cons. Canvas is faster, but it's lower level, so it's harder to code. DOM is slower but easier to code because of its event handling and object access. If DOM is too slow, you have to resort to canvas.
One possible compromise is to render the full canvas and clip it using overflow:hidden. That's what I did on a waveform display I am working on.
SVG should be easier than the DOM for shapes. Since SVG is not completely cross browser, you should use something like http://raphaeljs.com/

I would go with canvas as it's relatively fast.
As far as off-screen positioning, mouse events, and re-rendering — it could be all taken care of by using canvas library like Fabric.js. Take a look at the demos.
Event inspector demo & working with events tutorial might come in useful.
Off-screen (not) rendering is taken care of by default. Just position objects at off-screen coordinates and they won't be visible.