Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Harbs]

PathBuilder was designed to be drawing agnostic and the Graphics package is 
mostly interfaces. Theoretically, anything in Graphics should be usable with 
both SVG and Canvas implementations.

The org.apache.royale.svg classes are SVG implementations and can be used 
within any Royale components.

I wanted to do a canvas implementation as well, but it’s something I never got 
to. AFAIK, the only Canvas implementation in Royale is the CreateJS package.

For code with PathBuilder in use, take a look at the following TLF classes:
TextFlowLine
AdonrmentUtils
BackgroundManager

FYI, there is also logic for Transforms which work in conjunction with the 
Graphics classes.

HTH,
Harbs

> On May 18, 2018, at 3:01 PM, Carlos Rovira  wrote:
> 
> Thanks Harbs,
> 
> to understand better about the code you said, this is done creating a
> Canvas where the drawing is done? If so what is the canvas component in
> Royale?
> I'll want to try that, if there's some example code in same place, please
> let me know.
> thanks!
> 
> 2018-05-18 13:19 GMT+02:00 Harbs :
> 
>> Take a look at the Graphics package.
>> 
>> Specifically, PathBuilder lets you use commands very similar to Flash
>> drawing commands.
>> 
>> Also, CompoundGraphic in Basic offers a number of drawing commands.
>> 
>> org.apache.royale.svg (in Basic) has many basic shape types which simplify
>> drawing of those.
>> 
>> I’ve used these classes extensively, and they work very well.
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 18, 2018, at 2:09 PM, Carlos Rovira 
>> wrote:
>>> 
>>> I talk about "drawing things" that was something
>>> more related to the Flash API.
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

Thanks Harbs,

to understand better about the code you said, this is done creating a
Canvas where the drawing is done? If so what is the canvas component in
Royale?
I'll want to try that, if there's some example code in same place, please
let me know.
thanks!

2018-05-18 13:19 GMT+02:00 Harbs :

> Take a look at the Graphics package.
>
> Specifically, PathBuilder lets you use commands very similar to Flash
> drawing commands.
>
> Also, CompoundGraphic in Basic offers a number of drawing commands.
>
> org.apache.royale.svg (in Basic) has many basic shape types which simplify
> drawing of those.
>
> I’ve used these classes extensively, and they work very well.
>
> Thanks,
> Harbs
>
> > On May 18, 2018, at 2:09 PM, Carlos Rovira 
> wrote:
> >
> > I talk about "drawing things" that was something
> > more related to the Flash API.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Harbs]

Take a look at the Graphics package.

Specifically, PathBuilder lets you use commands very similar to Flash drawing 
commands.

Also, CompoundGraphic in Basic offers a number of drawing commands.

org.apache.royale.svg (in Basic) has many basic shape types which simplify 
drawing of those.

I’ve used these classes extensively, and they work very well.

Thanks,
Harbs

> On May 18, 2018, at 2:09 PM, Carlos Rovira  wrote:
> 
> I talk about "drawing things" that was something
> more related to the Flash API.

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

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 :

> 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,
> iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP
> C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA
> AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
> REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
> ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
> vr4MkhoXe0rZigBJRU5ErkJggg=="
>
> 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"  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  >
> 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 

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Alex Harui]

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,
iVBORw0KGgoNSUhEUgoKCAYAAACNMs+9BGdBTUEAALGP
C/xhBQlwSFlzAAALEwAACxMBAJqcGAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigBJRU5ErkJggg=="

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"  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 
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"  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 
> wrote:
>
> > IMO, because of PAYG, BinaryData should not have 

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Greg Dove]

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 
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"  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 
> 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"  carlosrov...@apache.org>
> > wrote:
> >
> > So great! I'll be trying it :-)
> >
> > 2018-05-17 15:41 GMT+02:00 Harbs :
> >
> > > 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=02%7C01%7Caharui%4
> 

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Alex Harui]

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"  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 
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" 
> wrote:
>
> So great! I'll be trying it :-)
>
> 2018-05-17 15:41 GMT+02:00 Harbs :
>
> > 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  >:
> > >
> > >> 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=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
>
>
>

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Greg Dove]

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 
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" 
> wrote:
>
> So great! I'll be trying it :-)
>
> 2018-05-17 15:41 GMT+02:00 Harbs :
>
> > 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  >:
> > >
> > >> 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=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%
> 2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
>
>
>

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Alex Harui]

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" 
 wrote:

So great! I'll be trying it :-)

2018-05-17 15:41 GMT+02:00 Harbs :

> 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 
> wrote:
> >
> > I see we already has Compressionutils that uses pako, this uses zlib?
> >
> > thanks
> >
> > 2018-05-17 15:17 GMT+02:00 Carlos Rovira :
> >
> >> 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=02%7C01%7Caharui%40adobe.com%7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%2FMbYScSZlwI6ToUq%2BulNTETs%3D=0
>
>


-- 
Carlos Rovira

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C1ede1860539442c514e608d5bc00ce9d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636621634047568412=pNJ8qCDh%2B1XbcHqqD3u%2FMbYScSZlwI6ToUq%2BulNTETs%3D=0

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

So great! I'll be trying it :-)

2018-05-17 15:41 GMT+02:00 Harbs :

> 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 
> wrote:
> >
> > I see we already has Compressionutils that uses pako, this uses zlib?
> >
> > thanks
> >
> > 2018-05-17 15:17 GMT+02:00 Carlos Rovira :
> >
> >> 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
> >> http://about.me/carlosrovira
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Harbs]

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  wrote:
> 
> I see we already has Compressionutils that uses pako, this uses zlib?
> 
> thanks
> 
> 2018-05-17 15:17 GMT+02:00 Carlos Rovira :
> 
>> 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
>> http://about.me/carlosrovira
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Piotr Zarzycki]

I'm sorry Carlos! Serkan is working on something else!

2018-05-17 15:24 GMT+02:00 Carlos Rovira :

> Ok right, for me is ok to use that class and inflate/deflate methods,
> do you know if that methods use the zlib algorithm? if use that we are
> done, since is the same algorithm used in ByteArray
>
> 2018-05-17 15:22 GMT+02:00 Harbs :
>
> > Yes. The big issue with compression is that it adds a lot of code.
> >
> > The most commonly used JS library for compression is pako.[1] I’m using
> > that personally.
> >
> > We don’t want to include something like this in BinaryData because it
> adds
> > a lot of bulk.
> >
> > HTH,
> > Harbs
> >
> > [1]http://nodeca.github.io/pako/ 
> >
> > > On May 17, 2018, at 4:17 PM, Carlos Rovira 
> > wrote:
> > >
> > > 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
> > > http://about.me/carlosrovira
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

Ok right, for me is ok to use that class and inflate/deflate methods,
do you know if that methods use the zlib algorithm? if use that we are
done, since is the same algorithm used in ByteArray

2018-05-17 15:22 GMT+02:00 Harbs :

> Yes. The big issue with compression is that it adds a lot of code.
>
> The most commonly used JS library for compression is pako.[1] I’m using
> that personally.
>
> We don’t want to include something like this in BinaryData because it adds
> a lot of bulk.
>
> HTH,
> Harbs
>
> [1]http://nodeca.github.io/pako/ 
>
> > On May 17, 2018, at 4:17 PM, Carlos Rovira 
> wrote:
> >
> > 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
> > http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Carlos Rovira]

I see we already has Compressionutils that uses pako, this uses zlib?

thanks

2018-05-17 15:17 GMT+02:00 Carlos Rovira :

> 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
> http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Harbs]

Yes. The big issue with compression is that it adds a lot of code.

The most commonly used JS library for compression is pako.[1] I’m using that 
personally.

We don’t want to include something like this in BinaryData because it adds a 
lot of bulk.

HTH,
Harbs

[1]http://nodeca.github.io/pako/ 

> On May 17, 2018, at 4:17 PM, Carlos Rovira  wrote:
> 
> 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
> http://about.me/carlosrovira

Re: BinaryData compress/uncompress methods (like ByteArray) missing

[Piotr Zarzycki]

Hi Carlos,

Yes and it is in progress. Serkan is working on that [1]. I made several
comments and waiting for his update.

[1] https://github.com/apache/royale-asjs/pull/227

Thanks,
Piotr

2018-05-17 15:17 GMT+02:00 Carlos Rovira :

> 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
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*