On Oct 4, 2008, at 3:19 AM, Oliver Hunt wrote:
On Oct 4, 2008, at 3:07 AM, Anne van Kesteren wrote:
On Sat, 04 Oct 2008 01:37:53 +0200, Oliver Hunt <[EMAIL PROTECTED]>
wrote:
<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>
Philip Taylor suggested that a while back:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010939.html
Ian Hickson replied only to the added value of returning an array
rather than a string:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011268.html
(Which at this point is unfortunately no longer possible I'm afraid.)
Ah, I was not meaning to in any way suggest that we change the type
of fillStyle/strokeStyle, merely to overload the assignment
behaviour to allow arrays to be used -- although i'm not sure
whether there is a clean way to represent this in the idl
definitions in the spec.
Basically i would expect
context.fillStyle = [1,1,1,0.5]
alert(context.fillStyle);
to produce an output akin to rgba(255,255,255,0.5) or some such.
The goal is simply to make a very common idiom (computed colours) be
much more concise. As I have said previously webkit also provides a
setFillColor(r,g,b,a) method which might be preferable? (the problem
with this kind of approach is that it means that there are two
distinct methods to set the active colour :-/ )
setFillColor avoid the need for allocation entirely in all cases.
We could also consider letting fillStyle take a number to be
interpreted as a 32-bit RGBA value, since modern JS engines can do
math and masking faster than string operations or array allocation.
But the broken out setFillStyle version seems like it might still be
more of a perf win in many cases.
- Maciej
