[whatwg] Canvas performance issue: setting colors

[Oliver Hunt]

On Sep 30, 2008, at 1:09 AM, Sjoerd Visscher wrote:

> I guess this applies to the other methods and attributes of canvas  
> as well. The majority of canvas methods are constructed in a way  
> that allows an almost direct mapping to a C/C++ call. So when all  
> the canvas code is perfectly optimized, the color code will probably  
> still be the bottleneck. Unless you say that serializing floats to  
> string and concatenating them and then parsing the string again can  
> be done just as fast as creating and destructing a color object.

Sorry, i'm not sure i understand what you're saying?

The issue with your suggestion is that it would probably not save  
anything too dramatic in terms of performance -- you go from  
constructing a string which all js interpreters do optimise heavily to  
a function call + (from the PoV of the interpreter) generic object  
creation.  For what you want (which is rapidly changing computed  
colours) a set*Style(double r, double g, double b, double a)-esque  
method -- creating an object you are unlikely to be reusing is  
superfluous.

Anyhoo, the current unnecessary performance cost in the WebKit canvas  
implementation in this particular testcase is that we don't special  
case the common case (from the PoV of canvas) rgb[a](...) syntax and  
just fire up a full CSS compatible colour parser.  The reality is that  
this is only really a significant problem for pages that do "bit  
blitting" by drawing millions of 1x1px rect fills where each rect fill  
has an colour parsing step.

--Oliver

>
>
> On Sep 30, 2008, at 12:53 AM, Oliver Hunt wrote:
>
>>
>>> I think the canvas api should get 2 new methods:
>>>
>>> CanvasColor createRGBAColor(in float r, in float g, in float b, in  
>>> float a)
>>> CanvasColor createHSLAColor(in float h, in float s, in float l, in  
>>> float a)
>>>
>>
>> WebKit already has a non-standard function -- setFillColor(r, g, b,  
>> a) -- that provides a faster mechanism to set the colour, however  
>> we believe we can rather easily improve the performance of the  
>> standard fillStyle, strokeStyle properties and just have not yet  
>> gotten round to it.  Until we have improved this I would be  
>> hesitant to go around adding entirely new object types (especially  
>> canvas specific ones).
>>
>> --Oliver
>>
>
> --
> Sjoerd Visscher
> sjoerd at w3future.com
>
>
>