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" <[email protected]> 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 <[email protected]> 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, "[email protected] on behalf of Carlos > Rovira" <[email protected] on behalf of [email protected]> > wrote: > > So great! I'll be trying it :-) > > 2018-05-17 15:41 GMT+02:00 Harbs <[email protected]>: > > > 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 < > [email protected]> > > wrote: > > > > > > I see we already has Compressionutils that uses pako, this uses > zlib? > > > > > > thanks > > > > > > 2018-05-17 15:17 GMT+02:00 Carlos Rovira <[email protected] > >: > > > > > >> 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%40adobe.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%40adobe.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%40adobe.com% > 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636621634047568412&sdata=pNJ8qCDh%2B1XbcHqqD3u% > 2FMbYScSZlwI6ToUq%2BulNTETs%3D&reserved=0 > > >
