Where is 64-bit Linux support for Flash Player?

I run 32-bit Linux but there is a very vocal group of people who really want 64-bit Linux support for Flash Player. Today there is a decent work around for running the 32-bit Flash Player on a 64-bit Linux system using the nspluginwrapper. From what I’ve heard it works fairly well on most distro’s but I haven’t heard yet how well it works with the new Flash Player 10 beta. Despite this potential work around eventually Adobe does need to natively support 64-bit Linux – and they will. This is not as simple as a recompile – otherwise there would be 64-bit support today. There is a bug already filed in the public Flash Player bug database for 64-bit support. I’d encourage you to not just go vote for that bug but also to get involved. As Tinic Uro points out in the bug comments, the missing piece for 64-bit support is open source – so you can help! Flash Player uses the open source Mozilla Tamarin VM. This VM does not yet support 64-bit Linux because all that machine code generation in the JIT compiler needs to be ported from 32-bit to 64-bit. The code is in Mozilla’s Tamarin Central Mercurial repo. This IS open source! You can help get 64-bit Linux support for Flash Player!

The Open Web: Now Sexier and Smaller

In the past Open Web proponents have criticized Flash and Flex because the SWF specification – while being published and publicly available – limited what readers could do with the specification. More specifically the agreement to view the specification required that readers not build programs that would run SWF files. The intentions behind this were good – Adobe does not want Flash to have inconsistent and incompatible implementations.

Today Adobe Systems has announced that they are removing those restrictions on the SWF and FLV specifications! This is very exciting news and something I’ve been lobbying for since I started working for Macromedia (actually I think I began bugging Emmy Huang about this before I started working for Macromedia). Flash has become the standard for sexier web experiences with RIAs, video on the web, and interactive web content. Today that standard is truly open!

Adobe has also announced the Open Screen Project which aims to create an open and consistent layer on top of the countless small device platforms including consumer devices, phones, MIDs, and set top boxes. This is an extremely exciting project that will hopefully do for the world of small devices what the browser did for the PC world. You could also call this the “RIA Everywhere!” project. :)

Software keeps getting more exciting and the Open Web just got sexier and smaller!

Talkin’ About a Revolution

Revolutions may be enabled by technology, but they are driven by people. Adobe’s recent announcements about Flex, Flash, and Adobe AIR on Linux are the most recent technology enablers for the software revolution that is currently underway.

Usually I’m one of the first to post about Adobe’s Linux related announcements. My trip to Bangalore, India, however, made me a little late to the party this time. In case you haven’t seen the announcements, on March 31, 2008 Adobe released an alpha version of Adobe AIR on Linux and an update to the alpha version of Flex Builder 3 for Linux (which supports building AIR applications on Linux). On the same day Adobe also announced that we joined the Linux Foundation.

In a post about the announcement, JD points to one of my old blog posts, which still accurately echoes the significance of this announcement – “… for the first time EVER, nearly everyone in the world has access to a FREE, ubiquitous application runtime, and a FREE application development toolkit for that runtime! Of course I’m referring to Flash Player 9 and the free Flex 2 SDK.” Now I can update this statement “For the first time EVER, everyone in the world has access to a FREE, ubiquitous web runtime, a FREE cross-OS desktop runtime, and a FREE, open source, and mature development toolkit for those runtimes! Of course I’m referring to Flash Player 9, Adobe AIR, and the Flex 3 SDK.” This is huge. We can now build real software once and have it run on every major OS and in every major browser – and we can do it using open source tools!

Why the excitement? Haven’t we had this for years – with Java? QT? GTK? True… in theory. We’ve had the technology; but we always lacked a critical mass of people that were actually using it for wide reaching, real software. There are now countless companies – including Oracle, SAP, Salesforce.com, Intuit, E*Trade, eBay, AOL, NASDAQ, Yahoo!, and numerous startups – that are using Flex to build real software for Flash Player on the web and Adobe AIR on the desktop. This kind of software revolution is reminiscent of the transition from client-server to web applications. The movement is real. The technology is mature (even the new Adobe AIR desktop runtime consists primarily of mature, proven technologies like Flash Player, Tamarin, SQLite, and Webkit). Software is changing for the better, especially for those of us on Linux.

I now have several desktop applications installed on Linux – such as the eBay Desktop – which I would never have had before AIR worked on Linux. Most companies simply do not invest time and money building or porting their software for such a small customer base. With AIR it doesn’t matter. Companies build the software once and it works on the web, on the desktop, on Windows, on Mac, on Linux. This is a software revolution not because the technology exists, but because people – lots of people – are actually using it.

Today we call the products of this software revolution “Rich Internet Applications”. In ten years it’ll just be “software”.

Bursting Bubbles

Bubblemark is a popular benchmark for some of the RIA technologies including Flex, Adobe AIR, Ajax (DHTML), Java Swing, Java FX, Silverlight, etc. I’ve been trying for a while to create a new Flex version of Bubblemark to show just how fast Flash Player and Adobe AIR are. But I’ve come to a few realizations… First, you can make benchmarks say whatever you want them to say.

When trying to optimize Bubblemark I found a few interesting things. First was that IE (and some versions of Firefox) limit the frame rate of Flash Player (and possibly other plugins). This means that while the Flash Player VM might be able to actually achieve 200+ frames per second the actual visual result might be only 60 fps. And maybe this is for good reason. Why do you need a visual frame rate faster than the refresh rate on a monitor? You don’t. And especially not for RIAs.

Graphic rendering performance is certainly relevant for RIAs but that is only one factor which affects overall application performance. As Chet Haase points out, Bubblemark lumps a number of different factors – calculation speed, rendering performance, and timer resolution – into a single “frames per second” metric. That leads to my second realization.

The frame rate of bouncing bubbles isn’t very relevant to RIAs. As Josh Marinacci of Sun says – “there aren’t any real benchmarks yet for rich internet applications.” I think that my Census RIA benchmark is more pertinent to RIAs than bouncing bubbles. Census benchmarks how quickly an application can get data from a server, parse that data, and render the data in a datagrid. Sorting and filtering are also important benchmarks that I’m working on integrating into Census. Today the Census app has various Flex and Ajax tests but I’m also currently working on adding a Silverlight test, an Ext JS test, and an updated Dojo test. I’d love it if someone would create a Java FX version as well.

Just for kicks let’s go back to Bubblemark and see what I was able to come up with (with help from Chet Haase). I created two versions of the new Flex Bubblemark application. You can run each version in the browser (Flash Player) or on the desktop (Adobe AIR). The results will vary between the web and desktop versions due to the browser throttling. The first application will only move the bubbles once per frame. This is similar to the original Flex Bubblemark application. If the browser is only letting Flash Player run at 60 fps then the maximum fps will be 60. Adobe AIR seems to limit the fps to 250 but I haven’t yet confirmed that. With both of these versions CPU utilization should be pretty low since they are being artificially throttled. The second set of applications moves the bubbles as many times as possible per frame. The appearance of these might be choppy since the bubbles only get rendered after being moved potentially hundreds of times. The second set of benchmarks is more real world if you are interested in VM processing speed as opposed to resolution of the timing mechanism. However a third set of tests which is probably the most useful and that I haven’t yet written would calculate how many bubbles can be moved once per frame and maintain 60 fps. That kind of metric is probably relevant to RIAs that need to do a lot on every frame. But most RIAs I’ve seen are more concerned with the speed of data processing. Here are the new Flex Bubblemark applications:

Single Move Per Frame: Web | Desktop (requires Adobe AIR 1.0)
Many Moves Per Frame: Web | Desktop (requires Adobe AIR 1.0)

(Flex Bubblemark Source Code)

Benchmarks are only useful when you apply them to your scenario. Is the performance good enough for what you need? Are your users able to run what you build? There are thousands of RIAs which run in Flash Player and now hundreds of Adobe AIR applications. For the millions of users of these applications the frame rate is fast enough and the VM performance is superb. For the developers of these applications the Flex tooling enabled them to efficiently build these applications. Not only do the runtimes and the tools work on Windows, Mac, and Linux – the runtimes and core development tools are free. There is more to choosing a platform than the speed at which a runtime can bounce objects around the screen. Sorry if I’ve burst any bubbles.

Tamarin-Tracing: Mozilla’s New VM for ECMAScript 4

[Update: QVM was an internal Adobe codename. The new VM’s name seems to be “Tamarin-Tracing”. For more info on this new VM read the announcement by Edwin Smith. Edwin doesn’t explicitly state that the VM is for mobile devices but it is hinted at. However the research paper that Edwin references does state that this tracing type of VM is good for mobile devices.]

The mobile space has been heating up lately with Apple’s iPhone, Google’s Android, and Sun’s JavaFX Mobile. But what about all of us developing with JavaScript 2.0 / ActionScript 3.0 / ES4? While we have been able to build for Flash Lite with Flash CS3, those of us developing with Flex haven’t had an easy way to use our existing programming knowledge to build mobile applications. Part of the reason for this is that the core language of Flex (AS3 / ES4) isn’t yet supported on mobile devices. The good news is that Adobe has just contributed a new VM targeted at mobile devices, to the Mozilla Tamarin project. Tamarin is the open source core of Flash Player 9 and will at some point be the VM in Firefox that executes JavaScript 2.0. More specifically AVM2 is the VM piece of Tamarin which executes ActionScript Byte Code (ABC). ABC can be created using the soon to be open source Flex SDK’s ASC compiler which turns AS3 (or ES4) into ABC. Unfortunately AVM2 wasn’t written to work well on mobile devices. So Adobe built Tamarin-Tracing – a new VM in Tamarin which is much better suited for non-pc devices. This is very exciting stuff!

Flash Player 9 Update 3 Sim-Ships on Windows, Mac, and Linux

Yesterday was a monumental day for Flash Player. For the first time ever, a major release of Flash Player was simultaneously shipped for all three of the major operating systems – Windows, Mac, and Linux! This illustrates Adobe’s commitment to being truly cross-platform. There isn’t a ubiquitous platform in existence that is as committed to cross-platform compatibility as Adobe is with Flash Player. This is one of the things I love about Flash Player. Sun promised us “Write Once, Run Anywhere” with Java and yet they have never been able to really deliver it. Theoretically maybe, but in reality how many Java apps / applets do you see with the breadth of use that Flash Player has? Despite Java’s disappointing failure of true ubiquitous cross-platform compatibility I am hopeful that the OpenJDK will fix this. The OpenJDK does seem to be fixing the recent problem of Java 6 not being available on OS X.

Congrats to the Flash Player team! This is a significant milestone that everyone benefits from!

For those of you building Flex applications you can download the debug versions of this new release here. Also there is more information about all the great new features and bug fixes in this release on Tinic’s blog, Mike’s blog, and Emmy’s blog.

What is a Rich Internet Application?

The more software experiences become like the natural world the more users are pleased with those experiences. One of the most powerful, understandable, and universal concepts in computing is the idea of a desktop containing files and folders. Users embraced this metaphor in their software because it modeled their natural world experience.

There is a paradigm shift underway. In this shift, developers are creating user interfaces which more closely model the natural world. Since 2002, the term used to describe these types of software applications is “Rich Internet Applications”, or RIAs. Technologies like Ajax, Flex, Silverlight, Adobe AIR, and JavaFX are growing in popularity as this shift to RIAs gains momentum.

But what is an RIA? Answering that question is like trying to answer “What is a tree?” You may be able to identify an RIA or a tree with certainty when you see one, but coming up with an exact definition can be very difficult. In cases like this, the best one can do is to identify some of the fundamental characteristics that the term encompasses.

When you break down the phrase “Rich Internet Applications”, you find that “Internet” and “Applications” are well understood. It’s the “Rich” aspect that makes RIAs interesting, and it’s the “Rich” aspect that requires a fuller explanation. Essentially, a Rich Internet Application is capable of delivering a rich experience to the user. It is the richness of the experience that is often enhanced by making software that is more natural – more connected, more alive, more interactive, and more responsive.

Connected

We are all connected. On this relatively small planet we all have many things in common. We communicate with one another via many different methods, in many different languages, sometimes easily and sometimes with difficulty. Likewise RIAs are built on a network that connects us all – the Internet. RIAs use this network of billions of connected pieces to help us communicate – between each other and between systems, sometimes easily and sometimes with difficulty. And like each of us, in some scenarios RIAs need to be able to work when disconnected from the Internet.

Alive

Movement and the passing of time are critical to our experience of beauty and the emotional reaction we have to it. Watching waves continuously crash on a beach is an experience which fills us with life. Similarly, we would not sit and watch a beautiful sunset for very long if it never changed. In RIAs, we create rich experiences by modeling the movement and beauty we find in the natural world. Smooth sliding transitions, zoom effects, soft blurs, drop shadows, and rounded corners are elements of RIAs which help make software feel more like the natural world. Beauty is often simple and never overdone. Software that feels more alive evokes an emotional response from us. That emotional response can help to improve our overall satisfaction with the software. RIAs should feel alive.

Interactive

When people communicate they interact — sometimes physically, sometimes audibly, and sometimes visually. Interaction is how we transmit and receive information. The richness of an experience is heavily dependent on this interaction made possible by our senses. RIAs facilitate physical, audible, and visual interaction. Many new devices are allowing for more natural methods of physical interaction. Multi-touch interfaces like tablet PCs and media players are becoming more common because users want to interact with software like they interact with objects in the natural world. Many more software applications are also adding video and audio capabilities, and some of these applications support bi-directional multimedia interaction. This allows users to interact visually and audibly in the context of an application. Imagine filling out a form online and, if needed, being able to interact via webcams with someone who can help you complete the form. Applications which embrace interactivity to that level are helping to bring natural world interactivity to software experiences.

Responsive

In the real world when people interact with each other or with objects like rocks and trees, those things typically respond quickly. If I kick a rock it immediately moves, unless it’s a big rock in which case my foot immediately hurts. If someone speaks to another person they expect a timely response. At a baseball game, you can see scores whenever you want, just by looking in the right place. Too often in the world of software people are forced to wait for their computers to respond. Whether due to network connectivity issues, processing limitations, or other problems, software too often makes us wait. Most web applications leave users waiting for at least four seconds every time the user clicks on something. With many applications the wait times can be significantly longer, even on a broadband connection. Imagine what an everyday conversation would be like with that latency. Real-time streaming, high performance client side virtual machines, and local caching mechanisms are becoming in integral part of RIAs because these technologies reduce latency, increase responsiveness, and make software feel more like the natural world.

Natural Software Experiences

All kinds of software applications — from ERP business applications to word processing applications — are embracing the characteristics of what we now call Rich Internet Applications. This move is happening because users intuitively want to experience software like they experience the natural world.

Rich Internet Applications are proliferating because they are more connected, alive, interactive, and responsive than yesterday’s software. In ten years nearly all software will be what today is called a Rich Internet Application. But in ten years it will be only natural to just call it “software”.