satine.org

Android has two major technical UX problems: animation performance and touch responsiveness.

Android’s UX architecture needs work. UI compositing and the view system are both primarily done in software. Garbage collection and async operations frequently block UI rendering.

Android team members are still in denial on the importance of GPU acceleration. They recommend eliminating garbage collection to improve animation performance. They say drawing isn’t the bottleneck and GPU accelerated 2D drawing won’t yield good results:

“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.

Look at Samsung’s Galaxy S browser. GPU accelerated and tile-based. I’m told it’s a result of Samsung’s PowerVR GPU optimizations. Smooth as butter, runs circles around the Nexus S Gingerbread browser on the same hardware!

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.

Wake up, Android team. Windows Phone 7 just lapped you.

Update: Additional discussion on Hacker News.

Jesper thinks that Apple is working on a new language. I’ve posted something similar in 2007, but a lot has happened in 3 years.

I believe Apple’s new runtime language successor to be (or very close to) JavaScript with an Objective-C bridge. Here’s why:

1. JavaScript is already one of the iOS platform languages.
2. JavaScriptCore Nitro is fast.
3. JavaScriptCore already bridges with Objective-C.
4. Apple uses JavaScript in deep, key areas: iAd, iTunes 9, Mobile Me
5. DashCode (and PastryKit).

Apple is probably still sorting out:

1. Security + sandboxes. I once asked Doug Crockford what he thought was in JavaScript’s future and this was it.
2. 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.
3. 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.

Technorati Tags: Apple, LLVM, JavaScript, WebKit, Objective-C

Section 3.3.1 of the iPhone SDK Agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

The thing to understand about Section 3.3.1. is that it is the legal letter of the SDK agreement, but not the desired intent.

Developers are allowed to use SQL for database operations. Developers are encouraged to use GLSL via OpenGL ES 2.0 for fast graphics. SQL and GLSL are not languages in the Objective-C family and they are compiled / interpreted. But they also don’t directly link against the Documented APIs (e.g., there’s no “SELECT subviews FROM UIView”).

Regular expressions and XSLT (ugh) are also similarly permitted.

How I intend to interpret Section 3.3.1., as an independent iPhone developer is as follows: Use Objective-C where it makes the most sense: directly interfacing with the iPhone SDK. When I need different tools to achieve something application specific, like an AI in Lua or printing commands in PostScript, I’m going to use them.

For me personally, I feel that this is what Apple permits and practices in the course of mobile software development.

Practices? Yeah. Have you looked at what iPhone OS itself uses? XML and JSON for data serialization. Nibs, property lists, XSLT in XML domain specific languages. TinyScheme to interpret Scheme code for sandboxed process permissions. hunspell‘s DSL drive the spell check dictionaries.

For sure, Apple has impure motives. But that doesn’t mean they’re wrong. Mobile constraints are different. Battery life and performance matter. A lot.

Use the right tools for the job: Objective-C when talking to iPhone OS. But whatever your application’s brain needs to think different.

Technorati Tags: Apple, iPhone, Flash, programming, languages, mobile