royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: BinaryData compress/uncompress methods (like ByteArray) missing
Date Fri, 18 May 2018 00:56:05 GMT
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.dove@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 <aharui@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.dove@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 <aharui@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.rovira@gmail.com on behalf of Carlos
    >     > Rovira" <carlos.rovira@gmail.com on behalf of
    > carlosrovira@apache.org>
    >     > wrote:
    >     >
    >     >     So great! I'll be trying it :-)
    >     >
    >     >     2018-05-17 15:41 GMT+02:00 Harbs <harbs.lists@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 <
    >     > carlosrovira@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 <
    > carlosrovira@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
    >     >
    >     >
    >     >
    >
    >
    >
    

Mime
View raw message