Sorry, I am jumping into this slightly old thread. Just catching up with
all the emails :-)
A bit of a background to the Graphics package in FlexJS: The goal was to
make it possible to write MXMLG/FXG syntax in FlexJS and have it compiled
to SVG for the HTML/JS implementation. It was not originally intended to
be swappable with Canvas drawing API.
The biggest reason for this is that SVG is retain mode whereas Canvas is
paint and forget mode. Which means that after drawing on the screen, it is
possible to target the individual drawing elements and manipulate them.
With MXML this is easily possible to do this:
<Rect id="myRect" x="0" y="0" width="100" height="100">
<fill>
<SolidColorFill id="myColorFill" color="FF0000" />
</fill>
</Rect>
Elsewhere, in code, you could do things like:
myRect.height = 500;
myColorFill.color = #00FF00;
The way the current graphics package in FlexJS is implemented, this code
will work fine in transpiled SVG/JS as well.
I don't think that this will be easily doable with a Canvas drawing API.
The entire canvas is one DOM element. Anything drawn inside Canvas cannot
be (easily) accessible. Unless you want to setup everything and draw it
again.
Even then, you wont be able to target individual elements with mouse
events. Applications like Charts, for example have the need to be
interactive. You want to be able to enlarge a circle when you mouseover,
etc. With a Canvas implementation these kind of things are not possible.
As you mentioned in another email, Canvas has a lot of similarities to
Flash's drawing API, but the FlexJS graphics package is an abstraction of
the Flash drawing api which provides a set of SVG like drawing elements.
Thanks,
Om
On Thu, Jul 21, 2016 at 11:59 AM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 7/21/16, 11:56 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
> >I’m with you.
> >
> >If the transform stuff has too much overhead, I’d do it as a Bead. We’ll
> >see how it goes…
> >
> >Let’s discuss this some more once we’ve done some of this implementation
> >so there’s something concrete to discuss.
>
> Sounds good. IIRC, some of the current design was motivated by some
> FXG/SVG handling, so keep that in mind as well. I don't have any set
> opinions on how things end up as long as there is bias towards low
> overhead in the JS implementations and it is pay-as-you-go.
>
> Thanks,
> -Alex
>
>
