Great! It would be helpful for me to see an example of usage in ActionScript as well as MXML, so I can build the APIs accordingly.
Thanks, Om On Wed, Sep 24, 2014 at 12:14 PM, Peter Ent <[email protected]> wrote: > I think using <g> is the way to go. Probably need a GraphicsGroup element > or something like that. > > --peter > > On 9/24/14 1:42 PM, "OmPrakash Muppirala" <[email protected]> wrote: > > >I was thinking about more as well. I agree that for the use cases you > >mention with regards to charts, the <g> element would be ideal: > > > >https://developer.mozilla.org/en-US/docs/Web/SVG/Element/g > > > >It is the recommended way to contain a group of objects. One advantage > ><g> > >over a nested <svg> is that you can apply transforms to <g> which applies > >to all child elements, whereas you cannot do that with a (nested) <svg> > >Also, fills and strokes applied to the <g> element will get inherited by > >the contained child shapes. > > > >Obviously, the style properties cascade, so you can override individual > >shapes' styles as needed. > > > >As I am typing it, I realize that this is somewhat similar to the <Group> > >element in FXG. We should be easily able to extend this concept in > >FlexJS. > > > > > >Thanks, > >Om > > > >On Wed, Sep 24, 2014 at 10:24 AM, Peter Ent <[email protected]> wrote: > > > >> Hi, > >> > >> I had a discussion with Alex about the FlexJS chart package and how it > >> makes use of SVG. For a quick background, the FlexJS chart package makes > >> use of the core.graphics package created by Om which makes FlexJS charts > >> much more easily cross-compiled from ActionScript to JavaScript. > >> > >> At the moment, the chart package creates a complex display list > >>structure > >> where each value to be plotted is a FlexJS component/element. In > >> JavaScript, this comes down to a <div> with an <svg> (+ graphic, e.g., > >> rectangle) for each item to be rendered to display the chart. Imagine > >>you > >> are plotting a lot of points (say 500). That would lead to 500 divs and > >> more svgs. While feasible, it takes time to render and bloats the DOM. > >> > >> Om added some efficiencies by creating a GraphicsContainer (and single > >> <svg>) and you can draw directly into it (have <rect>, <path>, etc.). I > >> modified the FlexJS chart package to take advantage of this so that each > >> item to be rendered makes use of the shared GraphicsContainer as its > >> background and adds the necessary <rect>, <path> or whatever to draw the > >> chart. Much more efficient. > >> > >> Since then, I've been looking deeper into SVG and discovered some > >>things I > >> didn't know it was capable of (although I'm not sure how compatible they > >> are with IE). For example, you can nest <svg> elements and even group > >>them. > >> This enables relative placement of the items. For example, right now to > >> draw anything, all of the coordinates are based on the (0,0) of the > >>shared > >> GraphicsContainer. Meaning, each bar of a bar chart is placed relative > >>to > >> the underlying chart base (<svg>). That might sound OK, which it did to > >>me, > >> but after chatting with Alex, I can see that having more relative > >> coordinates would allow for future things such as animations. > >> > >> Consider a bar chart with two series. Right now, all of the bars are > >>drawn > >> relative to the <svg>. What if each series were its own <svg>, enabling > >> each bar to be relative to its series origin? This would allow each > >>series > >> to be manipulated independently. Further, an SVG group could be used for > >> all of the bars in the chart, giving them shared characteristics (color) > >> and that could be changed all at once by changing the group color. > >> > >> Basically, using containers within SVG will make manipulating the charts > >> easier in the future and there are several ways to do. I am looking for > >>any > >> suggestions or thoughts folks might have who are more familiar with SVG > >> than I am. > >> > >> Regards, > >> Peter Ent > >> Adobe Systems > >> > >
