On 1/21/13 9:02 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
>
> Quoting Alex Harui <aha...@adobe.com>:
>
>> There are probably a lot of other MXML-isms like the classfactory handling.
>> But my hope is to get rid of as many as we can. Most if not all of this
>> code gen can be handled better by code in the framework interpreting data.
>> Really, if was practical to generate code on the fly in AS,
>
> What do you mean generate code on the fly, you mean ABC bytecode
> during runtime in the player?
Yes. Technically I know it is "possible", and believe me, I have thought
about leveraging it at times.
>
> I wouldn't
>> convert MXML at all, I would just suck it in as XML and parse it at runtime.
>> It would make for much smaller SWFs and take advantage of the JIT by making
>> the parsing loop hotter. Right now, Flex MXML generates lots of run-once
>> methods.
>
>
> I'm keeping .js in mind for mxml as well so I guess this is just mute
> point right now.
I believe js performance will also benefit from re-use of code vs lots of
run-once methods.
>
>
>> I'll put together a "spec" on the wiki about the data format. You might be
>> able to guess it from the MXMLDataInterpreter class.
>>
>
>
> Yeah I noticed that class last night, it would be nice to read
> something you write though.
Okeydokey.
>
> Mike
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
