#rgb and #rrggbb are both now using a more optimised path, but webkit
also provides the non-standard setFillColor(r,g,b,a) and
setStrokeColor(r,g,b,a) functions, and there's the ImageData APIs.
Of course you're welcome to contribute patches to improve performance,
but in general DOM additions should go through WhatWG first.
--Oliver
On Jan 4, 2009, at 2:52 PM, Dean McNamee wrote:
I've been working on some canvas code that is an animation doing many
fills of different colors. I've spent some time profiling my code,
and the majority of time (over 8%) spent in WebKit is in the CSS
parser. The current canvas spec only allows you to set colors as a
string that goes through the CSS parser "rgb(1, 2, 3)", etc, or as a
gradient. The gradient color points are also CSS color strings, so
creating gradients also requires going through the parser.
Does anyone have thoughts on allowing fillStyle / strokeStyle (and
probably the gradient color points also) to take an array of RGB /
RGBA? This would allow for much more efficient color setup, and would
be a very trivial change to the current DOM binding code. I can
submit a bug and patch to make the sfx / v8 DOM binding changes, but
since it's something standardsy, I wanted to make sure to put it out
there and solicit opinions.
I think it's a pretty big weakness now that the only way you can set
colors has to go through such a heavy parsing path.
Thanks
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
