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
> >
> >
> >
>
>
>
