[OT] flash player 10.1 beta 3

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[OT] flash player 10.1 beta 3

Hudson Ansley
flash player 10.1 beta 3 is available:
http://labs.adobe.com/technologies/flashplayer10/

I mention this because it appears to have improved the speed of
pixelbender filters and I think memory opcodes (at least over previous
betas :), be interested to see results from some of the speed tests
that folks on this list have posted in the past.

Regards,
Hudson

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

jlm@justinfront.net
10.1 should have opto codes for multitouch is this currently in the  
haXe compiler? I am still trying to get a nexus build if any one at  
google/adobe will let me test a beta or alpha?  I have got bluetooth  
software so any emailed my way I can easily transfer via my mac, and I  
presume flash10 standard will play on it.

Cheers

;j
On 26 Feb 2010, at 17:47, Hudson Ansley wrote:

> flash player 10.1 beta 3 is available:
> http://labs.adobe.com/technologies/flashplayer10/
>
> I mention this because it appears to have improved the speed of
> pixelbender filters and I think memory opcodes (at least over previous
> betas :), be interested to see results from some of the speed tests
> that folks on this list have posted in the past.
>
> Regards,
> Hudson
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Chris Hecker

There are opcodes for multitouch?  That seems like a random thing to put
in the vm directly.

Chris


Justin Lawerance Mills wrote:

> 10.1 should have opto codes for multitouch is this currently in the haXe
> compiler? I am still trying to get a nexus build if any one at
> google/adobe will let me test a beta or alpha?  I have got bluetooth
> software so any emailed my way I can easily transfer via my mac, and I
> presume flash10 standard will play on it.
>
> Cheers
>
> ;j
> On 26 Feb 2010, at 17:47, Hudson Ansley wrote:
>
>> flash player 10.1 beta 3 is available:
>> http://labs.adobe.com/technologies/flashplayer10/
>>
>> I mention this because it appears to have improved the speed of
>> pixelbender filters and I think memory opcodes (at least over previous
>> betas :), be interested to see results from some of the speed tests
>> that folks on this list have posted in the past.
>>
>> Regards,
>> Hudson
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Lee Sylvester
Not with the shear level of multi-touch monitors and PC's coming out, it
isn't :-)  Forward thinking...

Lee



Chris Hecker wrote:

>
> There are opcodes for multitouch?  That seems like a random thing to
> put in the vm directly.
>
> Chris
>
>
> Justin Lawerance Mills wrote:
>> 10.1 should have opto codes for multitouch is this currently in the
>> haXe compiler? I am still trying to get a nexus build if any one at
>> google/adobe will let me test a beta or alpha?  I have got bluetooth
>> software so any emailed my way I can easily transfer via my mac, and
>> I presume flash10 standard will play on it.
>>
>> Cheers
>>
>> ;j
>> On 26 Feb 2010, at 17:47, Hudson Ansley wrote:
>>
>>> flash player 10.1 beta 3 is available:
>>> http://labs.adobe.com/technologies/flashplayer10/
>>>
>>> I mention this because it appears to have improved the speed of
>>> pixelbender filters and I think memory opcodes (at least over previous
>>> betas :), be interested to see results from some of the speed tests
>>> that folks on this list have posted in the past.
>>>
>>> Regards,
>>> Hudson
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Chris Hecker

I mean the "opcode" part.  Like, it's an actual opcode as opposed to a
library function?  That makes no sense.

Chris



Lee McColl Sylvester wrote:

> Not with the shear level of multi-touch monitors and PC's coming out, it
> isn't :-)  Forward thinking...
>
> Lee
>
>
>
> Chris Hecker wrote:
>>
>> There are opcodes for multitouch?  That seems like a random thing to
>> put in the vm directly.
>>
>> Chris
>>
>>
>> Justin Lawerance Mills wrote:
>>> 10.1 should have opto codes for multitouch is this currently in the
>>> haXe compiler? I am still trying to get a nexus build if any one at
>>> google/adobe will let me test a beta or alpha?  I have got bluetooth
>>> software so any emailed my way I can easily transfer via my mac, and
>>> I presume flash10 standard will play on it.
>>>
>>> Cheers
>>>
>>> ;j
>>> On 26 Feb 2010, at 17:47, Hudson Ansley wrote:
>>>
>>>> flash player 10.1 beta 3 is available:
>>>> http://labs.adobe.com/technologies/flashplayer10/
>>>>
>>>> I mention this because it appears to have improved the speed of
>>>> pixelbender filters and I think memory opcodes (at least over previous
>>>> betas :), be interested to see results from some of the speed tests
>>>> that folks on this list have posted in the past.
>>>>
>>>> Regards,
>>>> Hudson
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>
>>>
>>
>
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Yanis Benson
Since OP called it "opto codes" I think he just doesn't understand what
opcodes are. And yeah, putting opcodes for multitouch defenitely makes
no sense.

On 02/26/2010 10:34 PM, Chris Hecker wrote:
> I mean the "opcode" part.  Like, it's an actual opcode as opposed to a
> library function?  That makes no sense.
>
> Chris


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

jlm@justinfront.net
Oh lets discuss if it's multitouch, multi-touch, or multi touch?  
Rather than how and if haXe can or does support this.


On 27 Feb 2010, at 06:49, Yanis Benson wrote:

> Since OP called it "opto codes" I think he just doesn't understand  
> what opcodes are. And yeah, putting opcodes for multitouch  
> defenitely makes no sense.
>
> On 02/26/2010 10:34 PM, Chris Hecker wrote:
>> I mean the "opcode" part.  Like, it's an actual opcode as opposed  
>> to a library function?  That makes no sense.
>>
>> Chris
>
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Baluta Cristian
If it's multitouch and the iPad-iPhone will run apps made with flash cs5, makes more than perfect sense.
haXe will support it if Nicolas will implement it, what else can we discuss?


On Sun, Feb 28, 2010 at 3:07 AM, Justin Lawerance Mills <[hidden email]> wrote:
Oh lets discuss if it's multitouch, multi-touch, or multi touch?  Rather than how and if haXe can or does support this.



On 27 Feb 2010, at 06:49, Yanis Benson wrote:

Since OP called it "opto codes" I think he just doesn't understand what opcodes are. And yeah, putting opcodes for multitouch defenitely makes no sense.

On 02/26/2010 10:34 PM, Chris Hecker wrote:
I mean the "opcode" part.  Like, it's an actual opcode as opposed to a library function?  That makes no sense.

Chris


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

back2dos
Well, basically the CS5 must be having some means of converting swf into
iPhone native binaries.
They must be able to do so, otherwise they'd make usage of swc
impossible. Also, AVM bytecode is a pretty good representation of the
source ActionScript, so it's moreless interchangable.

Now the worst case scenario is, we update our external classes to
include the multi-touch API, and then we compile our code to an swf/swc
and import it into a .fla for the final translation.
But I guess this "cross-compiler" will be included in the flex SDK,
since I can't image Adobe will lock out the Flex product suite.

In any case, I see no point in including this as a backend, except the
fact that one can expect that cross-compiler to be painfully slow.

greetz
back2dos

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Lee Sylvester
That's not what adobe is doing. The compiler takes a further step to  
convert swf bytecode to iPhone ASM. Simply interpreting Flash bytecode  
would be far too slow. (I also spoke to Richard Galvan at Adobe about  
this at FotB last year)

Regards,
Lee




On 28 Feb 2010, at 19:11, Juraj Kirchheim <[hidden email]> wrote:

> Well, basically the CS5 must be having some means of converting swf  
> into iPhone native binaries.
> They must be able to do so, otherwise they'd make usage of swc  
> impossible. Also, AVM bytecode is a pretty good representation of  
> the source ActionScript, so it's moreless interchangable.
>
> Now the worst case scenario is, we update our external classes to  
> include the multi-touch API, and then we compile our code to an swf/
> swc and import it into a .fla for the final translation.
> But I guess this "cross-compiler" will be included in the flex SDK,  
> since I can't image Adobe will lock out the Flex product suite.
>
> In any case, I see no point in including this as a backend, except  
> the fact that one can expect that cross-compiler to be painfully slow.
>
> greetz
> back2dos
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Lee Sylvester
In reply to this post by back2dos
Actually, re-reading your post, you're absolutely right ;-)  I first
read it as interpreting the SWF bytecode, not "converting".  My bad!

Lee




Juraj Kirchheim wrote:

> Well, basically the CS5 must be having some means of converting swf
> into iPhone native binaries.
> They must be able to do so, otherwise they'd make usage of swc
> impossible. Also, AVM bytecode is a pretty good representation of the
> source ActionScript, so it's moreless interchangable.
>
> Now the worst case scenario is, we update our external classes to
> include the multi-touch API, and then we compile our code to an
> swf/swc and import it into a .fla for the final translation.
> But I guess this "cross-compiler" will be included in the flex SDK,
> since I can't image Adobe will lock out the Flex product suite.
>
> In any case, I see no point in including this as a backend, except the
> fact that one can expect that cross-compiler to be painfully slow.
>
> greetz
> back2dos
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

back2dos
Yeah ... no problem ... :)

However, I don't get how interpreting ABC would be far too slow. IMO,
this is just some crap claimed by Apple, to justify their policies.
The iPhone does support JavaScript. And as a matter of fact, many people
use JavaScript to create apps for the iPhone.
They now even consider using JavaScript to playback flash animation. How
sick is that?
There is no reason for an ABC-interpreter to be slower than a JavaScript
interpreter.
Au contraire, one can perform much better optimizations on ABC then on
JavaScript due to static typing and sealed objects.
The really draining performance draining part about flash player is
rendering, namely (alpha)compositing, filters and vector rasterization.
Compared to that ABC-execution is extremely cheap.
The only "applications" where ABC-speed actually matters more than
graphical performance are benchmarks :D

I am quite convinced, Apple doesn't want to have interpreters on their
device for political reasons.
One is, that that'd facilitate bypassing an important source of their
income: the app store.

greetz
back2dos

Lee McColl Sylvester wrote:

> Actually, re-reading your post, you're absolutely right ;-)  I first
> read it as interpreting the SWF bytecode, not "converting".  My bad!
>
> Lee
>
>
>
>
> Juraj Kirchheim wrote:
>> Well, basically the CS5 must be having some means of converting swf
>> into iPhone native binaries.
>> They must be able to do so, otherwise they'd make usage of swc
>> impossible. Also, AVM bytecode is a pretty good representation of the
>> source ActionScript, so it's moreless interchangable.
>>
>> Now the worst case scenario is, we update our external classes to
>> include the multi-touch API, and then we compile our code to an
>> swf/swc and import it into a .fla for the final translation.
>> But I guess this "cross-compiler" will be included in the flex SDK,
>> since I can't image Adobe will lock out the Flex product suite.
>>
>> In any case, I see no point in including this as a backend, except
>> the fact that one can expect that cross-compiler to be painfully slow.
>>
>> greetz
>> back2dos
>>
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Lee Sylvester
This is quite coincidental, but I have just finished reading two books
on iPhone development with HTML, CSS and JavaScript and converting that
data to native App Store apps using PhoneGap or QuickConnectiPhone. If
you lookup both, you'll see that you can create apps in JavaScript that
can do pretty much everything that an Obj-C app can do, including :-

embedded offline Google maps,
geolocation,
accessing the contacts functionality,
vibrating the phone,
playing system sounds,
saving data to a local SQLite database,
sending data to other iPhones,
and loads more native stuff

If you fancy reading about this, get the book "Building iPhone Apps with
HTML, CSS, and JavaScript: Making App Store Apps Without Objective-C or
Cocoa" which can be bought from :-

http://www.amazon.com/Building-iPhone-Apps-HTML-JavaScript/dp/0596805780/ref=sr_1_1?ie=UTF8&s=books&qid=1267389547&sr=8-1

It's a good read and get's the mind working. Also, some good links are:-

http://phonegap.com/
http://quickconnect.sourceforge.net/
http://jqtouch.com/

I'm currently researching this quite heavily, as it's a much shorter
journey to successful iPhone / iPod Touch / iPad apps than any other
route out there and also follows the same development methodologies that
I'm already used to.

I know this is the opposite to your argument, but wasn't sure if you
knew of these right now :-)

Best,
Lee




Juraj Kirchheim wrote:

> Yeah ... no problem ... :)
>
> However, I don't get how interpreting ABC would be far too slow. IMO,
> this is just some crap claimed by Apple, to justify their policies.
> The iPhone does support JavaScript. And as a matter of fact, many
> people use JavaScript to create apps for the iPhone.
> They now even consider using JavaScript to playback flash animation.
> How sick is that?
> There is no reason for an ABC-interpreter to be slower than a
> JavaScript interpreter.
> Au contraire, one can perform much better optimizations on ABC then on
> JavaScript due to static typing and sealed objects.
> The really draining performance draining part about flash player is
> rendering, namely (alpha)compositing, filters and vector rasterization.
> Compared to that ABC-execution is extremely cheap.
> The only "applications" where ABC-speed actually matters more than
> graphical performance are benchmarks :D
>
> I am quite convinced, Apple doesn't want to have interpreters on their
> device for political reasons.
> One is, that that'd facilitate bypassing an important source of their
> income: the app store.
>
> greetz
> back2dos
>
> Lee McColl Sylvester wrote:
>> Actually, re-reading your post, you're absolutely right ;-)  I first
>> read it as interpreting the SWF bytecode, not "converting".  My bad!
>>
>> Lee
>>
>>
>>
>>
>> Juraj Kirchheim wrote:
>>> Well, basically the CS5 must be having some means of converting swf
>>> into iPhone native binaries.
>>> They must be able to do so, otherwise they'd make usage of swc
>>> impossible. Also, AVM bytecode is a pretty good representation of
>>> the source ActionScript, so it's moreless interchangable.
>>>
>>> Now the worst case scenario is, we update our external classes to
>>> include the multi-touch API, and then we compile our code to an
>>> swf/swc and import it into a .fla for the final translation.
>>> But I guess this "cross-compiler" will be included in the flex SDK,
>>> since I can't image Adobe will lock out the Flex product suite.
>>>
>>> In any case, I see no point in including this as a backend, except
>>> the fact that one can expect that cross-compiler to be painfully slow.
>>>
>>> greetz
>>> back2dos
>>>
>>
>>
>
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

jlm@justinfront.net
Yer phoneGap is very interesting, Lee I wondered if haXe could do the  
phoneGap layer.

But on the multitouch is not really apple thing, iphones are big at  
the moment but who knows about tomorrow... my nexus had an update that  
enabled multitouch, and I rem nokia had multitouch in research way  
back so there must be quite a few flash 10.1 platforms that will have  
multitouch, at FITC, adobe had a prototype of something with a huge  
screen and no proper casing guess like a big brother clone to the ipad  
but with flash multitouch.  One company I worked with were pushing  
apple for flash support on there iphone/ipad for there online sales,  
and from what I understood they seemed to think it will definitely  
come, I suspect that adobe are holding off on releasing 10.1 player  
maybe in part down to trying to get apple on board at launch.  I think  
multitouch is going to be like the scroll wheel for mice in terms of,  
one minute no one has it, and in a year from now everyone will have it  
in some form or another, on there phone or pc, so it's fairly  
important tech as it will change flash, and html, and app interfaces.

Might be wrong... but I think multitouch is about to break out of its  
niche.


On 28 Feb 2010, at 23:04, Lee McColl Sylvester wrote:

> This is quite coincidental, but I have just finished reading two  
> books on iPhone development with HTML, CSS and JavaScript and  
> converting that data to native App Store apps using PhoneGap or  
> QuickConnectiPhone. If you lookup both, you'll see that you can  
> create apps in JavaScript that can do pretty much everything that an  
> Obj-C app can do, including :-
>
> embedded offline Google maps,
> geolocation,
> accessing the contacts functionality,
> vibrating the phone,
> playing system sounds,
> saving data to a local SQLite database,
> sending data to other iPhones,
> and loads more native stuff
>
> If you fancy reading about this, get the book "Building iPhone Apps  
> with HTML, CSS, and JavaScript: Making App Store Apps Without  
> Objective-C or Cocoa" which can be bought from :-
>
> http://www.amazon.com/Building-iPhone-Apps-HTML-JavaScript/dp/0596805780/ref=sr_1_1?ie=UTF8&s=books&qid=1267389547&sr=8-1
>
> It's a good read and get's the mind working. Also, some good links  
> are:-
>
> http://phonegap.com/
> http://quickconnect.sourceforge.net/
> http://jqtouch.com/
>
> I'm currently researching this quite heavily, as it's a much shorter  
> journey to successful iPhone / iPod Touch / iPad apps than any other  
> route out there and also follows the same development methodologies  
> that I'm already used to.
>
> I know this is the opposite to your argument, but wasn't sure if you  
> knew of these right now :-)
>
> Best,
> Lee
>
>
>
>
> Juraj Kirchheim wrote:
>> Yeah ... no problem ... :)
>>
>> However, I don't get how interpreting ABC would be far too slow.  
>> IMO, this is just some crap claimed by Apple, to justify their  
>> policies.
>> The iPhone does support JavaScript. And as a matter of fact, many  
>> people use JavaScript to create apps for the iPhone.
>> They now even consider using JavaScript to playback flash  
>> animation. How sick is that?
>> There is no reason for an ABC-interpreter to be slower than a  
>> JavaScript interpreter.
>> Au contraire, one can perform much better optimizations on ABC then  
>> on JavaScript due to static typing and sealed objects.
>> The really draining performance draining part about flash player is  
>> rendering, namely (alpha)compositing, filters and vector  
>> rasterization.
>> Compared to that ABC-execution is extremely cheap.
>> The only "applications" where ABC-speed actually matters more than  
>> graphical performance are benchmarks :D
>>
>> I am quite convinced, Apple doesn't want to have interpreters on  
>> their device for political reasons.
>> One is, that that'd facilitate bypassing an important source of  
>> their income: the app store.
>>
>> greetz
>> back2dos
>>
>> Lee McColl Sylvester wrote:
>>> Actually, re-reading your post, you're absolutely right ;-)  I  
>>> first read it as interpreting the SWF bytecode, not "converting".  
>>> My bad!
>>>
>>> Lee
>>>
>>>
>>>
>>>
>>> Juraj Kirchheim wrote:
>>>> Well, basically the CS5 must be having some means of converting  
>>>> swf into iPhone native binaries.
>>>> They must be able to do so, otherwise they'd make usage of swc  
>>>> impossible. Also, AVM bytecode is a pretty good representation of  
>>>> the source ActionScript, so it's moreless interchangable.
>>>>
>>>> Now the worst case scenario is, we update our external classes to  
>>>> include the multi-touch API, and then we compile our code to an  
>>>> swf/swc and import it into a .fla for the final translation.
>>>> But I guess this "cross-compiler" will be included in the flex  
>>>> SDK, since I can't image Adobe will lock out the Flex product  
>>>> suite.
>>>>
>>>> In any case, I see no point in including this as a backend,  
>>>> except the fact that one can expect that cross-compiler to be  
>>>> painfully slow.
>>>>
>>>> greetz
>>>> back2dos
>>>>
>>>
>>>
>>
>>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

back2dos
In reply to this post by Lee Sylvester
Lee McColl Sylvester wrote:

> This is quite coincidental, but I have just finished reading two books
> on iPhone development with HTML, CSS and JavaScript and converting
> that data to native App Store apps using PhoneGap or
> QuickConnectiPhone. If you lookup both, you'll see that you can create
> apps in JavaScript that can do pretty much everything that an Obj-C
> app can do, including :-
>
> embedded offline Google maps,
> geolocation,
> accessing the contacts functionality,
> vibrating the phone,
> playing system sounds,
> saving data to a local SQLite database,
> sending data to other iPhones,
> and loads more native stuff
>
> If you fancy reading about this, get the book "Building iPhone Apps
> with HTML, CSS, and JavaScript: Making App Store Apps Without
> Objective-C or Cocoa" which can be bought from :-
>
> http://www.amazon.com/Building-iPhone-Apps-HTML-JavaScript/dp/0596805780/ref=sr_1_1?ie=UTF8&s=books&qid=1267389547&sr=8-1 
>
>
> It's a good read and get's the mind working. Also, some good links are:-
>
> http://phonegap.com/
> http://quickconnect.sourceforge.net/
> http://jqtouch.com/
>
> I'm currently researching this quite heavily, as it's a much shorter
> journey to successful iPhone / iPod Touch / iPad apps than any other
> route out there and also follows the same development methodologies
> that I'm already used to.
>
> I know this is the opposite to your argument, but wasn't sure if you
> knew of these right now :-)
>
> Best,
> Lee
Oh, I don't mind opposing arguments. I rather find them interesting, as
in this case. :)
Still, as interesting as I found this information, I don't quite see,
how this contradicts my argument.

I said, ABC execution can't possibly be too slow, if JavaScript
execution is fast enough for Mr. Jobs and his cultists :-D

Right now, Apple has more less full control over the iPhone. They have
total control over the app store, thus over all apps using the full
iPhone API. Google got to taste of this control, when Google Voice was
rejected. Then there is Safari, with its own JavaScript interpreter,
that has really a limited API, which is limited to classical JavaScript use.

Introducing a 3rd-party platform that has all features its providers
deems to be must-haves, but that doesn't require content to be
downloaded from the app store will take all control from apple. Full
grown apps, that're just downloaded via HTTP. Basically, you could even
bypass Apple's one-app-at-a-time principle. You can just plug together
multiple flash apps by loading them into one swf and letting them run
alongside each other. If air ran on the iPhone and added the iPhones
features, you could basically combine this rogue content deployment
mechanism with the full iPhone API. And Adobe wouldn't be the only ones
trying to get a piece of the cake. The app-store would become obsolete,
as much as the iPhone app concept, since people really do wanna use
multiple apps at a time. For example, what use do chat clients have **on
a phone** if you can't use another app at the same time. :-)

Anyway, I think the list is not the place to discuss this.
OTOH, I found your links pretty interesting. Especially with WebGL
coming up and probably soon available for the iPhone, one could really
create some great apps using haXe.
How does this work for the iPhone? Do they have some app shell that
loads a JavaScript interpreter and an HTML renderer and interfaces with
them? Or do they actually compile your sources to iPhone binaries?

greetz
back2dos

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Lee Sylvester
Juraj Kirchheim wrote:

> Oh, I don't mind opposing arguments. I rather find them interesting,
> as in this case. :)
> Still, as interesting as I found this information, I don't quite see,
> how this contradicts my argument.
>
> I said, ABC execution can't possibly be too slow, if JavaScript
> execution is fast enough for Mr. Jobs and his cultists :-D
>
> Right now, Apple has more less full control over the iPhone. They have
> total control over the app store, thus over all apps using the full
> iPhone API. Google got to taste of this control, when Google Voice was
> rejected. Then there is Safari, with its own JavaScript interpreter,
> that has really a limited API, which is limited to classical
> JavaScript use.
>
> Introducing a 3rd-party platform that has all features its providers
> deems to be must-haves, but that doesn't require content to be
> downloaded from the app store will take all control from apple. Full
> grown apps, that're just downloaded via HTTP. Basically, you could
> even bypass Apple's one-app-at-a-time principle. You can just plug
> together multiple flash apps by loading them into one swf and letting
> them run alongside each other. If air ran on the iPhone and added the
> iPhones features, you could basically combine this rogue content
> deployment mechanism with the full iPhone API. And Adobe wouldn't be
> the only ones trying to get a piece of the cake. The app-store would
> become obsolete, as much as the iPhone app concept, since people
> really do wanna use multiple apps at a time. For example, what use do
> chat clients have **on a phone** if you can't use another app at the
> same time. :-)
>
> Anyway, I think the list is not the place to discuss this.
> OTOH, I found your links pretty interesting. Especially with WebGL
> coming up and probably soon available for the iPhone, one could really
> create some great apps using haXe.
> How does this work for the iPhone? Do they have some app shell that
> loads a JavaScript interpreter and an HTML renderer and interfaces
> with them? Or do they actually compile your sources to iPhone binaries?
>
> greetz
> back2dos
>
A few points; any JavaScript based web app can add an icon to the main
iPhone menu pages, just like an App Store app would, while still
remaining an online app. This can then facilitate looking like an app
store app while having the freedom of a web app and would be how you
perceive Flash apps to be on the iPhone. As many iPhone apps require the
internet to function, this wouldn't be a big deal for chat apps and whatnot.

As for how QuickConnect and PhoneGap work, they work like any native app
would, but present a WebAppUI control and store the HTML, CSS,
JavaScript and image files as resources and push them to the WebAppUI
control when needed. The app also facilitates an extended API, which the
JavaScript engine can access using a thin JS layer. I guess this is a
direct mimic of how Flash and the AIR runtime work. The benefit is, you
can create an app quickly using JS, but have the functionality and
implementation of a standard native app. What's more, the runtimes are
fully open-source, so you could extend the API yourself to provide
custom native functionality, like image processing or native XML file
management etc.

With regard to the Flash engine, I believe Apple were quite worried
about the shear size of the Flash player and it's resource usage more
than losing control of apps in App Store. As the JavaScript route
bypasses the App Store and Apple actually promotes the development of
such apps, it doesn't make sense for the rumour that Apple are worried
about revenues lost through Flash apps appearing on the iPhone. While,
if you consider that Adobe have spent a fortune and a long period of
time making the Flash player smaller, faster and less resource
intensive, one can begin to see just what comments have passed between
Apple and Adobe. As Adobe now have the FULL Flash player running on
mobile devices (Nexus One, Blackberry etc), then they are obviously
hoping for a second round with Apple sometime this year. Steve Jobs
might consider Flash to have been bloated and unacceptable last year,
but he can't play that card with FP 10.1 or later versions of the player.

Of course, this is all IMHO ;-)

Lee



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: [OT] flash player 10.1 beta 3

Kevin Newman
On 3/1/10 5:22 AM, Lee McColl Sylvester wrote:

> As for how QuickConnect and PhoneGap work, they work like any native
> app would, but present a WebAppUI control and store the HTML, CSS,
> JavaScript and image files as resources and push them to the WebAppUI
> control when needed. The app also facilitates an extended API, which
> the JavaScript engine can access using a thin JS layer. I guess this
> is a direct mimic of how Flash and the AIR runtime work. The benefit
> is, you can create an app quickly using JS, but have the functionality
> and implementation of a standard native app. What's more, the runtimes
> are fully open-source, so you could extend the API yourself to provide
> custom native functionality, like image processing or native XML file
> management etc.
There's a difference between web apps and apps built with JS but
packaged for distribution in the app store. Many of these libraries
provide access to APIs that are not available in Safari based web apps,
and even if they aren't use (or if I'm mistaken and they don't) - you
can charge a price for the app store distributed items. This means that
Apple's profits are protected.

That said, the whole thing is silly. The App Store and the tight
integration with iPhone is a great draw for developers and publishers as
it is - it's hard to monetize content on the internet - and easy in the
app store. ;-)

I really hope Adobe is able to achieve much better performance than
JavaScript though. JavaScript is a bit sluggish on iPhone.

Kevin N.

--
haXe - an open source web programming language
http://haxe.org