W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

Re: [whatwg] [canvas] inner shadows

From: Rik Cabanier <cabanier@gmail.com>
Date: Sat, 24 Nov 2012 08:28:08 -0800
Message-ID: <CAGN7qDAJzdE1F8Jkvi3+XXtwYWOokRd04sqE3gE+wZhPTSssgA@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg@whatwg.org
On Fri, Nov 23, 2012 at 10:30 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Fri, 23 Nov 2012, Rik Cabanier wrote:
> > On Fri, Nov 23, 2012 at 8:58 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > On Fri, 23 Nov 2012, Rik Cabanier wrote:
> > > > >
> > > > > Turns out it's relatively easy to do today in canvas; after you've
> > > > > drawn your shape and filled it, just add the following code:
> > > > >
> > > > >   c.save();
> > > > >   c.clip();
> > > > >   c.moveTo(0,0);
> > > > >   c.lineTo(0,height);
> > > > >   c.lineTo(width,height);
> > > > >   c.lineTo(width,0);
> > > > >   c.closePath();
> > > > >   c.shadowColor = 'black';
> > > > >   c.shadowBlur = 30;
> > > > >   c.fill();
> > > > >   c.restore();
> > > >
> > > > I don't think that will work. Shadows are calculated before clipping
> so
> > > > they don't follow the clipping path.
> > >
> > > What matters is how they're painted, and that does follow the clipping
> > > path, as far as I can tell (step 4 of the drawing model).
> >
> > What matters is the shape that is used to calculate the blur (step 1) In
> > your example, that shape is a rectangle--
>
> No, no, the rectangle is just added to the existing path. The code snippet
> above comes _after_ you've drawn the shape.
>

True. I forgot that the clip doesn't do a newpath. Sorry about that!


>
>
> > > > Even if it was right, it would only apply to shapes and only if
> > > > those shapes didn't have strokes and were completely opaque.
> > >
> > > That's easy enough, though, you only need to make a shape that is what
> > > you want the inner shadow to go over, and then set the fill to black
> > > (or anything completely opaque).
> >
> > How about the strokes?
>
> The example in the OP didn't have them, but you'd have to include them in
> the fill area. With the new Path objects, you'd just use
> addPathByStrokingPath(), which would be relatively simple.
>

Unfortunately the winding rules will mess up your shape. (non-zero winding)

Take for instance a stroked circle.
The stroke which is added with addPathByStrokingPath will always create a
hole so you end up with a donut instead of just a slightly larger circle.


>
>
> > > It's even easier with the new Path primitives since you can construct
> > > a combined path by stroking them all into one.
> >
> > Unfortunately, the current path logic does not support unions. It just
> > does path accumulation which will not give you the desired result.
>
> So long as they don't overlap, that's not generally a problem. But sure,
> for some complex shapes you'd need some new feature or other, whether it's
> in shadows or path construction or elsewhere.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Saturday, 24 November 2012 18:13:06 GMT

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