For svg and canvas, the drawing commands map pretty cleanly to their HTML counterparts, so it would be pretty clean.
In fact, this is pretty much what GraphicsContainer currently does, but I’m talking about completing the support and naming it to be more indicative of what it is. Basically, If you just need a simple SVG shape, you would use one of Circle, Rect, Path, etc. If you need nested SVG elements, you’d use the (new) GraphicsContainer. If you’d need a single SVG with complex drawing, you’d use CompoundGraphic. The only scenario that this does not cover would be nested groups within a single SVG. A reason you might want to do that would be to improve performance. I’m not sure how to structure the classes to easily enable that. On Jul 21, 2016, at 4:54 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 7/21/16, 3:00 AM, "Harbs" <ha...@printui.com> wrote: > > >> 3. I’d like an interface which mimics the Flash APIs as closely as >> possible. It might not make sense to have every element have a “graphics” >> object because it could inflate things unnecessarily, but I’m thinking >> that it might make sense to rename GraphicsContainer to CompoundGraphic >> which would have all the drawing commands as first class methods. That >> should make converting Flash objects to FlexJS objects pretty >> straight-forward myObj.graphics.drawRoundedRect() would become >> myObj.drawRoundedRect(). I’d like to keep the actual method signatures as >> similar as possible. > > Without thinking about it too much, my opinion is that the basic > components job is to thinly wrap browser behavior so the JS output is as > lightweight as possible, so I would be tempted to trade away Flash API > compatibility to another SWC (which is happening in the MX/Spark port). > > My 2 cents, > -Alex >
