flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: Wrapped flash packages and FalconJX
Date Thu, 30 Jan 2014 18:23:04 GMT
I haven't given up on my VanillaSDK idea, but as I don't even have time to
help finish FlexJS now, it'll be a while before I get to work on that again


On Thu, Jan 30, 2014 at 7:06 PM, Alex Harui <aharui@adobe.com> wrote:

> Hi Markus,
> Thanks for trying FlexJS.
> At this point in time, FlexJS isn't trying to emulate the Flash Player's
> APIs.  That could change if that's what folks really want, but IMO, it is
> better to try design a framework that will run optimally when
> cross-compiled.
> That's because I think there are some differences between the way Flash
> works and the browsers work, and we only have a small number of folks
> working on FlexJS right now so leveraging the browser's capabilities seems
> like the most efficient path and should give you the best performance in
> the end.
> Here's an example:  Let's say we did try to emulate flash.display.Sprite.
> Would we also then need to emulate the flash.events.Event.ENTER_FRAME
> event?  If so, would we then need to cache all changes to Sprite until an
> ENTER_FRAME event?  Because that's how Flash works, while modifying a DOM
> object in the browser is immediate.  If we didn't do that, code you
> currently have that expects that you can make lots of incremental changes
> to a Sprite before it gets rendered will have a very different interim
> visual result.
> There are other things like that as well.  For example, I think having a
> working accessibility API is important so if we don't use DOM objects in
> the browser we'd have to write an entire accessibility implementation.
> But if we use DOM objects in the browser, there are limitations as to what
> kind of Flash-like things are easy to draw in those DOM objects,
> especially if you want to support old browser like IE8.
> So, right now, we are suggesting that you scan your code for "import
> flash" and use the results as a way to estimate how much porting work you
> will need to do.  Then you can decide whether to build a JS emulation of
> some of that flash stuff or whether it is better to port that code to
> FlexJS APIs.  Even if we did auto-translate "import flash" to "import
> org.apache.flex.*" you'd still get a lot of compile errors because many
> APIs would be missing from the FlexJS versions.
> While you may not be able to use low-level Flash APIs in FlexJS, it was
> even a goal in the current Flex SDK to hide a lot of those Flash APIs
> anyway.  SystemManager wraps the root, for example.  With FlexJS, you have
> to work from the higher-level component APIs, many of which should look
> and feel much like Flex components.
> And, finally, all of this is just my current opinion, and I'm more than
> willing to discuss whether this is the right direction or not.
> -Alex
> On 1/30/14 3:16 AM, "Markus Gritsch" <markus_gritsch@gmx.de> wrote:
> >Hi group,
> >
> >Spending some time in converting an existing flex project to JS I have a
> >question about Class wrapping around flash packages like
> >org.apache.flex.events.Event. If my understanding is correct I have to
> >change all package declaration in my as3 code to org.apache.flex.x.x. A
> >cool think would be if the compiler could check the base class every time
> >a flash package declaration is found and replace the flash class
> >flash.events.Event with the corresponding Wrapper -
> >org.apache.flex.events.Event - at compile time - not in the code itself.
> >
> >Did I miss something?
> >
> >Thanks,
> >
> >Markus

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

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