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
[EMAIL PROTECTED]