flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: FXG 2.0 donation progress concerns and Adobe design tool support
Date Thu, 14 Mar 2013 22:14:59 GMT
On Thu, Mar 14, 2013 at 1:24 PM, Alex Harui <aharui@adobe.com> wrote:

> On 3/14/13 1:02 PM, "Om" <bigosmallm@gmail.com> wrote:
> >> Don't PhotoShop and Illustrator output SVG as well?  What is it about
> >> that is a must-have especially if you are targeting HTML and not Flash?
> >
> >
> > This implies that I need to decide on the target (HTML vs. Flash) before
> I
> > even start designing the skin for the app.  Is that what you expect
> > developers to do with FlexJS?
> Nope, I think they should just choose SVG, and FlexJS and its compiler
> should try to convert it into Flash assets when running on Flash.

Right, except that when the user chooses the SVG route, that eliminates
support for older browsers.

> Frankly,
> I'm not sure if it has to do a great job in terms of fidelity or
> performance.  For most folks, the end goal is to get a great HTML/JS app.
> The SWF version is so you can develop and test as much as possible before
> cross-compiling.
If I may suggest an alternative approach, I would use the SWF version to
support older browsers.  Remember, Flash Player for Desktop is still very

For the newer browsers that support do support inline SVG, we can convert
FXG to SVG and we have a viable non-swf alternative.  This is a more
future-safe approach, IMHO.

> > My point is that we have tools that create FXG, we have AS code that can
> > work with FXG.  I believe it is a more efficient approach run with FXG
> and
> > make it work with HTML/JS.  The end result would make the SDK users that
> > much happier.
> The AS code that works with FXG probably uses a lot of Flash APIs, so it
> can't be cross-compiled efficiently to JS.  If you can write an efficient
> FXG renderer on the JS side, please do so.

No, thats not what I meant.  I said "AS code can work *with *FXG".  This
can be translated to JS code working with SVG.  AS to JS translation is
what you guys are working on.  FXG to SVG XMSLT transformation is
(hopefully) the only missing link.

> >
> > On the flip side, you have not convinced me that we should drop FXG.
> I am not trying to convince you to drop FXG, I am just saying that I would
> rather write code to support SVG instead and may do so after I get bitmap
> skinning working.  IMO, every year, fewer and fewer new releases of tools
> will output FXG unless we can show the world a reason it is better than
> SVG.
> But again, you or anyone is welcome to write the FXG support, and I will
> welcome it.

I will hopefully get to work on it sooner than later.  I want to put this
idea out and let you guys kick the tires to see if I am missing something


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message