[webkit-dev] Canvas color CSS parsing performance
oliver at apple.com
Sun Jan 4 20:53:46 PST 2009
#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.
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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev