W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Canvas Shadows - Unnecessary Barrier to Entry

From: Philip Taylor <excors+whatwg@gmail.com>
Date: Sat, 28 Mar 2009 13:29:32 +0000
Message-ID: <ea09c0d10903280629y5433a954i81cff2064c3f779f@mail.gmail.com>
On Fri, Mar 27, 2009 at 11:22 PM, Charles Pritchard <chuck at jumis.com> wrote:
> [...]
> We've been working on Javascript / Canvas projects for two years now.
>
> We're in the process of releasing full implementations targeting the Common
> Runtime Language,
> Java AWT, ActionScript and DCOM.
>
> I'm sure you can all recognize, that these components have their own vector
> APIs,
> and that we're only sending requests through as a proxy.
>
> While we can implement everything, even the non-zero winding rule,
> there one part of the specification that's absolutely rotten. And that's the
> #shadows section.
>
> I love a shadow, I love a good looking UI, but most of these APIs do not
> have shadow
> support for shapes.

Do the APIs not provide enough features so you can implement shadows
yourself? e.g. Firefox uses Cairo which doesn't have any native
support for shadows; but it can draw shapes onto an alpha-only
surface, manually blur the pixels (if you can implement getImageData
then I assume you must already have access to the raw pixels and can
do the blurring efficiently), then draw the shape again, and composite
everything appropriately, which results in a correct shadow
implementation. I don't see what makes this fundamentally harder than
implementing all the other required canvas features.

> [...]

-- 
Philip Taylor
excors at gmail.com
Received on Saturday, 28 March 2009 06:29:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT