- From: Oliver Hunt <oliver@apple.com>
- Date: Tue, 30 Sep 2008 01:21:26 -0700
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 > > >
Received on Tuesday, 30 September 2008 01:21:26 UTC