Hi Byron

Have you noticed that the animation speed set by resizeDuration is very different on different browsers? On my system (Win7 64, Intel i7 2.93GHz, 8GB RAM) the animation is smooth and takes about 1.25 secs on IE9, Chrome and slightly slower on Opera. On Safari it takes about the same time, but the animation stutters, particularly the background overlay. But on Firefox (v14, but I've noticed this on the past few versions) the animation is much faster and almost jerks the image into view in about 0.5 secs. This is timed on the first image gallery on your demo page, but it's consistent with what I see on my sites whether run locally or from the server.

I can live with the stuttering in Safari on PC as I doubt many people use it (I only have it for testing - and I've not noticed the stuttering when I've checked out FB on a mates Mac), but are you aware of anything that's changed in Firefox over the past few versions that could be causing this?

Hi Roy. It's nice to hear from you again. As usual, you've accurately zeroed in on some interesting behaviour here.

... <admin: inaccurate and out-of-date information removed> ...

Summary: The next version of Floatbox will have more consistent animation speeds, Safari will improve only if the Safari team improves it, and a big 'thank-you' to you for raising this.

I've overhauled the animation timers for future releases and want to provide a few details here so as not to leave the out-of-date information in my above post as the last word. This post is of no value to folks who aren't curious about the technical details inside Floatbox.

Most computer monitors' refresh rates are 60Hz, resulting in a screen redraw occurring once every 16.67 milliseconds. This marks the upper limit of smoothness when displaying animations or movies. If the screen content is being updated at twice this rate, half of those updates will never be shown or seen.

In the next release, I've removed the use of postMessage to invoke rapid redraws. This technique was a benefit when timer-based redraws were typically clocking in above the monitor refresh interval regardless of the requested interval. The postMessage trick would get the screen redraws happening faster than the monitor refreshes and resulted in a visible smoothing of the "zooming" images on some platforms.

Hardware and software has advanced considerably since then and we can now see fast browsers doing image redraws multiple times each millisecond using the postMessage technique on fast hardware. This excessive number of unseen repaints is not really a problem as it pretty much guarantees that the content will be at the right position and size when the next screen refresh occurs. But as Roy brought to my attention, having the redraws significantly out-racing the 1 millisecond resolution of the system timer can mess up the arithmetic and result in the animation racing to completion too quickly. Those extra redraws also tax the CPU unnecessarily.

Modern browsers are starting to implement a built-in requestAnimationFrame function, the purpose of which is to maximize animation smoothness while minimizing CPU load by synchronizing content redraws with the 60Hz monitor refresh rate. This showed up in Firefox 12, Chrome 12, and will likely appear with IE 10 and Safari 6. Floatbox now uses this function wherever it is available.

When requestAnimationFrame is not present, Floatbox falls back to using the old-school setTimer function with a requested delay of 13 msecs. This value was determined by testing to give all browsers sufficient time to process the screen redraw before the next 16.67 msec monitor refresh occurs. Very old browsers or slow hardware will continue to fail to redraw at the 60Hz rate but these are the same platforms that either lacked postMessage or could not process the redraws fast enough under the old strategy.

The new technique using requestAnimationFrame or 13 millisecond timer requests retains maximum smoothness of the Floatbox animations, reduces CPU load, and solves the racing animations that Roy reported. It remains to be seen whether Safari 6's implementation of requestAnimationFrame will resolve its jerky animation problem on the Windows platform.

Really interesting read, Byron. I knew if anyone could get on top of this you would.

This just in:
It looks like Apple might have killed Safari on Windows. There is no longer any version for Windows offered on Apple's Safari download page. This seems like a satisfactory resolution of the animation problem on that platform.

But makes it harder for testing unless you have both Mac and PC.

Just installed 5.4.0. It was already at 11, but now you've turned Floatbox up to 13. It's nice to have the smooth animations back in Firefox. Great work, Byron.

You're certainly on the ball. You must have notifications setup somewhere. I was just about to contact you and ask you to check your Firefox platform. Glad to see we got a thumbs up.

I'm subscribed to your announcements thread and you also show up in my news feed. I like to keep up-to-date!