I'm attaching a standalone, reduced version of http://www.peacekeeper.therichins.net/test12.html I get 18-19 fps on OS X. With Chrome 31 it's 30-31 fps. On the JS side, we seem to spend a lot of time in js_math_round; we should find out why we're not inlining that. However, JS seems to be faster than Chrome already (see also bug 606648). It looks like we need to make this faster: this.ctx.fillStyle = "rgb("+rValue+", "+gValue+", "+bValue+")"; this.ctx.fillRect(this.xPosition + x * this.pixelWidth, this.yPosition + y * this.pixelHeight, this.pixelWidth, this.pixelHeight); We seem to spend a lot of time under fillRect and parsing "rgb(..)". Filing this bug in the CSS component but maybe Canvas/Graphics is a better choice; feel free to move it.

Bug 920046 will make the Math.round call a good bit faster. With that most of the JS time will be in JIT code and math_round_impl/floor and we are a lot faster than V8. If we can be as fast as Chrome on the canvas stuff we will do really well on this test.

For fillRect, see bug 601176. I could have sworn we had existing bugs about color parsing.... I'll see what's going on there.

So for what it's worth, I just tried this on Mac. The testcase is about 20fps for me, with Chrome at 30fps. If I comment out the fillRect call, we're at 85-90 fps, while Chrome is at 65-70. So the non-fillrect bits of this take at most 12ms for us (of which a profile says about half is color parsing), while fillRect takes about 40ms. For Chrome, the non-fillRect bits take about 14ms, and the fillRect takes about 20ms. So this is really fillRect-bound. I'll see what I can do about shaving time off color parsing but even if that gets down to 0 we'll end up at 22fps.

Profile shows nothing really obvious for color parsing other than "it's complicated". Which it is. :(

Yeah, the place to look is to figure out the fillRect cost. Color parsing sucks, I've long advocated that we should accept arrays to fillColor/strokeColor too (e.g. canvas.fillColor = [1.0, 0.0, 0.0, 1.0]; for rgba) to entirely skip the parsing.

One day we might want a supermagical WebIDL extension such as [StringSetter(fillStyleRGB, "rgb(", unsigned long r, ",", unsigned long g, ",", unsigned long b, ")"), StringSetter(fillStyleRGBA, "rgba(", unsigned long r, ",", unsigned long g, ",", unsigned long b, ",", float a, ")")] attribute (DOMString or CanvasGradient or CanvasPattern) fillStyle; which could pattern-match JS expressions in the JIT and call through to special stubs, avoiding building the string and parsing it :-). Would also be useful for "element.style.top = y + 'px';" and stuff like that --- very common.

I just tested this one, and Nightly is faster than Chrome 33 (18 vs 16fps) on the testcase attached and on the original peacekeeper test.

On 64 bit Linux Nightly ~33fps vs Chromium ~21fps