Thursday, September 4, 2008

Interesting observations about WebKit/Chrome and Chronoscope Benchmark

Playing around with the benchmark some more, I noticed some strange things. The more I clicked the "Bench" button, the faster Chrome got. After about 4 runs of the benchmark, it increased as much as 2x in performance. Is Chrome using HotSpot-like techniques to count method invocations for inlining?

Secondly, the animation on WebKit/Chrome gets choppy. This isn't because the Javascript isn't drawing the frames. The benchmark draws 100 frames, each in a setTimeout call to avoid slow script warnings. Browsers appear to defer reflecting any mutations to the UI until the Javascript thread yields the CPU back. That is, you don't see the results of a canvas fill() or stroke() until the CPU is yielded. (Opera seems to work differently, but offers a GameCanvas which lets you lock/unlock progressive updates)

Now, I would normally expect that the draw results would be copied/blitted/reflected into the Browser's document as soon as the Javascript thread yields. But what if the update is scheduled in the same timer/event queue as other pending setTimeout calls? And what if the next frame's scheduled timeout is before the native canvas update?

Then what would happen is that the Javascript code would get the CPU again, erase the canvas, and draw the next frame. This would account for the choppiness and disappearance of intermediate frames.

But it could also count for the performance differential between TraceMonkey/FF3.1 and WebKit/Chrome, in the sense that TraceMonkey might "pay the cost" of reflecting every frame into the browser's window which gets counted by my timing code, whereas WebKit/Chrome might get a free ride by skipping the update and somehow avoid the cost by deferring it.

I'm not sure, and it would be interesting if people who are familiar with the internals of Gecko and WebKit could comment on how canvas updates are handled.

In the meantime, I'll look at ways of ensuring that every frame is drawn, perhaps by increasing the intra-frame timeout interval.

4 comments:

ahhughes said...

Sure, chrome would like to be 'super browser' #1.... but the fact is that IE has majority share for no other reason than its the default install and that won't change. Unless chrome is sooooo frikken good the world can't ignore it, then it's a minority that deserves little attention. But I hope it knock's IE off.

Bill Mill said...

I don't see a reference anywhere to Opera's "gamecanvas". Could you point me to what you're talking about?

Ray Cromwell said...

@bill,
Try the following: http://my.opera.com/WebApplications/blog/show.dml/200788

Andrés Testi said...

Ray, I've found that Chrome flushes the canvas updates when processing is finished. You can test this raytracer with Opera and Chrome: http://labs.flog.co.nz/raytracer/