The Verge covers the same Google+ post that I quipped about yesterday.
Much of the discontent around UI responsiveness and animation smoothness in Android versions before ICS has revolved around the fact the OS does a lot of its rendering through software — meaning that the processor, instead of a dedicated GPU, is handling the visuals. That’s an inefficient way to do things and takes away CPU cycles that could be used elsewhere, but the point Dianne makes is that it’s not in itself the cause for sluggish performance. If you have a fast enough CPU, you can deal with some software rendering without a hitch.
The original post by Dianne Hackborn basically says that the problem isn’t that Android lacks hardware acceleration, it’s that it chooses not to use it.
Tomato, tomato.
That is such a complete and utter bullshit response to the criticism being leveled at the Android UI experience. If your platform has hardware acceleration built in, but you choose not to use it to smooth out the UI, then your UI isn’t hardware accelerated. Period.
I have personally never seen a review that claims Android lacks hardware acceleration. In fact, when I posted about the Eee Pad Transformer Prime the other day, I also did not make that claim. I only claimed (as have many others) that the User Interface rendering is not hardware accelerated. She points out that the window compositing is accelerated, but that drawing inside of a window is not.
Well now that’s a pretty huge fucking deal, wouldn’t you say?
From her post:
Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
There’s that pesky multitasking that’s so important. I’ve personally never found myself wishing for my iPhone to have full bore multitasking. Even back on my 3G.
Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice — there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.
Well then learn where it’s appropriate and where it isn’t, then provide an animation API that abstracts all of that information away from the developers. I suppose it’s hard to determine where it is and is not appropriate to use these features since there’s no consistency in hardware across the devices. Oh well.
Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.
Either she’s blaming bad developers of third party apps, or she’s saying that there are parts of the OS itself that conducts file I/O on the UI thread (easy to do since Android runs on a single-threaded UI model). Either one is a little shameful. Furthermore, it’s tragic when you can (and do) blame third party developers for writing software that ruins the state of affairs on your platform so easily. Another win for platform “open-ness”.
You’ll notice that at their heart, a great deal of the defensive positions that Dianne takes relate directly to the architecture of the operating system. When you allow apps to engage in unadulterated multitasking, heavy file I/O, and all of the other things that Apple explicitly doesn’t allow, then you do have to start taking in to consideration things like RAM overhead. In that respect, I guess Apple wasn’t working under the same “restrictions” that the Android team was working under back in 2007.
In my mind, this only serves as further vindication for Apple’s decision to keep multitasking out of the OS until the hardware had caught up. They very easily could have allowed it, with the numerous jailbreak tweaks as evidence of this. I used those tweaks, and I can tell you now that they absolutely had a noticeable impact on the usability of the phone. And when it came down to it, I chose the improved user experience over letting my Facebook News Feed update in the background.
I challenge you to find me a single piece of public literature aimed at engineers from Apple that ever brings up the challenges of making the UI experience smooth in the face of hardware constraints.
You won’t find one. “Because it’s hard” is such a bullshit cop-out. It doesn’t matter what it is you’re talking about. And that’s basically what Dianne Hackborn is saying in this whole long diatribe.
“Our UI sucks because making interfaces is hard”. They had to wait for a machine with a quad core processor and “full hardware acceleration” before they could show off a UI that was even noticeably close to a device like the iPhone 3GS, which is over two years old.
