About Flash Runtime 2016


#1

During the last Flash Online Conference, the more exciting part was about what Adobe would present to the attendee of this conf.

Chris Campbell
Product Manager & Customer Advocate for the Flash Runtime
@liquidate | ccampbel@adobe.com

So, Chris made a presentation about what to expect for 2016, here are the slides and some notes I made about it.

he mentioned people can contact him by email, but remember for subjects concerning the Flash Runtime

not the first time that he mentions it, here another example

just to say: yes people at Adobe can and will listen to what users have to say

So he started by listing the recent features

He continued by talking about the partnership of Adobe with Facebook

here the clickable URL http://adobe.ly/1NqCVQM

True, in the last few months the Flash Player have been more aggressively attacked by the medias about security concerns, not only Adobe have a partnership with Facebook, but also Google and other many independent security researcher.

The point was to show they do something about it, they don’t ignore it.

Then he continued by explaining the release cycle of the Flash Runtime

The red dot is a major release or a new version number.
The white dot is a “+1” release, in general reserved for bug fixes and security updates.

When you see “Flash 21”, it’s the version 21 for the Flash Runtime and that concern both the “Flash Player” and “Adobe AIR”.

So, here version 21 is the “Sutter” release, “Sutter” being the codename (street names in San Francisco), and so next releases would be:

  • Flash 22, Townsend
  • Flash 23, Underwood
  • etc.

It is also important to mention, because if you are under the impression that there is a lack of love from Adobe about Flash and/or AIR, well … you can see here that there is a monthly update scheduled “every second Tuesday of the month”, and this is a nice proof of commitment from Adobe.

So, if your concern is about security or new features or maintenance of what is already there, it is reassuring to see that kind of commitment.

Then the last slide was about the next updates planed

Note the choice of wording here “Upcoming Priorities”, in my opinion is what most people fail to see with the Flash Runtime.

When some people see that and remember the times where you had big new features added to the runtime, they can of react like “oh they are just doing the strict minimum”, or “this proof they are just in maintenance mode” etc.

What they fail to see is the change in dynamics

Before:
The Flash Player was the main runtime, and when you had updates it was on a yearly basis at best, eg. you had to wait 1 year and most of the time 2 years to get new features.
It was mainly focused about the web, even if AIR was around it was mainly for desktop, not for mobile.

After:
Even if the Flash Player is still an important runtime, it share the podium with AIR and in particular AIR for mobile, for the last 5 years or so mobile is all the rage.
Also, the updates are monthly now, you can not update a runtime with big features in just a month, it’s too short, and if you update it’s not only the web now, it’s many devices with different screen sizes, DPI (let’s call that resolution), and a lot of tiny little things.

From my point of view, I see that Adobe adapted to this new dynamic and so for many years now.

So, yeah the new features seems small compared to before, but wait one year put all those monthly features together and then you can see the big picture: it’s not small at all, in fact it’s quite smart.

Let’s get in the details of some of those features, to do that I will split them per categories

General

  • PCRE Updates for Flash Player and AIR
  • CORS origin header support
  • Stage3D asynchronous texture upload

Web

  • Flash Player support for new Content Security Policy (CSP) for full-time SSL
  • Video Texture for Flash Player
  • Linux PPAPI installers
  • Flash Player out of process support for Microsoft Edge
  • Support for HiDPI displays in Firefox on Windows

AIR Desktop

  • HiDPI support for AIR Desktop
  • 64-bit AIR - Windows
  • Decoupling the captive Flash Player plugin from the AIR runtime
  • improved HTML5 support in AIR desktop

AIR Mobile

  • Echo cancellation on Android & iOS
  • New Video stack for Android
  • iOS 9.0 multitasking and split screen support
  • iOS App thinning support
  • Provide soft keyboard focus support
  • Stage3D anti aliasing on mobile

See that new dynamic ? there is no more such thing as “one feature that fits all”

The general updates are mainly about security and upgrade of what is already there

PCRE Updates for Flash Player and AIR

PCRE is the regular expression engine by the Flash Runtime, it gonna be updated so be sure to check in the BETA channel if it breaks or not your regexp.

In details, see PCRE

PCRE is short for Perl Compatible Regular Expressions. It is the name of an open source library written in C by Philip Hazel. The library is compatible with a great number of C compilers and operating systems.

As far as I know, the Flash Runtime is still using PCRE v7.3

And the plan is to use PCRE2 v10.20

see PCRE2

PCRE2 is short for Perl Compatible Regular Expressions, version 2. It is the successor to the widely popular PCRE library. Both are open source libraries written in C by Philip Hazel.

The first PCRE2 release was given version number 10.00 to make a clear break with the previous PCRE 8.36. Future PCRE releases will be limited to bug fixes. New features will go into PCRE2 only. If you’re taking on a new development project, you should consider using PCRE2 instead of PCRE.

CORS origin header support

CORS for Cross-Origin Resource Sharing

is a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the resource originated.

the way it works

The CORS standard describes new HTTP headers which provide browsers and servers a way to request remote URLs only when they have permission. Although some validation and authorization can be performed by the server, it is generally the browser’s responsibility to support these headers and honor the restrictions they impose.

To update the Flash Runtime, yep it’s not only the Flash Player but also Adobe AIR, it would require to patch many internal Flash API to support CORS.

Flash Player support for new Content Security Policy (CSP) for full-time SSL

In Implementing Content Security Policy, Mozilla explains

Content Security Policy (CSP) is a security standard introduced to help prevent cross-site scripting (XSS) and other content injection attacks. It achieves this by restricting the sources of content loaded by the user agent to those only allowed by the site operator.

The policy is implemented via headers that are sent with the server response. From there, it’s up to supporting user agents to take that policy and actively block policy violations as they are detected.

I do hope Adobe plan also to support it with AIR, but yeah technically as a priority it is more important to support it with the Flash Player first.

Video Texture for Flash Player

In the documentation VideoTexture we can see a support for AIR 17 and Flash Player 18.

It is indeed supported since AIR 17 (iOS) and AIR 18 (Android), but it is not supported for the Flash Player.

You can refer to 2 blog posts

The current beta implementation is for Windows AIR only.
We will be adding support for Mac, iOS and Android AIR
in an upcoming release.

  • Video Texture on AIR for Desktop and Mobile

    So,Video texture object was introduced, which allows hardware decoded video to be used in Stage 3D content. Video Texture is only available for AIR not for Flash Player .

Stage3D asynchronous texture upload

The use case is explained here [New_Feature_Requirement] Async texture uploading for Stage3D.

If you’re not too familiar with Stage3D, let me give you an example with a basic image gallery not involving 3D: let’s say your gallery can display 1000 thumbnails, and on a screen you can fit 40 thumbnails or so.

If you preload 1000 thumbnails you gonna “kill” your memory usage, no what you want to do is to load only the thumbnail that the user is actually viewing, in our case 40, but most importantly, when the user scroll to another screen you want to unload those 40 images from memory and then load a new batch of 40 images. All that to keep some kind of control on the resources and have a constant use of the memory.

eg. if 1 thumbnail use 1MB, then you know at all time that 40 thumbnails use 40MB of memory, whatever the total number of images in your gallery (100, 1000 or more).

On a desktop, not a big deal as you can have a lot of memory in the range of 2GB to 4GB and more, on mobile it matters a lot as you are much much more limited, for example the latest iPhone 6+ have 1024MB of memory but you can allocate max 645MB.

In general, the “rule” on mobile is whatever the amount of memory in your device you can use about half of it, yes memory is sparse on mobile even with the latest device.

Now apply the example to 3D textures and suddenly your life can become hell and you have to return to old tricks like palette indexation and reuse of textures in odd place to use less memory and/or reload less textures etc.

I’m pretty sure anyone using Stage3D will welcome with both arms this feature :slight_smile:.

AIR 64bit on Windows is coming

It’s not gonna be a complete switch from 32-bit to 64-bit like they did for Mac OS X.

Adobe will not release 2 AIR SDK for Windows, one in 32-bit and another in 64-bit.

No, what gonna happen is that they gonna add a permanent AIR SDK 64-bit for Windows in the BETA channel, and keep releasing in the official channel a 32-bit SDK.

That way, if you need to produce an AIRT desktop app in 64-bit, you can use the AIR ASDK from the BETA channel and use the captive runtime to produce a 64-bit app.

Chris mentioned you could shoot him an email if you are interested in the 64-bit beta.

Considering that the usage of Windows 32-bit vs 64-bit is 50/50, I would say that’s the right move to keep the AIR SDK 64-bit for Windows only in the BETA channel.

Decoupling the captive Flash Player plugin from the AIR runtime

So far, when you distribute an AIR application on desktop, the Flash Player plugin is embedded into the app.

That means if you use HTMLLoader or StageWebView, and you display a SWF in the HTML, it does not use the Flash Player installed on the system.

What Adobe plan to do with this feature is to remove the Flash Player from the AIR runtime and if a SWF need to be displayed to look into a system location to find and use the Flash Player plugin.

If it’s not there a little badge will be shown to install it.

But you will also have the possibility to embed your own Flash Player plugin into your AIR app.

In a scenario where you build an AIR app with AIR SDK v20 and embed the latest Flash Player plugin v20, if later the system is updated with Flash Player v21, then an HTML page displaying a SWF from inside your AIR app will use the Flash Player v21 from the system.

IMHO the best of both worlds.

Personally if I could also have this feature in AIR 2.6.5 for Linux (we can dream) that would be even better, eg. instead of using something like Atom Electron to create a desktop app which is basically an HTML that embed a SWF we could just use an AIR app that also embed a SWF via HTMLLoader.


So, that’s about it, the features look small but they are not, it’s more about prioritization of what is more needed or important, small+small+small+small == big.


split this topic #2

A post was split to a new topic: Flash News in the Medias
reason: different topic


#3

The thing is Flash runtimes have been mature for a long time now. You look at the rapid evolution of browser APIs and 99% of it is stuff that has been done already in Flash runtimes, usually many years ago. When you have a mature runtime the updates aren’t going to be filled with sizzle like “post-processing filters! blend modes! animation! video! p2p! real-time sockets! OOP programming language!”, instead its small improvements, bug fixes, and compatibility. For example CORS compatibility is just crossdomain.xml we’ve had for years now, compatible in the browser (but it’s more annoying to implement CORS).

One thing I don’t see on this roadmap that I really wish was there is to decouple WebKit from HTMLLoader, so that we could use newer version of WebKit.


#4

Totally agree, the Flash runtimes is mature, and not only that but also the Flash API

few examples

  • CreateJS, and associated libraries
    is about bringing the Flash API to HTML5/JavaScript
  • Dart come along ?
    you can see StageXL
  • Swift arrives and …
    someone made an ActionSwift 3.0

and many more things alike are all about bringing this Flash API to other environments and/or languages, something about the Flash API must be good for that to happen right ?

hahah exactly, and that also show how much Flash influence the world around.

Many problems faced by dev have already some kind of solution in the “Flash world”, but nobody will ever admit they got the idea/concept from Flash …


Well … it’s been mentioned earlier in the starling forum

AIR in 2016 - Feedback survey and Christmas Tale

  • Improved HTML5 Support in AIR desktop
    We’d like to collaborate with the community on this one. I was hoping to find someone that has created an ANE (using CEF or something else) and learn more about their experience. Ultimately, we’d prefer this end up as an open source project.

from what I understand, Adobe would like to find someone or a small group of dev who have already worked on building an ANE for the desktop that integrate preferably CEF.

CEF is the Chromium Embedded Framework, if Adobe would prefer that it’s because they already worked on it with Brackets and many other products like Creative Cloud, Dreamweaver, Edge Animate, Edge Reflow, etc…
in fact they are quite involved with it see
Chromium Embedded Framework 3 Builds, where it says
“hosted and maintained by the Web Engine Team at Adobe”.

And before that on the Adobe forums
How do you use AIR’s WebKit/htmlloader?

A long standing issue in AIR has been the inclusion of an older version of WebKit. The request to update this library has come up many times in the forum and is in the top 10 on the community driven Uplist feature page. As with the recent and ongoing physics discussion, we’re not committing to any changes purposed below at this time, as we’re purely in an investigation mode at this time. We realize that this is an important feature and we need further clarification on what you’re looking for. Please read on for questions from our development team.

To the credits of Adobe they open sourced Webkit in AIR so if you have no idea how to do interop between JS and AS3, digging in this project can help a lot, etc.

And from all that here what I understand of the problem

  • everyone (Adobe included) is aware that the Webkit in AIR
    need an upgrade, for HTML5/CSS rendering and other little quirks
  • Adobe investigated it, but they are not gonna do it
    is it a budget problem ? a time problem ? size of the dev team problem ?
    I don’t know, but they are clearly not gonna do it
  • the compromise would be to use an HTML engine/renderer from an ANE
    and there, maybe, Adobe would “like to collaborate with the community on this one”

Personally I got a pragmatic approach, when Adobe does not do something I don’t see it as negative but more like a possible opportunity for someone else to do it.

For example, when mobile dev is all the rage and AIR 3.0 introduce ANE,
Adobe show some examples on Native extensions for Adobe AIR and then provide
some ANE for free, then those ANE get distributed as part as the gaming SDK: betatesting.ane, gameCenter.ane, productStore.ane, Social.ane, stageAd.ane.

Which let a new market wide open for other people to step in and sell commercial ANE for the mobile market, which I see as something positive.

Adobe does not do it, someone else is doing it, at the end of the day users are happy because if they need something native for Adobe AIR mobile development they can find “addons” to buy in the range of ~20$ which is not a buzzkill.

But for Adobe AIR desktop, the story is much different

  • you can dev ANE but only for Windows and Mac OS X
    no Linux target there (locked out by AIR 2.6 that does not have ANE)
  • the desktop ANE market is much much smaller than the mobile ANE market
    whatever the amount of efforts you would put into a commercial ANE
    you would be kind of stuck to sell it in the range of ~$20
  • even worst, if you do develop a desktop ANE and either sell it or make it open source
    you are most likely giving it for free (or close to it) to a potential competition
  • if you try to sell non-trivial desktop ANE in the range of ~$200
    it will fail as users are already used to to buy ANE in the range of ~$20

Developing and building a Chromium Embedded Framework ANE for Desktop AIR in itself is a great idea and also a great opportunity but

  • it’s not a small project, it’s a big one
    we’re not talking about couple of weeks of development
    but more in the range of 3+ months of intense development here
  • wether you decide to go commercial and/or open source with it
    you are f*cked, no way you can recoup time/costs with it
    supporting it / fixing it / maintaining it would be hell lot of time
  • amount of people who are able to contribute to
    a cross-platform C++ project is about null
  • chances that Adobe would collaborate / help / get involved ?
    a huge exclamation mark

that’s a lot of risks to take for a small entity (1 dev to 5 dev team)

but here the big one nobody seems to think about
in the HTMLLoader documentation you can read

On desktop computers (in the desktop and extended desktop profiles), the HTMLLoader class uses the internal AIR WebKit engine. The features available and rendering appearance are the same as those of the StageWebView class, plus close integration and script bridging between ActionScript and JavaScript. Since the StageWebView class uses the system web control provided by the Flash Player plugin, concurrent use of StageWebView and HTMLLoader instances is strongly discouraged as it has undefined behavior and can possibly terminate the application.

if already StageWebView and HTMLLoader does not play nice with each other in the internals of Adobe AIR, I can not even imagine how adding a CFE ANE can be an integration nightmare.

I have sent an email to Adobe asking a couple of questions around end of February,
I’m still waiting for the answer.


split this topic #5

A post was split to a new topic: THE FLASH ACCENT - EPISODE 2 - Flash Player 11 and 3D