The Care and Feeding of the Android GPU

the two tickets, "Support for external keyboard, mouse" and "Browser doesn't render SVG images" both strike me as absolutely essential to making smartphones competitive with PC's. people have been happily attaching fold up keyboards to Palm Pilots for a decade now, SVG is perhaps the only sane route forwards for resolution independent apps and animation, and Apple has found religion on both these topics-- yet Android is obstinately behind.

otoh composited gpu acceleration is not nearly the huge obvious win C. Ying boasts it as. the gpu is more power efficient than the cpu for intensive applications, but a smartphones natural state is not intensive use. mr guy of android points out a number of complexities-- opengl drivers only supporting a single context, opengl acceleration proving less speedy than software implementations. it places huge emphasis on driver support, which any embedded wonk will tell you is a scary prospect.

although gpu acceleration is becoming better supported, keep in mind that the smartphone market expands, both up and down, with broadcom & others putting out chips designed for sub $75 smartphones. android is definitely not winning the race for the top atm, but performance has always been a rather lonely market-- that said, unsmooth experiences dont fly. software graphics focus insures a base level of performance for everyone, and strikes me as the right place to start to insure a speedy experience not subject to external interrupts.

the current silkiness situation is a little sad. it'll get better. more relevant to me is Android not playing in the ecosystem-- external peripherials, UPnP/DLNA, SVG-- these are the real things that will make or break not Android, but the open digital web, and Android is failing, badly, even in compare with non-web-enthusiasts Apple.

Both Charles Ying of Satine and wzdd seem sympathetic to this notion that the gpu is a power saving device. Surely it is when doing complex work. On the other hand, most smartphone usage consists of relatively simple screens and basic if any transitions. If it's only going to take 3ms of CPU work to run a 150ms animation, by all means, figure out how to keep the OS from interrupting the high priority graphics task and make the CPU do it. Particularly if the GPU would have to be on across the entire 150ms. If not, what is the cost of copying the graphical content between the GPU and the CPU? How much CPU does it take to initialize and set up the GPU for this extremely simple task you ask of it? Is the CPU going to be able to sleep while the GPU is running the animation, and if not what kind of context switching and control costs are going to be imposed on the CPU to manage the graphics state?

We've barely begun to see multi-core cell phone GPU's, but the point of the GPU is basically to run lots of work at a nice low clock rate where voltages can be dropped. If you dont have a lot of work to do, there's really no sense waking up the GPU and having it's extremely dumb poorly-branching cores chug away at figuring out, say, the SVG animations that a semi-competent ARM core could knock off right quick. You're just wasting power turning on the GPU.

Smoothness and polish, I suspect, are much more a questions of resource allocation than CPU capability, particularly when you've got a sub 640x480 surface and a 1GHz core.

One thing I did notice right away was that the console felt different. It felt like it was maybe more responsive somehow, and not just when it was scrolling a wall of text. It even felt different when I was typing. Somehow, typing at a console (not in X, not via SSH) felt better in FreeBSD than it did in Linux. I couldn't tell you why, and I didn't really understand it myself. It wasn't something I could measure, or even describe, but it left me feeling like FreeBSD was more than 'just like Linux'.

I only used it for a day or so before I realized that I'd screwed up the partitioning and wiped out my Windows partition, and so had to re-reformat, but it left a profound impression.

I feel like iOS is the same way. All the Android phones I've tried (including a friend's Nexus One) have been, theoretically, the same as an iPhone in terms of features and capabilities and even hardware, but even before I got into using them in depth there was just something that felt a little off about tapping on icons or scrolling lists, and I could never put my finger on it, so to speak. Perhaps it's just design decisions or usage patterns that I'd internalized already, but I've always felt like it was something more. Maybe the scrolling behaviour is something I picked up on unconsciously, because while I don't remember it being slow or jerky, I do remember it didn't feel right.

Perhaps the numbers-oriented engineers at Google can't quantify it and so don't prioritize it, or maybe they just don't think it's worth wasting time on, but I think consumers, in the end, will notice. The real question is how many will actually care, and how many will shrug it off because of the benefits (perceived or real) that Android provides them over the iPhone?