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. On Jul 21, 2016, at 9:54 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 7/21/16, 11:38 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> The standard in SVG is declarative. The standard in Canvas is functional >> (very similar to the Flash APIs). Here’s a good write-up comparing Flash >> to Canvas.[1] > > Thanks for the link. > > IMO, at the lowest level, I would pretty much implement the Canvas API > as-is, so Canvas users have almost zero overhead. Then emulate the Canvas > API in SVG and SWF. Again, that way, people have a better chance of using > snippets like the ones in the link instead of, for example, having to > learn about a DropShadowFilter class and a filter property. > > The MX/Spark work, however, will need to emulate more of > flash.display.graphics APIs and eventually support more of the flash APIs. > You might find it worth it to build out a separate SWC that implements > the flash.display.Graphics portion of the MX/Spark work in order to get > what you want. > > Transforms may be yet another SWC. In theory, you should be able to draw > stuff without bringing in code to rotate it. > > Again, just my 2 cents, > -Alex >
