Falcon is made up of sub-compilers. There is one for FXG. Just because it
spits out AS of a certain format right now doesn't the JS output will be a
straight up translation of it. I can be anything.
I think Om and I are waiting to see if the HTML5 button with skinning really
does have rendering differences between browsers.
In my view of FlexJS there will be multiple buttons to choose from. If you
want to code up one that isn't accessible but uses Canvas, feel free. I'm
coding up buttons that leverage DOM widgets because it is small and fast so
I can get something out there for folks to try.
On 3/17/13 2:26 PM, "jude" <flexcapaci...@gmail.com> wrote:
> Om,
>
> There's FXG and SVG but there's also HTML5 canvas element.
>
> You probably already know this but FXG is made up of graphic primitives
> such as Rect, Path, Ellipse, Stroke, Fill and BitmapFill and so on. We also
> know that MXML / XML gets converted into ActionScript. In the case of FXG
> it gets converted into graphics commands.
>
> So this FXG:
>
> <s:Group>
> <s:Path data="Q 75 75 50 0" width="132" height="150" />
> </s:Group>
> gets converted into something like this the MXMLC compiler:
>
> var sprite:Sprite = new Sprite();
> sprite.width = 132;
> sprite.height = 150;
> sprite.graphics.drawPath(75,75,50,0);
> stage.addChild(sprite);
>
> And that gets converted into something lower level later on. What I was
> mentioning to Alex about is that when we go through the AS to JS
> translation we could translate graphics calls like above to the canvas
> element below:
>
> // Create canvas element
> canvas = document.createElement('canvas');
> canvas.setAttribute('width',132);
> canvas.setAttribute('height',150);
>
> var graphics = canvas.getContext('2d');
> graphics.beginPath();
> graphics.arc(75,75,50,0,Math.PI*2,true); // Outer circle
> document.addElement(canvas);
>
>
> It's not a 1 to 1 conversion but it's pretty close. Whoever spec'd out the
> canvas element took some notes from the Flash API or took some notes from
> whoever Flash took some notes from. I think we could get a much better
> representation with it than going the current way which is to use the stock
> browser and OS browser component set.
>
> The Flex button component is drawn using graphic primitives. We know that's
> always going to look the same because we control what's drawn and where. If
> we just create wrappers around the HTML controls we don't know what we will
> get and we're going to inherit all of HTML's problems. If we draw to the
> canvas what you draw is what you get.
>
> To make this work we'd have to create our own graphics api class in JS that
> was included. It could be really basic and allow use to use Flex skins,
> graphics calls and skins. The downside might be it sacrifices
> accessibility. But if it were up to me and that was the only reason why we
> hesitate to use it I'd say let's output an accessible version at the same
> time. We can do that now. We didn't have that option before. Then screen
> readers will be satisfied and we can avoid a whole mess of problems.
>
> It was brought up before but if we could choose the abstract out the
> renderer we could probably we might be able to solve a few more problems.
> When I saw Starling running the first time it was like seeing the iPhone
> retina display the first time. It's night and day. Maybe we can have a
> flash display list renderer (current), Starling 2d display list renderer,
> canvas display list renderer, webgl render or some raster bitmap display
> list renderer. These would just translate the original drawing api to the
> target api. Ok I know that's a lot of work and I'm rambling : P
>
>
> On Thu, Mar 14, 2013 at 5:14 PM, Om <bigosma...@gmail.com> wrote:
>
>> On Thu, Mar 14, 2013 at 1:24 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>>>
>>>
>>>
>>> On 3/14/13 1:02 PM, "Om" <bigosma...@gmail.com> wrote:
>>>
>>>>> Don't PhotoShop and Illustrator output SVG as well? What is it about
>>> FXG
>>>>> 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
>> prevalent.
>>
>> 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
>> obvious.
>>
>> Thanks,
>> Om
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
