Re: [whatwg] Canvas-related feedback

On Thu, 20 Dec 2012, Rik Cabanier wrote:
> On Thu, 20 Sep 2012, Dirk Schulze wrote:
> > > On Sep 21, 2012, at 3:12 AM, Ian Hickson <ian@hixie.ch> wrote:
> > > >>
> > > >> The only situation that might be reasonable would be a transform 
> > > >> on the Canvas that an author want to cover in the Path. But for 
> > > >> the rare case where this matters, you can create a new Path 
> > > >> object, add your path with the transform and call isPointInPath.
> > > >
> > > > Yeah, you could do that too.
> > > >
> > > >> Furthermore, a transform() function that applies to a Path object 
> > > >> seems to be useable as well.
> > > >
> > > > You can create a new Path, then add another Path to it while 
> > > > applying a transform, using the addPath() method.
> > >
> > > Yes, it is possible. But there are two reasons why I think that it 
> > > still makes sense to use a transform function. First it seems 
> > > natural to have a transform on Path object, like the 
> > > CanvasRenderingContext2D already has. Both share a lot of functions, 
> > > why disallow it for transforms?
> >
> > The main reason I didn't add it to Path is because it led to a bit of 
> > confusion in terms of what the transform applied to. Does it apply 
> > when you add points _to_ the path? Does it apply when you draw the 
> > path on another path or the canvas? Also, one of the more confusing 
> > aspects of the canvas API is that you can change the coordinate space 
> > while adding lines to the path, and we had a whole era wherein 
> > implemenations and the spec were confused as to what exactly happened 
> > when (did the points get transformed? Did the transform apply only 
> > when you stroke? etc).
> >
> > So in the new API I side-stepped the whole problem.
> 
> I don't understand. How did you sidestep the problem?

By not having a transform on Path.


> It is still confusing. for instance, reading the current spec, 
> transforms happen before stroking in addPathByStrokingPath, but after 
> stroking in addPathByStrokingText. Why is that?

That was just an oversight. Fixed. Thanks.


> Wouldn't it be easier to have API's that
> - create a path with svg path data
> - create a path with text (and a style)
> - stroke a path with a style
> - add a path with a optional transform

How does this differ from what we have? Do you just mean move the 
Text-based methods from being add*() methods to being Path constructors? I 
guess we could do that, I don't really see a compelling argument one way 
or the other. The current model is to use add*() for as much as possible; 
the only non-trivial constructors we have are a copy constructor, for 
convenience, and the SVG-based constructor, which is not an add*() method 
because I didn't want to try to explain how SVG path processing interacted 
with existing subpaths.


> We also should discuss what 'adding' a path means. Currently, the shapes 
> are simply aggregated which will only work for simple cases.

Proposals welcome. :-)


> > On Fri, 21 Sep 2012, Rik Cabanier wrote:
> > > On Fri, Sep 21, 2012 at 2:12 AM, Ian Hickson <ian@hixie.ch> wrote:
> > > > On Thu, 20 Sep 2012, Dirk Schulze wrote:
> > > > >
> > > > > The interface of CanvasRenderingContext2D currently has a 
> > > > > function called isPointInPath() with a Path object as input [1]. 
> > > > > I wonder why this needs to be on the context interface. Wouldn't 
> > > > > it make more sense on the interface of Path object itself? If an 
> > > > > implementation really needs a context to get a point on a path 
> > > > > it, it can create it on it's own.
> > > >
> > > > I don't think it would make _more_ sense, but I agree that it 
> > > > would make equal amounts of sense.
> > > >
> > > > In practice you're pretty much always going to have a context 
> > > > around when you want to check this, because the reason you'd use 
> > > > it is to see where I mouse click landed on a canvas. And you're 
> > > > going to want the Path object transformed as per the transform on 
> > > > the canvas, generally speaking.
> > >
> > > Not necessarily. The path object makes sense outside of canvas as 
> > > well. You don't need a context to create it so we are thinking of 
> > > integrating it with SVG. It would increase interop and simplfy the 
> > > API's if you could ask SVG elements for their path, or create them 
> > > with one.
> >
> > Sure, but with SVG you don't need to know if a point is in a path, 
> > because the events get dispatched to the right path by the UA.
> 
> That assumes that you always have an event handler attached to the path.

No, not at all. Even if the event handler is a global listener, it still 
gets the target information in the event object.


> This might not always be the case. For instance in a game, you might 
> want to know what region of the character you hit.

I don't see how having a "isPointInPath" method on a Path object would 
help with that. You'd still need to have the path transformed; if this was 
canvas, you'd want to check each of the actual paths against the actual 
canvas (or more likely, use a hit region), if it was SVG, you'd check what 
the target of the event was.


> > > Maybe if there was a 'currentpath' property on the 2d context, you 
> > > can move 'isPointInPath' to the path object. This would let you get 
> > > rid of the extra 'isPointInPath' that takes a path too.
> > >
> > > so:
> > >   myContext.currentpath.isPointInPath(...)
> >
> > I don't really see what problem this solves.
> 
> It simplifies the API and gives you access to the current path.

I don't see how this is simpler. It's exactly as complex, as far as I can 
tell. I don't understand what being able to access the current path gives 
you. Not being able to access it doesn't seem, a priori, to be a problem.


> > > I agree with Ian that there shouldn't be a method that changes the 
> > > current points in a path. However, if there was a 'transform' 
> > > function that took a matrix and returned a transformed path, it 
> > > would do what Dirk wants. In addition, the path API's could be 
> > > simplified since you can take out all the 'transform' arguments.
> >
> > Can you elaborate on the use case for this?
> 
> Simplify the API's so they're easier to understand and implement.

I don't see how it simplifies the API for authors.

Could you elaborate on why it's simpler for implementors?


> > > > https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
> > > >
> > > > Would it make sense to have the canvas section defer to this spec 
> > > > for all blending, filtering, and compositing?
> > >
> > > I think it does since then everyting will be in 1 location. I would 
> > > need to update the blending spec for canvas because it behaves 
> > > differently than HTML and SVG.
> >
> > Ok, let me know when I should do this.
> 
> There's a first draft posted here: 
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending 

Ok, I've deferred to that. Implementors, if you don't want to implement 
this, please let me know. Rik, if the integration is not correct, let mek 
know.


> > On Sun, 16 Dec 2012, Rik Cabanier wrote:
> > >
> > > It seems a bit too expensive to add a variable to the graphics 
> > > context that is checked for just this call.
> >
> > Why would it be expensive?
> 
> A UA would have to initialize and store the value in each drawing state. 
> Maybe not super expensive, but if we keep adding things to the state, it 
> will eventually make a difference.

This is one bit. I don't think it'll break the bank. It's cheaper than 
adding a new blend type.


On Wed, 9 Jan 2013, Dirk Schulze wrote:

> 
> After all the discussions about winding rules and the new introduced 
> enumeration for "nonzero" and "even odd", I wonder if the the 
> compositing and blending modes should be two enumerations as well.
> 
> enum CanvasCompositingMode {
>  "source-over",
>  "source-in",
>  …
> }
> 
> and
> 
> enum CanvasBlendingMode {
>  "normal",
>  "multiply",
>  ...
> }
> 
> This wouldn't actually change the behavior or definition a lot, but 
> might help to cleanup a bit. I am happy about other names if they are 
> not good enough.

I'm fine with doing this; since right now the spec just defers to Rik's 
spec, it'd be up to Rik to define the enum for me to hook into.


On Wed, 9 Jan 2013, Rik Cabanier wrote:
> 
> the 'globalCompositeOperation' property takes the same syntax as the css 
> 'mix' so I don't think an enum will work.

As specced today, it takes a single keyword, so an enum would work. To 
move it beyond that, we'd need to make sure we had implementor buy-in, and 
then we'd have to update the composition and HTML specs.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'