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 >>
