[Public WebGL] WebKit 20-50% slower than Chrome/Minefield using large Float32Array Arrays

Stephen Bannasch [email protected]
Thu Feb 17 16:16:00 PST 2011

At 11:23 AM +0100 2/17/11, Thatcher Ulrich wrote:
>Cool demo.
>One thing you should try, without even going to WebGL, is filling the
>canvas using context.putImageData() instead of lots of fillRect calls.
> Perhaps also best to render into a 100x100 canvas, and have the
>browser scale it onto the correct size on the page, instead of doing
>that in your paint routine. 


Thanks for the suggestion, it works much better. I implemented it and the canvas renderings is about 50% faster.


>The other thing you should definitely do is make a color table instead
>of making and parsing "hsl(...)" strings for every pixel.

The div-stuffing method is now slower than the canvas rendering but it wasn't that slow.

The div-stuffing method pre-generates 256 css rules, inserts them into the stylesheet and 256 div strings and puts these into an array.  Later when generating the string to insert with innerHTML I build it out of the pre-computed array of div strings that reference each of the 256 styles.

But ... there's a new mystery! A colleague asked how much slower it would be if I didn't use typed arrays ... so now there are two alternate implementations that link to each other:


On my Chrome version 9 using regular arrays and rendering runs about 7.1 fps while using typed arrays is slower at only 5.4fps.

On plain old Safari v5 I'm getting 3.6 fps.

Without rendering Chrome 9 runs about 41 fps using regular arrays and only about 31 fps with the Typed Arrays. Minefield isreversed running about 41 fps using Typed and 28 fps using regular arrays.

Regular Safari runs about 21 fps without rendering.


I have made a few other changes in the model but none that I thought would slow doiwn typed-arrays.

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list