This is how I see it in ActionScript. FlexJS Charts has ChartDataGroup which I have as a GraphicsContainer to provide the foundation <svg>. ItemRenderers get created and are added via chartDataGroup.addElement(itemRenderer). Each itemRenderer instance creates the graphics it needs and adds that via addElement() as well. I was also working on a version where the itemRenderer didn't use addElement for the shape but used the GraphicsContainer draw functions for better speed and to reduce the number of objects.
If we keep with addElement, then an itemRenderer being added as an element to a ChartDataGroup needs to translate to a <g> being added to a <svg>. The itemRenderer would create a core.graphics.Rect and addElement(rect) which would add a <rect> to the <g>. Peter Ent Adobe Systems On 9/24/14 3:29 PM, "Peter Ent" <[email protected]> wrote: >OK, I'll cook something up. > >--peter > >On 9/24/14 3:17 PM, "OmPrakash Muppirala" <[email protected]> wrote: > >>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 >>> >> >>> >>> >
