This is the new PlayStation Video Unlimited service. This PlayStation app runs at a full 60 frames per second (when you see it on a PS3), has tons of 3D graphics effects, full-speed 1080p video playback, and a fluid, hardware accelerated, animated user experience. What you may not know is that this is a web app.

A Web App? On A PlayStation?

The Video Unlimited service is a JavaScript application with a carefully designed runtime platform and very lightweight APIs to access hardware accelerated 3D graphics and shader effects, video playback engine, and other aspects of the PS3 hardware.

Two years ago, I helped start this project at Sony. In six weeks, our team took a working Flash UI prototype and recreated it on a PS3, complete with an early version of the platform, now internally called Trilithium. Alex Bustin, the same UI developer who built the original UI prototype, also wrote the Trilithium port.

The release of Video Unlimited was delayed until now, but Trilithium was used to build another of Sony’s partner’s apps, Hulu Plus for PS3. (See video at the end of this post).

The Trilithium Platform

Trilithium’s strength comes from taking full advantage of the PS3 hardware and existing well-optimized frameworks to do everything from graphics to video playback, leaving the decisions about the high level application to a very flexible JavaScript core API.

We built Trilithium for several reasons:

Make good use of the complex 8-core + GPU PS3 hardware without killing ourselves.

“It is very naive to think that using the GPU to render text and bitmaps is suddenly going to fix every issue you may see. There are many things that can be done to improve performance of the UI without using the GPU. Notably improving touch events dispatching, reducing garbage collection pauses, asynchronous operations to avoid blocking the UI thread, etc. A one year old NexusOne (and other devices before) is perfectly capable of scrolling a list at close to 60fps (limited by the display’s refresh rate.) Using GPUs to do 2D rendering can introduce other types of inefficiencies (fillrate can be an issue, some primitives like arbitrary shapes are complicated to render with antialiasing, textures need to be uploaded, shaders compiled, etc.) I am not saying we won’t do GPU rendering for the UI (I have worked on it myself a couple of times to test it) but please stop assuming that this is what has to be done right now.”

No one is saying that Android’s “2D primitive drawing” needs GPU acceleration. It’s Android’s view system and animation compositor that needs GPU acceleration. To compare, Core Graphics is still mostly software based while Core Animation is entirely GPU accelerated.

Stop executing Dalvik Java VM code on every animation frame. Use the programmable GPU graphics pipeline. Add a scene graph if it makes sense. Run it on a separate thread. You might even get 32-bit graphics along the way.

Android engineers say that better hardware will eventually solve the problem — an insane rationale for the problem. On mobile, power efficiency is king. Throwing dual cores or more GHz at the problem is just going to get you more average performance with zero battery life, and even then, as long as your screen doesn’t get too big.

Security + sandboxes. I once asked Doug Crockford what he thought was in JavaScript’s future and this was it.

LLVM compilation. For Apple, it makes sense to have a compiled language story that improves JavaScript performance even further via compile-time analysis and optimization, courtesy of LLVM. It’s great for iOS code validation too.

Framework design. Apple is known for taking time to try out features and APIs to get them right before publishing them.

Update To Jesper’s point about replacing Objective-C. I believe this successor adds a new level to the Apple language family and doesn’t replace Objective-C. Use JavaScript where appropriate: high level memory safe, dynamic, functional code with a productive, concise syntax. Drop into Objective-C to do performant, memory efficient, or security-privileged things. Drop into C for more speed, more efficiency. It’s turtles all the way down, and in many ways, we’re already there.