API Review RT:17407 Canvas Node

[Vasiliy Baranov]

On 19.04.2012 13:23, Jim Graham wrote:
> First, while the API gives heavy nods to the overall feel of the HTML5
> Canvas graphics API, this is not meant to be a duplicate of that API.
> Instead we want to provide an API that serves the needs of any of:
>
> - HTML5 Canvas programs and their developers
> - AWT Canvas programs and their developers
> - SVG programs and developers
> - any number of similar immediate mode APIs that we've seen over the years
>
> But, we wanted it to be an API that fit well with existing FX paradigms.
> This is the FX version of immediate mode graphics, but with a strong nod
> to familiarity of those other APIs. It is most like the HTML5 APIs
> because that was at the top of our priority list, but it isn't an HTML5
> clone, just like it is fairly far from being an AWT/Java2D clone.
>
> To that end, we have a number of places where we are "just like HTML5,
> but with an FX parameter or object".
>
> - fill and stroke paints are FX Paint objects: Color, LinearGradient,
> RadialGradient
> (when we provide a public ImagePattern paint object, that will work too)
> - rendering png/jpeg/etc images uses the FX Image object, not an HTML
> entity
> - angles are in degrees like FX objects, not radians like HTML5
>
> Some areas where we broke from FX, but are still contemplating if that
> was the right move:
>
> - a separate composite mode which largely duplicates the Blend modes
> used on Nodes, but is its own enum
> (basically HTML5 provided some blend modes which we weren't happy
> providing in our scene graph, so I punted for the short term, but we may
> switch back to the FX Blend.Mode values before we finalize - pros? cons?
> opinions?)
> - we provided some prototype ImageData facilities to test usefulness of
> manipulatable image buffers, but we eventually want to replace those
> with whatever we do for the FX scene graph ImageOps API so we deprecated
> these but left them in for playing around with until we finish that task.
> - we are waiting on getImageData which provides read-back support until
> we finalize official support for "Node to image" and then will provide
> something similar there. We didn't even provide a prototype for playing
> in this case.
>
> Some HTML5 oddities that I borrowed, but don't necessarily like:
>
> - current path is not part of save/restore states per HTML5 spec, but
> I'm not sure why they do it that way
> - stateful path construction where every element can be in a different
> coordinate system as opposed to providing a separate path object that is
> evaluated in its entirety in the current coordinate system at the time
> it is rendered
>
> Some things we added from 2D and SVG:
>
> - fill/draw/oval/poly*/roundrect/arc
> - appendSVGPath
>
> Some things we added from other legacy immediate mode APIs:
>
> - nothing that I remember - any suggestions? (Only minor additions can
> be considered for this release due to time constraints, but discussions
> leading to Jira entries are always good.)
>
> Does that help answer your questions?

Absolutely.

Thank you,
-- Vasiliy