Alex, your comment about a full-blown emulation component set built on openfl display objects could perhaps be a different (and interesting) approach or 'parallel' option in time. But I wasn't really meaning that at this point. I wasn't thinking so much on the 'displaylist' side of things.
I was only intending to suggest that for some of the flash dependencies inside the emulation classes (e.g. use of ByteArray, for example), it might be a quick solution to use whatever emulation code openfl has for those already - even if that is only temporary or transitional. For ByteArray we do have alternate approaches as discussed, but perhaps using the openfl code could mean less initial work getting things working where-ever it is used, because there might be very little change required from the original code. Perhaps something like BitmapData might be useful from openfl, for example (I don't think we have 'emulation' for this yet, right?). If this works, it could speed things up in emulation efforts perhaps by focusing more on migrating the 'Flex' specific code and not on the lower level flash player classes that are not yet emulated but necessary for some things. As I said, I only noticed the activity for openfl, and have not investigated what Joshua is doing there, so just wanted to float the idea... which is done now, so I will leave it to others to figure out if it makes sense or not! On Fri, May 18, 2018 at 10:36 AM, Alex Harui <aha...@adobe.com.invalid> wrote: > Hi Greg, > > That's an interesting idea. My inclination is to recommend that migrators > get rid of their flash*.* dependencies for two reasons: > > 1) I think in many cases there are other JS implementations that will work > better. Having a Button be an HTMLButtonElement should be better than it > being implemented on OpenFL's Sprite. > 2) Not having code rely on flash*.* makes it easier for us to provide a > third target someday (WebAsm, Native). > > But if folks want to pursue an emulation component set that uses OpenFL > for flash*.*, it could become a viable solution. Especially for apps that > had a lot of custom graphical content. > > My 2 cents, > -Alex > > On 5/17/18, 2:33 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > Just a quick suggestion about 'emulation' options. > > I notice Joshua Granick has been active in terms of working to get the > openfl js lib to work as an extern. That does sound interesting > because I > think that gives access to the work that has already been done there in > terms of emulation of a lot of the flash.* packages. > > I only mention it because it might provide a faster route for getting > some > of the internal code inside the emulation classes that use various > native > flash utils etc work. > I have not investigated this, just thought I would mention it in case > it > was not something that had been considered - I expect Joshua could > provide > a lot more detail about this if asked. > > > > > On Fri, May 18, 2018 at 9:18 AM, Alex Harui <aha...@adobe.com.invalid> > wrote: > > > IMO, because of PAYG, BinaryData should not have compress/uncompress. > > Feel free to create a BinaryDataWithZLib or something like that. > > BinaryData has no requirement to fully replace ByteArray. The > emulation > > components will probably have a better emulation of ByteArray. > > > > My 2 cents, > > -Alex > > > > On 5/17/18, 7:16 AM, "carlos.rov...@gmail.com on behalf of Carlos > > Rovira" <carlos.rov...@gmail.com on behalf of > carlosrov...@apache.org> > > wrote: > > > > So great! I'll be trying it :-) > > > > 2018-05-17 15:41 GMT+02:00 Harbs <harbs.li...@gmail.com>: > > > > > Hah! I forgot I wrote that class… ;-) > > > > > > Yes. Pako is a zlib port. > > > > > > Thanks, > > > Harbs > > > > > > > On May 17, 2018, at 4:22 PM, Carlos Rovira < > > carlosrov...@apache.org> > > > wrote: > > > > > > > > I see we already has Compressionutils that uses pako, this > uses > > zlib? > > > > > > > > thanks > > > > > > > > 2018-05-17 15:17 GMT+02:00 Carlos Rovira < > carlosrov...@apache.org > > >: > > > > > > > >> Hi, > > > >> > > > >> BinaryData is the new ByteArray in royale right? > > > >> I was searching for compress/uncompress methods but seems we > > don't have > > > yet > > > >> > > > >> I'm missing something here? maybe the compress/uncompress > > algorithms has > > > >> some license issues and for that reason wasn't implemented? > > > >> > > > >> thanks > > > >> > > > >> > > > >> -- > > > >> Carlos Rovira > > > >> https://na01.safelinks.protection.outlook.com/?url= > > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%4 > 0adobe.com% > > 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de > > cee1%7C0%7C0%7C636621634047568412&sdata=pNJ8qCDh%2B1XbcHqqD3u% > > 2FMbYScSZlwI6ToUq%2BulNTETs%3D&reserved=0 > > > >> > > > >> > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > https://na01.safelinks.protection.outlook.com/?url= > > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%4 > 0adobe.com% > > 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de > > cee1%7C0%7C0%7C636621634047568412&sdata=pNJ8qCDh%2B1XbcHqqD3u% > > 2FMbYScSZlwI6ToUq%2BulNTETs%3D&reserved=0 > > > > > > > > > > > > -- > > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url= > > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%4 > 0adobe.com% > > 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de > > cee1%7C0%7C0%7C636621634047568412&sdata=pNJ8qCDh%2B1XbcHqqD3u% > > 2FMbYScSZlwI6ToUq%2BulNTETs%3D&reserved=0 > > > > > > > > >
