I think this is all very interesting. We have still a part of what we could make with Flex uncovered. I talk about "drawing things" that was something more related to the Flash API. There's some efforts like spriteflexjs, but I think the problem with that project is that is "isolated" and seems difficult to use as a piece of the global puzzle. Don't know too much about openfl, and seems that some great things are happening integrating with apache royale compiler. But I'd really want to know more about all of this since there's almost no information and in order to imagine what we could do with all of this, we should have some kind of articles, post or whatever that could let us know about what things we can do, technologies implied, actual integrations, how to build those libraries, some example out there of royale and openfl using at the same time?
If we had some of the proposed information we could help on that just my 2 :) Thanks! Carlos 2018-05-18 2:56 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > Hi Greg, > > I think I understand your point. I want to point out, though, that the > current plan for the emulation set is to make Basic beads the fundamental > workhorse of this emulation set. What we are doing is taking, say, the > beads used in Basic ImageButton and re-using those beads with no or little > modification in Spark ImageButton. So that means to me that if there is an > API parameter of flash.display.BitmapData, that we are going to first > choose to rename it to something like royale.display.BitmapData and have it > subclass the class that is used to represent bitmap data in Basic. I'm not > sure how OpenFL implements flash.display.BitmapData, but it may or may not > be compatible with Basic because Basic is going to shove the data into an > IMG tag and it appears that to do that the data would be base64 encoded and > look like: > > "data:image/png;base64, > iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP > C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA > AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J > REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq > ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 > vr4MkhoXe0rZigAAAABJRU5ErkJggg==" > > Similarly, I think some Basic beads use BinaryData so our ByteArray might > get renamed to royale.utils.ByteArray and subclass our BinaryData so it can > be passed into the Basic beads. But we will keep your suggestion in mind. > Thanks for bringing it up, > -Alex > > On 5/17/18, 5:19 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > 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 > > > > > > > > > > > > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
