For those who have missed this, Arno Gourdol, leading the Flash Runtime engineering team presented a session at Flash Camp Brasil last week entitled, Future of the Flash Runtime. Arno unveiled some very cool features we are working on right now, and I wanted to make sure you guys know about those in case you did not luckily attend Arno's session.
If you are curious about the slides, you can download them here.
Here are some of the features we are working on :
- Faster GC : GC hint API and more.
- New numeric types : float and float4 (very useful for Molehill in the future).
- Concurrency : Worker threads (shared nothing model) to leverage multicore CPU's. No more UI 's blocked when doing expensive operations.
- Stage3D : The API used for Molehill (that you know through the Incubator builds).
- StageVideo : Allowing full GPU acceleration (decoding + blitting) when used with H.264. Part of Flash Player 10.2 and coming to AIR soon.
- Threaded video pipeline : Will decode non H.264 streams on another thread (H.264 being decoded by the GPU), Net I/O will also be moved to another thread, all this bringing smoother playback.
I will be covering some of those in more details later on, stay tuned! 
Comments (50)
Concurreny!! Bring on the threading!!
“Concurrency”, this changes everything…
Short iterations please
What about the byte/short datatypes?
great news!
What about faster runtime? As far I know abc compiler also isn’t quite good, Haxe makes better optimizations at this moment.
please think also about enabling right button not only for context menu !!
Great! I am so looking forward to use Threading.
Sounds really cool.
I’ll join with Rob asking for byte/short types, it shouldn’t be that painful and it may add quite a lot of flexibility in memory micromanagement.
Also, I’d really like to see a modern storage API. Shared objects are an awesome concept, but really dated now. We’re entering an era with high-resolution 3D texturing in the Player, and for the end-user sake, it would be much more efficient to be able to store that (and any kind of binary data) in a local storage, without being limited by serialization/deserialization stuff of SO, and even allowing to pipe a texture from storage to VRAM directly, without going through managed memory.
I’m kinda dreaming here, but if you’d like to discuss this potential feature further, you know how to join me
Thanks Thibault!
+1 for samuel. So how will shared-nothing, well share nothing? It has to at some point.
Concurrency! multi-threads!
Our prayer has been answered, amen!
I’ll join Rob and Samuel…
We need a datatype which costs only 1 byte of memory… Even a boolean occupies 4 bytes…
so “byte” datatype would be very handy addition…
Thanks
These features are really cool, any estimated date when the new fp ships?
If there will be a “float” type, will there be a “Number” type renaming to “double”?
Yay threading!
Any Alchemy type considerations?
Or Aparat?
Wanna know man?
What the flash really need is just one thing: “pointers”
Garbage collections is sucks, but if the Flash give to us some way to access the memory directly, just like the Pointers, it’s OK!
And what about WebM(VP8)/H.264 encoding for Camera class? So we can achieve Skype video-call quality?
What about 64 bits integers/doubles. Many file formats and net protocols use them.
Threading, it was about damn time
. Although that Disclaimer: Future banner worries me, I hope it won’t take long to see this come true. I wonder what the support will be for different synchronization primitives.
About the faster AS part of the slide, what does nullability means? will that be the equivalent to .Net nullable types? If so, it is nice and it has several uses, however I’d prefer some other things like method overloading, structs, enums and private constructors.
I like the changes… congrats to the team pretty excited about finally having new numeric types.
One feature that i would love to have : inverted masks !
what do you think ?
Hy!
Great!!
What have you done there dudes! what is the frame 18!?!?!
Can we have video from the sessions?
Cheers.
Isn’t its future quite behind it? It’s probably one of the most irrelevant technologies, with ms’ Silver-thingy, looking forward.
awesome news.
Hi Rob and Samuel,
Yes, I would kill for more primitive types too (byte, short, etc.). Would make a lot of things lighter in memory and easier when working at the byte level.
It is definitely on the radar, but we needed float/float4 for faster 3D maths operations for Molehill.
For storage, I will reach you
Thibault
Awesome new to finally have some info about concurrency/worker threads. I can’t wait to see that pop up in a future Incubator release of Flash.
Page 12 has the new Flash Player quarterly release schedule, which I vaguely remember someone else from Adobe blogging about. Is the big red dots and blue smaller dots represent big releases followed by smaller releases? Or is that just graphical look that doesn’t mean anything?
This looks great all in all. Thanks guys for pushing from release to release.
I have to agree with Bartek:
Free the right-click! We could add so much more value to our projects with that tiny change!
Wooo Concurrency!!! This is the biggest feature the SDK has been missing.
Worker threads. Thank you so much – you just made my day! Can’t wait to play.
Hi Haluk,
Of course you will be able to pass data in and out of the worker, but internally the player does not share the data. Data will be copied, so for huge amount of data, you may have a cost for the copy, but most cases should be totally fine even when passing a big ByteArray or BitmapData instance. We even have hardware instructions today on some CPUs for fast memcpy.
This shared-nothing model enforces a model where there is no state shared between the background worker and your UI thread. No side effects. This makes your programming easier and removes the need of using locks which would increase the complexity of your code.
Think of it as the WebWorkers model in HTML5 but enhanced, cause you will not be limited to Strings or JSON for message passing. Another similar implementation is the BackgroundWorker API in .NET.
Thibault
Where may I find out more about AS3 nullability???
When instantiating the following class …
public class Example {
private var _location:Point = new Point ();
private var _view:Rectangle = new Rectangle ();
}
… 3 different objects are allocated (Example, Point, Rectangle).
If both the Point and Rectangle references are not nullable, does that mean their memory space will be allocated within the Example instance memory, so only one object is allocated when instantiating the Example class?
This WOULD be awesome and would reduce by half the allocations in an application taking advantage of this.
Thanks a lot Thibault for clarification. Although I agree that, the out of the box thread safety of SN is invaluable, I suspect whether it is the best solution for EVERY scenario. So an addition to my wish list would be thread types, however it is way below on the list.
Hi Haluk,
Yes, this model will not cover every use case, but most of them. I think people will come up with ways to architect their application in a way to leverage this mechanism as nicely as possible.
We may expose lower-level threading with a shared memory later on, but not for now.
Thanks for the interest!
Thibault
Hi maliboo,
We are working on improvements on this side too. I cannot talk about this for now, but you will like it
Thibault
Didn’t read about threading following a shared nothing model. I knew Adobe was going to implement concurrency so developers didn’t need to worry about synchronization, but this is not what I expected.
I hope Adobe will expose a shared model later on, but I don’t complain at all, as this will cover most of the common needs out there, and will avoid all the common problems people have with concurrency.
Will people be able to choose worker priorities? What is the maximum number of workers that can be spawned? Will there be ways of aborting/pausing/waiting for the end of workers? Also, will workers suffer from the script timeout limit? I really hope not.
Multi-threading ! This is gona be awesome to build big smoothy application !
Armetiz.
Hi Thibault,
All this features are very exciting. Can’t wait to test them !
It would be great to have a specific Flash Player and a specific tool to build Tablet Website and Application with Flash. All this Molehill improvements are great but I’m pretty sure that some of this functionalities will not be adapted to a “slower” device like e-pc or tablet. And even if it will, I am convinced that tablet are different in their use and need a specific authoring tool. Of course, they’re is already Flash Lite, but this tool is more for mobile…
Anyway, Thanks for all these details, that’s great to see all this improvements !
If you’re adding new primitive types, then it would be great to add a date solving the TimeZone problems when using Webservice or AMF Services.
No automatic convertion into locale time, when using not UTC.
Seperation between Date (with Time), DateTime, Time… like in Java, C# or ABAP.
Would help to solve the problems between Flex webservices expecting xsd:date (not xsd:datetime) and Flex Date, which is at the moment a type combining Date and Time…. .
Would make the life of developers in the enterprise sector much easier, when applications running in multiple timezones.
shared memory indeed could create more problems than it solves. What I would really love to see is a way to hand over a object from one thread to the other. example: subthread.take(data); should clear/lock all references in the current thread, allowing the subthread to access it immediately. In that way big chunks would not be that much of a problem.
anyway: I am happy for this progress
So as much as I like the idea of offering concurrency in Flash, I have the strong suspicion that the presence of concurrent threads is too much for a lot of the Flash users out there.
These are people who barely understand code in the first place, and they’re now expected to use threads to make applications run more smoothly? If you thought Flash got a lot of criticism for being buggy and unstable before, just wait until people who have no idea what to do with concurrency start messing with these threads.
@Martin
Shared memory should be an option, there are several legit uses for it. The non shared model could be built on top of it, and be just the suggested way to go. This way, we could see some more libraries related to threading.
@anon
Just because there are people misusing some technology, it doesn’t mean the rest of people should be denied to use it and suffer from those constraints.
BTW, I don’t know if this is somehow “forbidden” or taboo, but saw tonight the SL5 Beta has been released, would love to see some benchmarks between Molehill and the XNA support in SL. Also, would like to know the objective point of view of what it offers of people like Thibault.
I assume that Worker scope will run in main SWF scope? So we can reach Camera and Microphone objects in worker *without* additional security dialog? (this will be kickass feature for Augmented Reality! – process image in background, and return simple position object)
thats a good news should be much faster
Is there a beta (AIR) where we can play with concurrency like we can with Molehill? I would really like to add / test this with a project because of the locking. It’s a closed group so installing an AIR beta is no problem.
Any news on the cancelled Physics engine? Will it make it into the next Player?
Very cool stuff. I’d like to see private constructors and Abstract classes added too
We realy need a free right click handling for a browser game in development. Is there any chance that it will be in the next flash player?
Wow finally … threading … I’m so excited with what the future holds for Adobe Flash/Flex!!!!!!!!!
Yes concurrency!! This is what I am talking about!!
Who needs that junk? Performance is the least of the problems with the GC, make it stable and predictable then worry about speed. 3D is about the least important thing to worry about. Sure it will be nice, but it would be nicer to have a half-intelligent compiler, more language features (generics, better introspection, overloaded operators, virtual classes), a stable text engine that doesn’t leak like a torpedoed battle-ship, and a faster runtime. Stop adding bloat! Except for threading, you can put that in
Any news on the release of threading? I’m putting all my Flash Building to bed till its out!
Trackbacks/Pingbacks (3)
[...] se está trabajando, mejoras ya disponibles y que nos trae el futuro de Flash. Aquí os dejo este link. Comparte: sociallist_7aa47878_url = [...]
[...] ที่มา – ByteArray [...]
[...] [...]