I did some basic testing, and it looks like a significant amount of
the difference is due to this (based on the frame rate that ToT webkit
could kick out, the timeout difference corresponds to around a 30% on
its own). However it's difficult to be entirely sure as VMWare (from
memory) throttles WM_PAINT messages, there's an awful lot of variance
in the frame rate and my testing was very ad hoc so should be taken
with a grain of salt :D
However the topic of setting canvas fillStyle, strokeStyle etc is an
interesting one. Currently setting a computed colour is a fairly icky
process -- you have to do something akin to:
context.fillStyle/Stroke = "rgb("+r+","+g+","+b+")"; // or
rgba(...) where appropriate
Ignoring performance, that code is ugly all on its own, and when you
add to that the fact that most computed colours result in double
values (0..1) then it actually becomes something akin to
context.fillStyle/Stroke = "rgb("+Math.round(255*r)
+","+Math.round(255*g)+","+Math.round(255*b)+")";
Or whatever -- even uglier.
So I believe for these scenarios we need a better mechanism for
changing the stroke and fill style on the canvas, the trouble is that
i'm not sure what. I'm really not convinced that creating a special
CanvasColor type would be a win because that would (at best) reduce
the above to something akin to
context.fillStyle/Stroke = new CanvasColor(r,g,b,a);
or worse:
context.fillStyle = context.createColor(r,g,b,a);
But otoh, maybe if we had a generic Color object that could be used in
other places (like css) maybe it could be a win, especially if a Color
could be a solid color, pattern, gradient, etc -- I know there are
some places where people like behaviour like that. OTOH, it's
difficult to see how that could be backwards compatible in a
reasonable way -- so maybe something similar to WebKit's setFillColor
would be best.
Just a final note, I am of the opinion that while canvas.fillStyle is
not a stunningly fast API i am of the opinion that the real problem
with the fillStyle API is the verbosity of setting an arbitrary
computed color more than anything else.
<thinking out loud>
Just had a thought (no idea how original) -- how about if fillStyle
were able to accept a 3 or 4 number array? eg. fillStyle = [0, 0.3,
0.6, 1.0] ?
That might work well if people are using arrays as vectors/colours
</thinking out loud>
--Oliver
On Oct 3, 2008, at 4:11 PM, Robert Sayre wrote:
On Mon, Sep 29, 2008 at 6:24 PM, Sjoerd Visscher
<[EMAIL PROTECTED]> wrote:
A large percentage of the time goes into building color strings for
setting
the strokeStyle, which the browser then has to take apart again.
This is a
very unnecessary performance hit. (Btw, on my Mac this runs faster
under
Google Chrome in VMware than natively in the latest Webkit nightly.)
I see that your test case include setTimeout(doIteration, 0);
Are you sure this doesn't boil down to the difference between Chrome
and WebKit's setTimeout minimum delay?
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
