Flash Player 11 Feature Requests

I have the following feature requests for the Flash Player.

1. Implement web workers (except ours is with compiled bytecode). Copy Chrome’s implementation, but instead of an AS class, we can give it an an Interface, much like Loader.content works. That way, we can sequester it in it’s own ApplicationDomain and SecurityDomain for security reasons, support both embedded and dynamically loaded code, and ensure it doesn’t negatively affect the elastic race track (much how Shader has a synchronous and asynchronous operation).

You can read more details on their suggested implementation here. Apparently people get really offended when you call it a “thread” vs. a “worker”. Wow, dude, no one cares, we just don’t want our GUI to lock up, we don’t care what you ask us to call it.

2. Give us access to video thumbnails for both streaming and progressive. Netflix and iTunes ability to do this really enhances usability; Amazon’s inability is lame. I realize I could load bytes via the new NetStream API or do some fancy server-side encoding ability, but that’s not solving the use case in an easy to use API. I understand the future of Flash Player since 9 has been to create low-level API’s. If NetStream can already do this within reason using the net NetStream.loadBytes, great, otherwise, let me know.

3. Continue making the GPU and/or OpenGL access in Flash Player as transparent and built-in as possible. If things like cacheAsBitmap, cacheAsBitmapMatrix, and scrollRect
“just work” to take advantage of these features, great. If I have to blit everything, set the GPU on, and abandon the DisplayList API, that’s a failure.

4. Native JSON.encode and JSON.decode.

5. Native OAuth with proper Authorization headers done by Flash Player. Every Flash Developer I know hates using it, yes has to because that’s where the world has moved. Debugging it makes you want to go crazy… if it was in Flash Player, native, and QA’d by y’all, at least we’d have a fighting chance.

New TextField API? Dude, we have larger problems. Mobile performance, lack of threads, JSON still not native in the Flash Player, and a long list of JIRA bugs & smaller feature requests people have been voraciously voting on. In my consulting, I’ve seen some amazing TLF usage. That has been the exception to the rule; the forcing it down people’s throats via the broken implementation in Flash CS5, and the god awful horror it is when attempting to embed fonts in Flex 4.x SDK doesn’t get me very excited in “creating a happy medium”.

Do the above. Win. If you don’t do anything, at least make Mobile faster.

17 Replies to “Flash Player 11 Feature Requests”

  1. I don’t care what people call it either and the web worker model is good enough for me. However, I’ve heard from other developers that they aren’t happy with that and want something more powerful and low level.

    You’ve probably seen this link already, but these notes from Adobe’s Arno Gourdol Flash Camp Brasil presentation shows some code examples of what the Flash team is thinking of:
    http://arno.org/arnotify/wp-content/uploads/2011/04/Flash-Camp-Brasil.small_.pdf

  2. Very excited to see Thibault’s reply! Great suggestions. Native JASON slipped my mind with my own list, but definitely a good addition.

  3. I still can’t figure out why Adobe doesn’t let us use the right mouse button (RMB). Is it so people can see the context menu that says the application was made with Flash? The only people interested in that information would be developers. And those developers could just as easily look in the html source code. There’s no need to remove (more then) half of a perfectly useful control device that gamers are familiar with, just for marketing reasons.

    Adding the RMB, and while we’re at it ALL mouse buttons, would be one of my top priority requests.

  4. William Sanders, as been recently writing a number of articles on parallel programming in ActionScript. Here’s his thoughts on Adobe’s example:

    http://www.as3dp.com/2011/04/07/parallel-programming-on-the-radar-for-adobe/comment-page-1/#comment-9303

    “I’m very curious to see how Adobe handles threads and other //p features. I saw some hints in the Brazilian Flash Camp presentation where they displayed a Worker object in AS3. This portends a Master/Worker //p paradigm. That worries me a little—not because it’s not a perfectly good paradigm, but the .NET people seem to be taking a different tack. They go to lengths to indicate that tracks and threads are very different. They point out that tracks are more available for potential parallelism than are threads, which to me sounds like a good model for parallel interfaces.”

    From Joa Ebert:
    http://bugs.adobe.com/jira/browse/ASL-23?focusedCommentId=397825&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_397825

    “…I think the model of web workers is okay. But is it not possible to have a low-level API and build web workers on top of it? Workers are not always the solution and we should be able to use the right tool for the right job. I think it is important to let the developer decide whether or not they want to use model A or B depending on the needs of their application. For instance there are a couple of cases were workers are nice but then again there are a couple of cases where we need different tools.
    Imagine you have a loop over 1.000.000 objects and perform very complex operations for each. With a worker, where I would offload that computation I would probably use one thread — or I have to implement the logic of splitting that up into N-workers, and then wait for all to dispatch a complete to do something like a join. A library like C# parallel would help here for instance and take that extra work away. Parallel.For(…), done. Otherwise this code will be written by 100s of developers, introducing new bugs etc.”

    Filipe Morgado says here:
    http://bugs.adobe.com/jira/browse/ASL-23?focusedCommentId=357110&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_357110

    “I’d rather have a low-level API with a total control (and total source of bugs) than a high-level API full of restrictions. People would implement all kind of safe APIs around native calls and we would just have to choose (or write) the most suitable one for any particular purpose.”

    I’ve heard from others similar comments from other developers in person. With them saying that they like the way Java or C# or python or whatever programming language of choice seems to be and that it happens to handle threads better than WebWorkers. I have no idea how many of these people have real concerns or if they are just more comfortable with another language’s way of handling threads. I don’t have any experience in programming with threads and so I’m not really familiar with the in’s and out’s myself. I just want anyway to stop the UI from locking without having to rely on green threading, which is more of a hacked solution (not to mention the speed increase with real threads accessing separate CPU cores). What I’ve seen from Adobe so far works for me.

  5. As a dev who uses Flash/Flex/AS3 as one of many tools rather than my primary focus like most of you, I’d happily help rally behind #3 and even more importantly your last sentence.

  6. and my wished are:
    – Multithreading
    – Full supporting Generics
    – Improving compilers in IDEs (alchemy like performance)

  7. Hehe, good hint from Steve, if you check his link (https://bugzilla.mozilla.org/show_bug.cgi?id=640711) you’ll see that JSON is a feature we have been working on lately. You can check the early performance benchmarks we have, kind of cool :)

    Web Workers too, we are working on this by the time we talk, and we decided to offer a safe model ala WebWorkers or similar to BackgroundWorker in .NET cause it makes a lot of sense as a first model to introduce and matches what most people will need. You will be able to prevent the UI from locking and be able to leverage multiple cores, but there will be restrictions (a non fully shared model) but it will unlock most of the situations you may have been trapped in. Right now we are thinking about doing both, aggregated model and embedded.

    You will be able to send most common datatypes to the workers (this will be copied). We are actually thinking about ways to actually deliver workers that match the common problems people have when developing Flash content and common techniques (passing a BitmapData for image processing, offscreen DisplayObject access for layout and content drawing to be rasterized later on, etc.), so a better model than WebWorkers where you are limited to String or JSON at best.

    And again, exposing the complexity of low level threading (with a shared memory model), this may be useful in some cases for sure, but it is a question of tradeoff and I think we unlock most scenarios with the first model, and I am not a huge fan of exposing such a complexity in the player, or if we do, then let’s do it through a secure model and something really new and nice like STM.

    Continue GPU efforts, yes, we are doing this through StageVideo and now Stage3D (Molehill). And we have plans in the future to abstract more and more the low-level APIs to make this easy to leverage for 2D, which I think is the most appealing thing for game developers today, using Molehill for 2D.

    For the Native OAuth and Video stuff, I adde this to my list to investigate ;)

    Thanks for the suggestions!

    Thibault

  8. Whoah I had no idea this stuff was under development. Sweet. I would add HotSwap ability when debugging so I don’t have to restart an application every time I compile.

  9. Good suggestions and discussion from Thibault.

    I’d also very much like to see language improvements – generics at the very least but they don’t seem to be mentioned very often so I’m a little worried.

  10. I’d love it if computeSpectrum() didn’t throw a security error, or if we could use the FFT on Sound.extract().

Comments are closed.