[whatwg] Canvas performance issue: setting colors

[Oliver Hunt]

I did some basic testing, and it looks like a significant amount of  
the difference is due to this (based on the frame rate that ToT webkit  
could kick out, the timeout difference corresponds to around a 30% on  
its own).  However it's difficult to be entirely sure as VMWare (from  
memory) throttles WM_PAINT messages, there's an awful lot of variance  
in the frame rate and my testing was very ad hoc so should be taken  
with a grain of salt :D

However the topic of setting canvas fillStyle, strokeStyle etc is an  
interesting one.  Currently setting a computed colour is a fairly icky  
process -- you have to do something akin to:

   context.fillStyle/Stroke = "rgb("+r+","+g+","+b+")"; // or  
rgba(...) where appropriate

Ignoring performance, that code is ugly all on its own, and when you  
add to that the fact that most computed colours result in double  
values (0..1) then it actually becomes something akin to

   context.fillStyle/Stroke = "rgb("+Math.round(255*r) 
+","+Math.round(255*g)+","+Math.round(255*b)+")";

Or whatever -- even uglier.

So I believe for these scenarios we need a better mechanism for  
changing the stroke and fill style on the canvas, the trouble is that  
i'm not sure what.  I'm really not convinced that creating a special  
CanvasColor type would be a win because that would (at best) reduce  
the above to something akin to

  context.fillStyle/Stroke = new CanvasColor(r,g,b,a);

or worse:

context.fillStyle = context.createColor(r,g,b,a);

But otoh, maybe if we had a generic Color object that could be used in  
other places (like css) maybe it could be a win, especially if a Color  
could be a solid color, pattern, gradient, etc -- I know there are  
some places where people like behaviour like that.  OTOH, it's  
difficult to see how that could be backwards compatible in a  
reasonable way -- so maybe something similar to WebKit's setFillColor  
would be best.

Just a final note, I am of the opinion that while canvas.fillStyle is  
not a stunningly fast API i am of the opinion that the real problem  
with the fillStyle API is the verbosity of setting an arbitrary  
computed color more than anything else.

<thinking out loud>
Just had a thought (no idea how original) -- how about if fillStyle  
were able to accept a 3 or 4 number array? eg. fillStyle = [0, 0.3,  
0.6, 1.0] ?

That might work well if people are using arrays as vectors/colours
</thinking out loud>

--Oliver

On Oct 3, 2008, at 4:11 PM, Robert Sayre wrote:

> On Mon, Sep 29, 2008 at 6:24 PM, Sjoerd Visscher  
> <sjoerd at w3future.com> wrote:
>>
>> A large percentage of the time goes into building color strings for  
>> setting
>> the strokeStyle, which the browser then has to take apart again.  
>> This is a
>> very unnecessary performance hit. (Btw, on my Mac this runs faster  
>> under
>> Google Chrome in VMware than natively in the latest Webkit nightly.)
>
> I see that your test case include setTimeout(doIteration, 0);
>
> Are you sure this doesn't boil down to the difference between Chrome
> and WebKit's setTimeout minimum delay?
>
> -- 
>
> Robert Sayre
>
> "I would have written a shorter letter, but I did not have the time."