create blog

go home go home
  1. about
  2. code
  3. wiki
  4. blog

Posts Tagged ‘javascript’

JavaScript Animation Benchmarks

Wednesday, October 21st, 2009

I’ve been working on a mixin to add animation to SproutCore views.

The current version only works for layout properties, and does not yet work for centerX and centerY properties (they used to work, but some of the performance optimizations have made it slightly more tricky—I’ll be adding it back soon, though).

I decided to see how fast the code was in different browsers. The tests were done using a test application which generated a specified number of views, and then, once per second, updated a “frames per second” display. The measuring is somewhat subjective, as I have to deduce, based on consistency (or lack thereof) in the numbers, what the frame rate actually is. For the most part, they were pretty consistent, but the WebKit browsers at really low numbers of views (and really high frame rates) could be quite inconsistent at times.

I ran the tests on two separate machines:

  • Mac OS X Snow Leopard on MacBook Pro 15″ Core 2 Duo 2.33Gz w/2GB RAM. Lots of open programs, including iTunes. Not as scientific as would be optimal, but it is my work machine.
  • Windows XP on Pentium 4 3.20GHz w/2GB RAM. Only the browser was open.

Browsers tested (note that my Firefox was OLD):

  • Safari 4.0.3 for Mac
  • Firefox 3.5.3 for Mac
  • Chromium 4.0.223.3 (29380) for Mac
  • Internet Explorer 8
  • Firefox 3.0.1 for Windows (oops. Should have upgraded first. Remind me to update numbers on Friday)
  • Safari 4.0.3 for Windows
  • Chrome 3.0.195.27 for Windows

Here is the data:

Data collected during testing of the different browsers

Data collected during testing of the different browsers

That’s boring. Where are the pictures?

All Browsers

All Browsers

Even here, you can tell that Chrome and Chromium are the best performers for small numbers of views. However, for larger numbers of views, Safari on Mac was a very clear winner, running at 12 frames per second for 2000 LabelViews..

Predictably, Internet Explorer was slowest. I didn’t bother to run all the tests for it.

Windows Browsers

Windows Browsers

This chart shows only the Windows browsers. Again, you can tell IE is very slow. Chrome is very very fast. Safari is pretty good. My out-of-date Firefox is not always that much faster than IE; it will be interesting to see how Firefox 3.5 fares.

Notice the dip in performance for Safari at around 300? It briefly does worse than Firefox. It quickly levels off, though, and is second only to Chrome.

Mac Browsers

Mac Browsers

And, of course, the best for last. Note how we see the same dip in performance for Safari—though it does not dip below Firefox; it would have dipped below Chromium, were it not already below it. Again, though, it leveled out faster than Chromium.

I always wanted to do a performance chart, but now that I have… it’s a lot of work (about 57 or so data points there… each measured separately).

Question Is the difference between Safari and Chromium completely caused by Google’s V8 JavaScript engine, or are there a few other differences?

Sprouting—Automated Spriting for SproutCore

Saturday, October 17th, 2009

Well. Spriting. Do you know what it is? While I’ve included a very brief summary, you may want to just skip that part if you already know about it, or find a better description of the technique. Also, while this article is specifically aimed at SproutCore, the concepts (and the script download) can easily be applied elsewhere.

Well, here are your options:

  1. Read the whole article. Could be amusing, if I’m having a bad writing day.
  2. Skip to the download and “how to use.” No, I’m not going to explain the code. Well, not here, at any rate. I’ll explain it in the code itself. Yes, of course there are comments.

What is Spriting?

Example Sprited Images

Example Sprited Images

Spriting is a technique which combines multiple small images into one large image. This can be very beneficial, because it means that, instead of downloading, say, 100 small images for all the commonly used icons in your web application, the web browser downloads one bigger image (or, perhaps, two or three, but you get the picture).

The goal of spriting is to reduce the effect of latency on your web app’s performance.

To your left is an example set of sprited images.

Using a Script

You may thing that combining several images into one larger image might be a bit time-consuming and, overall, a tad challenging, especially if you are often updating the individual images.

You are not alone. I feel the same way.

However, I do know a little about writing scripts—even if I’d like to know a lot more; I’m still only learning Python. So, there is a simple answer:

Write a darn script!

The Product

If you just want the script and how to use it, you’re in luck. Because there are, in fact, some comments in the script, I’ll leave the explanation of how the code works for there.

You can download the code from GitHub.

The script is written in Python. It requires: Either: Python 2.6+ or Python 2.5 with simplejson installed PIL (Python Imaging Library)

Very briefly, here is what it does:

  • Takes a “sets” folder, which should have sub-folder sets of icons to be sprited.
  • Takes an output folder, under which it will create new set folders containing CSS and image files.
  • Combines images under a maximum size (128×128 by default—see Configuration) into a sprites.png file in the output set folder.
  • Creates CSS referencing these images using a URL template (SproutCore oriented at first—see URL)

Sets

You often might have more than one set of icons. For instance, you could have a main set, and then an alternate set that you only want to load on demand. You still want that additional set to be sprited.

Or, perhaps, you may have images meant for repeating backgrounds, but that you still want to sprite.

To facilitate this, the spriting script takes, as its first argument, the location to a sets folder. You put your sets as subfolders into this folder. For instance, this could be your folder layout:

my-sets
	common
		delete-32.png
		delete-64.png
		refresh-32.png
		refresh-64.png
		refresh-512.png
	repeat-x
		config.js       — see Configuration
		toolbar.png
		footer.png
		header.png
	odd-feature
		some-icon.png
		other-icon.png

URLs

The CSS has to reference the images. Only problem: it doesn’t know where those images are.

Usually, you’d just be able to use paths relative to the StyleSheet. However, if you are using SproutCore, this won’t work because it moves around all the CSS and JavaScript.

With SproutCore, you need something more like:

static_url('images/set/sprites.png')

This is what the script does by default. Just like above. It uses a URL template of

static_url('images/{set}/{image}')

It is a string which will be passed through the Python format function, with set and image as arguments.

Configuration

There are a few things that are configurable. Configuration is done per-set.

Configuration files are JSON files, and are very simple. They are optional, and take at most four parameters:

  • max-size: Default: 128.
    The maximum size for sprited images. Images above this size will be put as separate images. Useful if you have some really high-res icons you don’t want to sprite, but want to keep with the set.

  • repeat: Default: “none”; can also be “x” or “y”.
    Determines the repeat mode. If repeat is “x,” the sprites will be laid out in rows; if “y,” the sprites will be laid out in columns. The generated CSS will include repeat-x or repeat-y, respectively.

Note that all images in a repeat-x set must be the same width, and all images in a repeat-y set must be the same height. The width or height of these images should be set using repeat-width and repeat height, which are discussed below.

  • repeat-width: Default: 32.
    If repeat=“x,” the width of the repeat images. If your repetition does not require a pattern, you could set this to 1.

  • repeat-height: See that lovely summary of repeat-width above? Well, this is the same, but for y/height.

The CSS

As you may know, SproutCore automatically includes any CSS files. So, since this generates CSS files (and, if you provide the right argument, puts them directly into a SproutCore-watched folder), the CSS is automatically added. So, how do you use it?

Very simply. The script generates CSS rules in this format:

.set-name .icon-name.icon, .set-name .icon-name.icon { /* CSS */ }

For example, to show “refresh-64″ icon in set “common”, you’d do something like this:

ImageView.design({
  layout: { left: 100, top: 100, width: 64, height: 64 },
  value: "common refresh-64 icon" // using SproutCore's built-in className support for spriting
}

Or, as you may have noticed from the rule above, you can accomplish some basic theming very easily by treating set names as themes:

View.design({
  layout: {left: 100, top:100, width:256, height: 256},
  classNames: ["common"], // the theme
  childViews: ["styledView"],
  styledView: ImageView.design({
    layout: { left: 100, top: 100, width: 64, height: 64 },
    value: "refresh-64 icon" // using SproutCore's built-in className support for spriting
  })
})

Nice and simple, eh?