Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: unknown (athena.apache.org: error in processing during lookup of
 aharui@adobe.com)
From: Alex Harui <aharui@adobe.com>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Subject: Re: [FlexJS] Building SVG skins from existing Spark component skins
Thread-Topic: [FlexJS] Building SVG skins from existing Spark component skins
Thread-Index: 
 AQHPM5kwndqAadnhzEaJCRo0ObeT6JrI1CaA///9wYCAALIoAP//mGiAgACVroD//+rNAA==
Date: Fri, 28 Feb 2014 05:22:52 +0000
Message-ID: <CF35558B.1A3D1%aharui@adobe.com>
References: 
 <CACK5iZcqSPZ78WGFDFV2uTpw+xUukS=MJAi+9mQ66gax1SsHRQ@mail.gmail.com>
 <CAMFKFRien_3gLnROoH23aVHGPjrS4tjZ5_DfztknEhfPw2Wgfw@mail.gmail.com>
 <CF34B185.1A2FF%aharui@adobe.com>
 <CACK5iZdzqyv65HeMk9G9iZjUPjx0TBnzvbU9zQ-1cB_HrXi5gw@mail.gmail.com>
 <CF34D903.1A338%aharui@adobe.com>
 <CACK5iZd5RSgFBNY9MFP5h=QJPY6iOhFOAgHjDzi8AawP8aS1yQ@mail.gmail.com>
In-Reply-To: 
 <CACK5iZd5RSgFBNY9MFP5h=QJPY6iOhFOAgHjDzi8AawP8aS1yQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.9.131030
received-spf: None (: adobe.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FA2C255DDF9E2840AE1A33317BE1D898@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 2/27/14 2:38 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com> wrote:

>On Thu, Feb 27, 2014 at 1:43 PM, Alex Harui <aharui@adobe.com> wrote:
>
>>
>>
>> On 2/27/14 11:53 AM, "OmPrakash Muppirala" <bigosmallm@gmail.com> wrote:
>>
>> >
>> >Lets do it!  Where do we start?  I want to start building some JS side
>>SVG
>> >drawing APIs that I want to use with our Charts.  The BarChart on the
>>JS
>> >side uses CSS to draw, which will become limited very soon.  Having a
>> >robust JS based SVG drawing API will definitely help us in the long
>>run.
>> >Do you mind starting with an SVG parser in Falcon?  We could just do
>>with
>> >the primitives for now:  BitmapImage, Ellipse, Line, Path and Rect.
>>Then
>> >we can do the fills, strokes, gradients, etc.  No need to deal with the
>> >whole SVG spec.
>>
>> An SVG Parser or emitter (output to SVG from the tree)?  I'll try to
>>find
>> the relevant code this evening.
>>
>> I'm not sure what you mean by a drawing library.  What pops into my mind
>> is a component called Graphics that creates a DOM element and draws
>>Flash
>> in AS and SVG in JS.  You shouldn't need any compiler changes for that.
>>
>>
>The Graphics component is what I had in my mind.  I thought you had
>mentioned some compiler changes in your last email.  If that is not
>required, ignore what I said.
>
>If I understand the flow correctly, we will have an AS skin class that
>references an SVG document.  The compiler parses the SVG document (like it
>does with FXG today) and will generate AS code that uses the Graphics
>component to draw stuff in Flash.
>
>On the JS side, we will have a similar Graphics component with same
>drawing
>API, except that the code draws SVG onto the HTML DOM.
>
>I believe you will figure out the SVG parser part.  I can take care of
>creating the Graphics component on AS and JS versions.
>
>Am I on the right track?
Well, can we start with FXG first?  Then I don't have to worry about how
to handle SVG on the AS side.  IMO, the output doesn't have to be the same
for AS and JS.  On the AS side the compiler already converts FXG to a
Sprite and Shapes and TextField.  IMO, that is the most efficient
representation of FXG in terms of performance.  Someday, I would have the
compiler convert SVG to Sprite and Shapes and TextField.  I believe the
mapping isn't clean for all of SVG, but could be for many graphic
primitives.

The question is: what is the most efficient representation of FXG/SVG on
the JS side?  Should it be SVG markup, or data structures that you can use
to call the createElementNS/setAttributes in a loop?  Or just linear JS
code making those calls?  We stopped using linear AS code for MXML codegen
because it is faster/smaller to generate a data structure and run a loop
where the JIT-compilation is re-used.

So, if it were up to me, we'd start with a test case where an MXML or AS
skin points to an fxg file for each state.  The Falcon compiler should
already generate the right thing for the AS side.  Then, we have to apply
a similar hook to the FXG compiler that we did to get JS output for
FalconJX and start coding up however we want the JS/SVG output to look
like.  It could call this Graphics component, but may not need to, it may
just generate SVG or JS calls.  But for sure, you're welcome to write the
Graphics class for both AS and JS and teach BarChart to use it.  We'll
need that no matter what.

Anyway, if this plan is acceptable to you, what I'd prefer to do is this:
I would apply the hooks to the FXG compiler and get it to output
"something".  I'd point you to the change list so you can see what files
need to be modified.  Then you can try your hand at modifying those Java
source files to get whatever output you want.  You really don't have to
know much about compilation, you are basically taking a tree structure and
converting it to some textual representation.  Then we don't have to do as
much coordination between the two of us.

I'm working on getting mustella to run with FlexJS right now (and fixing
installer issues) but I'll stop to try to apply those hooks if you are
game.

-Alex