royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <>
Subject Re: SVG for Flash (was Re: How to get assets (svg, png,...) inside *-js.swc and *-swf.swc libraries)
Date Tue, 27 Feb 2018 06:19:23 GMT
I think supporting SVG natively is the best option going foward.

It should be possible to utilize something like AS3SVGRenderer to support
SVG rendering in Royale.  [1]




On Mon, Feb 26, 2018 at 10:10 PM, Alex Harui <>

> IMO, this deserves its own thread.
> I think there are several choices. I've not ever really analyzed and
> compared SVG to SWF, but one possibility is to write an SVG Interpreter in
> ActionScript that translates SVG into flash.display.Graphic calls.  Of
> course, that sounds like a really big project, which it probably is, but
> with PAYG and DAYG (do as you go) it seems like it might be the true final
> answer because then ActionScript that you write to manipulate the SVG at
> runtime can work.  More on this later.
> I think the only choice that currently works is to embed the SVG in a SWF
> with the Flex compiler.  I don't see support for SVG transcoding in the
> Royale compiler, but I could have missed it.
> Another option is to try to transform SVG back to FXG.  I think Om wrote a
> transform from FXG to SVG.
> Then there are options that transform SVG to PNG or other non-vector image
> formats.
> It would be easier on the runtime to have the compiler do the
> transformation, but I'm tempted to have the ActionScript code do it
> because then the asset that is deployed and loaded is the same SVG.  You
> don't have to copy an SVG file for JS and an FXG or SWF or some other file
> for Flash.
> I mentioned in another thread that for SWF, we first want to get the
> bounding boxes right, then worry about the pixels.  That's because, until
> customers really demand it, it may not matter how good the SWF output is
> as long as it can be used to test your business logic.  You may never
> deploy the SWF version, but it should save you time in catching errors in
> your code but I know I would want the UI to layout close enough to the JS
> version that I don't have to go and tweak a lot of the UI after I'm done
> testing on Flash/AIR.
> So, with PAYG/DAYG, the initial implementation of an SVG interpreter would
> just draw a filled rectangle of the size specified in the SVG.  Then over
> time as needed we would add beads for each SVG tag.
> Anyway, those are my thoughts on it.  Definitely want to hear from Om and
> anyone else who has spent more time around this topic.
> HTH,
> -Alex
> On 2/26/18, 1:45 PM, " on behalf of Carlos Rovira"
> < on behalf of> wrote:
> >Hi Alex,
> >
> >many thanks, just test and this is working fine! :)
> >
> >One more thing to think about now that we get to this point. In order for
> >SWF and JS versions to share the same assets...should we move swf to the
> >same folder than "assets"?...or maybe put assets (and maybe CSS) directly
> >on "target" folder? So any output could grab a the same assets folder (or
> >in other words, to avoid copying 2, 3 or more versions of the same files)
> >
> >I'm thinking in make JS and SWF version and try to match both, but for
> >this
> >I need to know how I can load the SVG from Flash. Right now is referenced
> >in CSS, but don't know if SWF version can handle as well SVGs in CSS. If
> >is
> >possible that would be great since will make the creation of themes more
> >easy
> >
> >Thanks
> >
> >Ca
> >
> >
> >
> >
> >2018-02-26 19:36 GMT+01:00 Alex Harui <>:
> >
> >> OK, I just pushed a change for this in vivid-ui-set branch.  It seemed
> >>to
> >> work for me.
> >>
> >> HTH,
> >> -Alex
> >>
> >> --
> >> Carlos Rovira
> >>
> >>
> >>2Fcarlosrovira&
> 7C74ac42b84dbb4bcd7b8508
> >>d57d624f87%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63655278355713391
> >>7&sdata=FNLpJCEUmENigzmOpOexcH446lX%2BDhGag1%2FmrjcP3V0%3D&reserved=0
> >>
> >>
> >>

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