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.

With 52 days to go, and the iPad rumor mill kicking into gear, the question of the day is, “what is the iPad’s mystery icon?”

So, if you think it’s crazy for Apple to be hiding mystery iPad software and hardware, remember that history tends to iRepeat itself.

Personally, I’m looking forward to iChat and Dashboard widgets on iPad.

Update: Felipe makes a good point in the comments. On June 18, 2007, 11 days before the iPhone launch, Apple also upgraded the display hardware from plastic to glass. Glass display parts are $16 today, while camera parts are roughly $10.

Technorati Tags: iPad, YouTube, Apple

User-Agent: iTunes/9.0 (Macintosh; Intel Mac OS X 10.5.8) AppleWebKit/531.9

Survey says: Yes.

It’s important to understand that iTunes is only using WebKit to render the iTunes Store and iTunes LP. The rest of the iTunes UI still remains native in Carbon.

Previous versions of iTunes had a custom native UI for viewing the iTunes Store and were definitely not WebKit based prior to iTunes 9.

Technorati Tags: Apple, iTunes, WebKit

Technorati Tags: Apple, Google, CrunchPad, TechCrunch

Technorati Tags: Apple, iPhone, Developers, iPhone SDK, App Store