defaults write com.apple.Safari IncludeInternalDebugMenu 1


Next time you start WebKit nightly or Safari, you will find a new menu called “Debug” (nope, it’s not the Develop menu.). This is how it currently looks like on Snow Leopard:

To me, the by far most useful features are the “Show Compositing Borders” and “Show Caches Window” options. Compositing borders gives you insight into the different render layers and helps you identify render issues (more on this soon), and the cache window gives you lots of info on memory usage. Finally, please note that there’s a good reason why this is hidden from us in the first place: Much of it is not self-explanatory and some of it will not work at all on your machine. Handle with care!

Enjoy! Thanks goes to Alex Russell, who gave me this very helpful tip around a year ago.

For many subsequent years, smart web developers have tried and failed to produce accurate ways to measure something that comes close to displayed frames per second on websites. Something that’d been so vital to the gaming industry for decades can’t be that hard to measure, right?

In the web world, fps map closest to redraws. Redraws (or repaints) happen when anything on screen needs to visually change (if the layout changes as well, an additional reflow/relayout will be done). Many implementations tried to address the same problem:

• running intervals at ~16ms (60fps) and check how long they actually run to produce a number
• changing the width of a DOM element and read out the offsetWidth to see if the new width has been applied
• Internal browser debug tools (namely Chrome and WebKit)
• the Mozilla-only MozAfterPaint event
• requestAnimationFrame

I have tracked all of them down for you so you don’t have to try them out only to find out later that you’ve been tricked. Yes, none of them actually work. Yes, it’s a bloody nightmare.

Running intervals is never reliable – it just tells you that the JS execution is taking time, or sometimes not even that – many browsers throttle intervals artificially in some cases. It gives you no information whatsoever about painting. Changing the width of an element and reading back the offset values is better, as the numbers are smaller (smaller = more realistic), but too small – you want redraws only, not expensive reflows. Internal debug tools, such us the WebKit Debug menu or Chrome’s flags will show an FPS counter but no FPS. Rather, the opposite – Chrome’s FPS counter goes up when lots of stuff on screen happens, and goes to zero when the browser idles. The MozAfterPaint event wasn’t reliable when I tested it many months ago. The same goes for requestAnimationFrame.

I honestly don’t know why requestAnimationFrame is such a let down. It was supposed to be the cure for all our fps needs. Browser vendors told me over and over that this is the number I’ll want. Well, it’s not. I trust my vision more than your API. And I know when the counters are lying. You’re telling me 60fps when I’m clearly seing 20.

Update: I get the feeling that it’s wrong to blame requestAnimationFrame – it’s not even meant to report the number of draws, but rather informs you when you theoretically might be able to draw. I need feedback instead.

Seriously now. Can somebody please fix this?? You’ll be my personal hero for a month and I’ll buy you a nice german beer.

He was spot on during our Twitter exchange – his Scrollability demo performed amazingly well, while our own Scroller demo sucked hard on an iPhone 4 with iOS 4 (it was ok on iPad). Joe suggested that one has to use CSS Animations or transitions to improve framerates. He also suggested to use the “scale” transform to handle content scaling. Being an early adopter of CSS Transforms and all things shiny myself, I had my doubts about the JS animation vs. keyframe animation part. My own tests on sprite animations suggested that in fact, CSS keyframe animations were not at all faster than JS animations. In addition to that, even if there was a speed increase, there are multiple issues with implementing it that way:

• Scroller is designed with portability in mind. It only handles logic, and does not apply values. It can therefore be used in any environment, including Canvas.
• Zooming isn’t as easy as just putting a “scale” transform on the content and be happy. CSS Transforms do not modify the bounding box, so the content doesn’t actually become bigger. You won’t be able to pan to the edges anymore.

That being said, I was still curious on why our demo performed so bad in contrast to Scrollability’s shining examples. So I went ahead and created a couple quick mashup demos to be able to compare the context as well as functionality. First, I took Joe’s table demo, removed Scrollability and put our Scroller on it. No content or logic changes. Compare:

• Table demo (Scrollability)
• Table demo (Scroller)

Holy crap! Now that both are running in the same demo and scenario, performance on both is amazingly similar on an iPhone 4 running iOS 4. Scrollability still feels a tick smoother, but both are very usable and nice. I wasn’t finished yet so I created another interesting test case, putting Scrollability into our own DOM demo. In order to be able to compare, I deactivated zooming and horizontal scrolling on both. Here are the results:

• Fancy demo (Scrollability)
• Fancy demo (Scroller)

This is pretty amazing. On my iPhone 4, I found Scroller outperform Scrollability by a quite visible margin, and the margin is even greater on Chrome for Mac. At this point, I don’t have a clue as to why Scroller performs better – one possible reason might be the missing scroll indicator.

Update: I have heard from a couple people that they couldn’t confirm Scroller being faster than Scrollability on iPhone 4. After hours of debugging, I finally found out why they saw so different results. If you have the debug console in mobile Safari enabled, Scroller will always outperform Scrollability. If you have it disabled, Scrollability will outperform Scroller by a great margin. It’s completely mysterious, and it doesn’t help that Apple doesn’t give us debug info. I will continue to investigate what the issues are and update this blog post. Stay tuned.

Update 2: Obviously it had to be something silly. It wasn’t the viewport size. It wasn’t even the Scroller. It was the logging of debug values into input fields that caused a dramatic slowdown in Scroller when the debug console was not activated. I still have no clue why it was fast with debug on, but the riddle is solved. Scroller now always outperforms Scrollability.

In the end, I have learned that it’s not only the code itself that makes things fast, but the context. Only by comparing against the same context, the same markup in our demos, I was able to realistically learn about performance impacts. But as with all comparisons, take it with a good grain of salt. While Scroller and Scrollability have overlapping featuresets, there’s things that are different: Scrollability has a scroll indicator while Scroller doesn’t (it’s all logic, really), and Scroller additionally comes with zooming, both directions scrolling and some more.

And both have their respective use cases: I found it amazing how simple it was to setup Scrollability – it’s a great and easy plugin if you need simple scrolling content. For advanced scenarios such as games or more interactive content on Canvas or WebGL, I encourage you to try the Scroller. It requires more setup, but comes with greater flexiblity.

Until next time!

License holders such as the labels and associations like RIAA or GEMA think of games mostly as boxed units. This works fine for games like Singstar. You go to the store, spend cash on the game, and a (pretty big) portion of it goes back to the license holders and artists. That’s cool though, as it makes sense: After all, the game’s business value is dependent upon the music, so it is only fair a big portion is shared.

Welcome to 2011, where the largest percentage of gamers plays on Facebook, tablets and mobile phones. As much as you don’t “buy” Facebook or Google, you don’t “buy” a Facebook game. Games are becoming interesting consumer platforms more than ever. Some of them are always on, always engaging and a new layer of social interaction. The prior business model of adding music simply does not work any longer for these types of games.

Another proposal from the licensing industry has been pay as your customers listen, a.k.a the “radio model”. Yeah, pretty much what you think: Game developers are expected to pay as much for the usage of popular songs as if it would play on the radio. It’s viagra to forget that – again – the business model for radio entirely depends on the music – better music is directly proportional to more listeners! No, games are not radio channels.

Here’s a twist. Embedding popular music into games is a great privilege for the license holders and artists, not vice versa. It’s an unprecedented way to market music in highly interactive and engaging ways. They should be *dying* to get their newest music added to the most popular games on Facebook, and beg browser game developers to develop new interesting ways to integrate the music into their game worlds in smart ways. Hell, if I was running a label, I would not only give them my music for free, I would *pay* them.

background, stepped

This is by far the cleanest solution, and the solution I recommend for desktop browsers. It animates the background position, doesn’t involve any hacks and uses the new step-start easing property to disable easing, which, I found out, is implement in latest WebKit and Chrome already. Woot!

background, eased

Unfortunately, not all browsers (i.e. Safari, on both iPhone and iPad at least) support the step easing functions at this point, so a workaround is still required here. However, Doug Neiner found a better hack than me, which goes like this: Instead of doing the crappy resizing, simply double the keyframes and have a very low percentage keyframe before every change, which tricks out the easing. I recommend reading the source of the demo to get a clear picture. It rocks, and works reliably!

translated, stepped

I really really wanted to see if it was possible to accelerate animations on browser that feature hardware acceleration on CSS Transforms – in particular, iPad and iPhone’s Safari. As it turns out, it is possible – simply add an inner <div> resize it to the spritesheet full dimensions and put the background image there, set the parent div to overflow hidden and animate using translate3d(x,y,0). This, as it turns out, gives roughly a 300-400% performance increase on iPad – not bad, huh?

translated, eased

Might be obvious already – the above is great, but still looks broken on iPad. So again, we are using the brilliant little hack Doug came up with.

That’s it (harhar!), enjoy: Demo (run this on any WebKit browser)

I’m lazy, show me the end result first!

CSS Animations are great – they are a lot less pain for the normal web developer, are rendered more smoothly as the browser can control the framerate, and even become hardware accelerated. You can animate almost everything with it and be happy. Unfortunately, 90% of animations a classical 2D game engine requires cannot be implemented via CSS Animations: yes, I’m talking about the good old sprite animations.

Sprite animations require a big spritesheet that includes all frames (I use big png’s), and for the render, only the size of a frame is shown, while the animation is done by shifting the masked image. In web development, the easiest way to implement sprite animations is by utilizing a <div> with the spritesheet set as background-image, and then shifting its background-position via JavaScript. So since background-position really is just a CSS property, CSS Animations shouldn’t be an issue, no? You bet.

CSS animations are implemented around the concept of keyframing. You define a key rule, name it, and then define keyframe rules in percentages. Within these rules, almost every CSS property is allowed (no gradients, unfortunately!). As second step, the named keyframe animation is used like a variable and placed upon another css rule, using the -webkit-animation syntax. It is important what happens now: if you create two keyframe rules at 0% and 100%, changing the background-position-x from 0px to -100px, it will create frames inbetween for a smooth transition. This is usually very nice, but it destroys the idea of sprite animating: sprite frames need to be switched from one to another instantly, not scrolled!

Frustrated as I was, I gave up and let it go for now, implementing it in JavaScript instead. Today though, I revisited CSS Animations with new knowledge and new motivation, and yes, finally found out how to do it. Let me show you how.

The markup

This is the easiest part. Just a div with a class.

<div class='animated-sprite'></div>

The basic CSS rule

We now continue with the CSS, starting to style it as if we would animate it normally via JavaScript.

div.animated-sprite {
	width: 86px;
	height: 90px;
	background-image: url(animated-sprite.png);
}

Where do the values come from? A single frame has the size 86×90, so we resize the div to exactly the size of one frame. This should therefore display the first frame of the spritesheet that we set as background.

The magic sauce

This still looks to simple, right? Well, lets spice it up! We now change our markup to the following:

div.animated-sprite {
	width: 1px;
	height: 1px;
	background-image: url(animated-sprite.png);
	background-size: 7px 6px;
	-webkit-transform: scaleX(86) scaleY(90);
	-webkit-transform-origin: top left;
}

For those of you who end up thinking “Holy crap, what is he thinking?!”, let me detail what this is doing:

1. scale the element down to 1px by 1px
2. scale down the background in proportion using CSS3′s background-size
3. scale it up again using 2D CSS transforms
4. set the transform origin to the top left corner so the scaling doesn’t move the element

If you closely followed the instructions, you will notice that the element looks exactly the same than before, with the much simpler rule above. Usually, I was expecting to see a blurred pixel – after all, you are scaling up a one pixel element! Luckily, 2D CSS transforms are smart enough to remap the actual image resource after the scale, realizing that the original image is of a higher resolution, and then displaying it with the highest resolution possible. Now what is this good for, you might ask? Read on.

Tricking out the easing

The whole purpose of resizing the element to the absolute minimum the browser can handle, is that it’s also the absolute minimum CSS transforms’ easing can handle. This means if you animate something via keyframes by a single pixel, it cannot tween inbetween, meaning it cannot do a subpixel transition. This is good, as we just fooled the CSS transform engine: We can now animate the background position by single pixels, which the result ending up shifting the background spritesheet by a whole frame, without any transition inbetween. Keyframes become frames.

Creating the final keyframe animation

Now all that’s left for us is the actual CSS animation that we still need to create. This is painful by hand, so I created a little helper function that generates them on the fly. Enjoy:

function generateKeyframeAnimation(animationName, frameWidth, frameHeight, spriteWidth, spriteHeight, frames) {
	var css = '@-webkit-keyframes ''+animationName+'' {', step = 100 / (frames-1), horizontalFrames = spriteWidth/frameWidth;
	for (var i=0; i < frames; i++) {
		css += 'n'+((i) * step)+'% { background-position: '+(-i)+'px '+(-Math.floor(i / horizontalFrames))+'px; }';
	};
	return css+'n}';
}

But in the appropriate values and as animationName any name the animation should receive, and it will return something like this:

@-webkit-keyframes 'animated-sprite' {
	0% { background-position: 0px 0px; }
	14.285714285714286% { background-position: -1px 0px; }
	28.571428571428573% { background-position: -2px 0px; }
	42.85714285714286% { background-position: -3px 0px; }
	57.142857142857146% { background-position: -4px 0px; }
	71.42857142857143% { background-position: -5px 0px; }
	85.71428571428572% { background-position: -6px 0px; }
	100% { background-position: -7px 0px; }
}

Take this and put it in your CSS, then add a couple animation rules to the actual animated-sprite rule, so the end result will look like this:

div.animated-sprite {
	width: 1px;
	height: 1px;
	background-image: url(animated-sprite.png);
	background-size: 7px 6px;
	-webkit-transform: scaleX(86) scaleY(90);
	-webkit-transform-origin: top left;

	-webkit-animation-name: 'animated-sprite';
	-webkit-animation-duration: 1s;
	-webkit-animation-timing-function: linear;
	-webkit-animation-iteration-count: infinite;
}

This will tell CSS to map the animation we just created to this element, have it executed in one second (I’m doing 8 fps here), and playback should be linear and looping.

The final result, with some caveats

That’s it, really! We tricked out CSS transforms, had keyframes become frames, and have awesome sprite animations running with nothing but pure CSS. Neat, huh?

Final running demo

However, there are a couple of caveats, which is why this is very experimental, and not meant for any production use:

• This will not be faster than the JavaScript animation method. I was thinking to speed it up through hardware accelerated 3D transforms, but scale3D unfortunately ignores the image resource, and actually produces a big blurred pixel when scaling the 1px image up again.
• There’s a little bump at the end/start of every loop. I don’t know why, but I bet it’s related to how CSS transforms jump from 100% to 0%. Might be fixable.
• This requires tons of generated CSS for larger animations, not really practical. A JavaScript engine can compute steps on the fly.
• This is only a temporary workaround, until all browser implement the ‘step’ easing property. It will automatically disable the easing, with no crazy workarounds required.

Enjoy, until next time!

So why do I dislike dialogs that much? After all, I have written countless JavaScript implementations of dialogs and overlays in the past, and we have one in jQuery UI for quite some time now (and while I’m starting with my rant, keep in mind this is purely my personal opinion, not the one of the jQuery UI team). Diving into the browser and social game world, it slowly became crystal clear to me what the issue really is about.

Dialogs invite you to be lazy.
Solving the issue of navigation and interaction within your information architecture of your website or game is a very hard challenge. “Uh, if I just had a good place to put that invitation feature somewhere in my UI..”. If you are a web designer or developer, chances are you shared a similar frustration before. But wait! Thankfully, there’s an easy way out. Just take the feature and pack it in a dialog! That way, we don’t have to clutter our UI and can hide certain features, bring them up when needed. …right ?

Let’s turn it the other way around to see what’s going on here. By using a dialog, lightbox or overlay, you are effectively cheating. The content in your dialog will not fit into your centralized user experience, and remains disconnected. Your users have a harder time to relate to features in lightboxes. Even worse, modal dialogs often break one of the most important rules of great user experience: Never block the interaction of your users an your product.

Dialogs are the new popups. So the next time you are setting up a dialog, take a break and think about a better integration.