[whatwg] Canvas-related feedback

[Rik Cabanier]

<snip>

On Thu, 20 Sep 2012, Dirk Schulze wrote:
> > On Sep 21, 2012, at 3:12 AM, Ian Hickson <ian at 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?
It is still confusing. for instance, reading the current spec, transforms
happen before stroking in addPathByStrokingPath, but after stroking in
addPathByStrokingText. Why is that?

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

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


>
>
> > Second, the solution that you mention requires a copy operation. A lot
> > of libraries would create a new path, add the other path and apply the
> > transform afterwards. Seems unnecessary for me.
>
> I don't really follow. Can you elaborate?
>
>
> On Fri, 21 Sep 2012, Rik Cabanier wrote:
> > On Fri, Sep 21, 2012 at 2:12 AM, Ian Hickson <ian at 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.
This might not always be the case. For instance in a game, you might want
to know what region of the character you hit.


>
> > 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.


> > Most of the time you don't want to know if a point falls in the current
> > path in the canvas. You want to know after you finish drawing and the
> > user clicks on the canvas if he hit a region. By then the path in the
> > canvas is long gone (unless you want to go through the trouble of
> > redrawing everything).
>
> Sure, and for that we have the hit region API.
>

Yes, that is true.


>
>
> > 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.


> Why would you transform a path
> without immediately using it somewhere?
>

I don't understand. Can you rephrase?


>
>
> On Sat, 22 Sep 2012, Dirk Schulze wrote:
> >
> > Would it be possible to extend CanvasRenderingContext2D with the
> functions:
> >
> > void addPath(Path path); - which adds a Path object to the current path
> on Canvas?
> > attribute Path currentPath; - that returns a copy of the current path,
> or let you replace the current path with another Path object (not live)?
>
> It is definitely possible, but before we add anything, we must know what
> the use cases are so that we can evaluate if this is the best solution.
>
>
> On Fri, 28 Sep 2012, Dirk Schulze wrote:
> >
> > currentPath would not be live, no. But if you really want op(Path), then
> > it raises the question why we have path arithmetic in
> > CanvasRenderingContext2D at all. Then it should be completely separated
> > (which is not the case). What would be the sense for op(Path), if you
> > have currentPath attribute?
>
> CanvasRenderingContext2D has a path-related API because that's what has
> shipped and we can't break back compat.
>
>
> On Sat, 29 Sep 2012, Rik Cabanier wrote:
>
> > Currentpath could still be handy if you want to copy a path from one
> > canvas to another, or if you have existing code that you are migrating.
> > For instance, if you're going to use hit regions, it would be handy to
> > have.
>
> Why not just draw the path to a Path?
>
> I'd rather not add API surface just for transitory needs.
>

It's not that big of a deal.
In postscript, 'currentPath' was very handy and used quite a bit.

<snip>


>
>
> On Tue, 25 Sep 2012, Rik Cabanier wrote:
> > > >
> > > > I'm working on a spec to add blending and compositing through simple
> > > > CSS keywords. It is trying to define a generic model that is not
> > > > specific to Canvas, HTML or SVG and then lists how the model could
> > > > be implemented. We've gotten some comments that this feature would
> > > > be useful in Canvas as well so I was wondering if it made sense to
> > > > add it to the canvas API.
> > >
> > > Is there any chance of adding filters to this also?
> >
> > CSS Filters are already defined here:
> > https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html. The spec
> > refer to each other for some concepts but are pretty separate.
> > (Filtering generally just works on 1 image while blending and
> > compositing describes how 2 images are combined)
> >
> > One possibility would be to add a globalFilterOperation property that
> > takes the arguments of the 'filter' property [1]
>
> I haven't added this yet, but if this is something that UAs want to
> implement, I'm happy to do so.


>
> > > 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
Let me know what you think.

<snip>


> 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.


> On Mon, 10 Dec 2012, Rik Cabanier wrote:
> > On Mon, Dec 10, 2012 at 8:45 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Mon, 10 Dec 2012, Rik Cabanier wrote:
> > > >
> > > > yes, however it will be slower since the pattern has to be rendered
> > > > two or four times. If you can reflect in x and y, you can calculate
> > > > the pattern cell once and then have your hardware do the tiling.
> > >
> > > If it's something that happens a lot, then certainly it makes sense to
> > > add it. But I've heard very few requests for this.
> >
> > yeah, we (= Adobe) never implemented it natively in our graphics
> > libraries but other frameworks (such as xps from Microsoft) did.
>
> It's more a matter of who wants to use it than who implemented it, but
> thanks, that's useful information also.
>

yes, that's what I was trying to say.