Fairly or unfairly, Google’s Android often gets knocked for having a lagging or stuttering user interface when compared to Apple’s iOS on iPhone and iPad. TiPb’s previously guessed that this stemmed from very early architectural decisions made by Apple, who had a full screen, multi-touch UI — albeit it a highly limited one — in mind from the outset, as opposed to Google who originally had Android set up as a BlackBerry, Windows Mobile Standard, and Nokia competitor that had no need for high performance, sophisticated UI rendering.

That might turn out to be pretty much the case. In response to a Google+ post about hardware acceleration by Android engineer Dianne Hackborn, ex-Google intern Andrew Munn breaks down why Android’s way of handling graphics and event processing hinders the OS from offering users a more fluid, lag-free UI.

Android UI will never be completely smooth because of the design constraints I discussed at the beginning:

• UI rendering occurs on the main thread of an app
• UI rendering has normal priority

The iPhone changed things by introducing a dedicated thread with high priority for handling UI rendering, redirecting all power (CPU and GPU) to handling UI element rendering in realtime based on touch input. The result? Smooth-as-butter UI elements, transitions and animations as soon as you touch the screen — even on older hardware when paired with the latest iOS 5 software. The drawback: everything else, from app downloads to content rendering will pause so the UI can keep that high frame rate, high quality redraw pace.

Munn does disclose that he was only an intern with Google’s Android team and never actually got his hands on the raw Android source code, so this could be taken as supposition.

Indeed, our own resident Mobile Nations Android guru, Jerry Hildenbrand from Android Central says there might be a bit more to it:

The way it stands now, as long as you have free resources to run multiple UI threads [in Android] the UI is amazingly smooth — easily as smooth as the iPhone or WP7 phones. Problem is that nobody sets resource management up in a way to keep them free. A simple customization to the linux lowmemkiller kernel parameter fixes it, at the expense of huge memory hogs like Facebook or HTC applications. One day, when we have Octocore 12NM Cpu’s, DDR3 RAM, and huge batteries this way will prove better. For now, you have to hack at it.

So Android can be set up to prioritize UI, if that’s what’s wanted, but it’s not automatic like iOS. That might annoy user experience snobs, like our friends on the Iterate podcast but it might be a fine tradeoff for those with other priorities, like the big screens, different skins, and high customizability that Android’s design does allow.

Hit the source for a full technical breakdown.

Source: Dianne Hackborn, Andrew Munn

We’re back from flu enforced hiatus with an all new episode of TiPb TV featuring Apple’s all new iPad 2! There’s so much to cover we’re going to be breaking it up over several shows and fair warning — we’re going to be having fun with it. (If you want a more traditional look, go read our iPad 2 review.)

This time around Rene and I take a look at iPad 2′s Apple A5 chipset and iOS 4.3‘s JavaScript Nitro engine to see just how fast games like Infinity Blade can launch and websites like TiPb.com can render. Then we take FaceTime and the iPad 2′s “cameras” on the road for a full on tourist test at the local mall. And oh man your eyes may never recover!

(In case you’re curious, we used iPhone 4′s Wi-Fi personal hotspot to connect iPad 2 to FaceTime over 3G which makes no sense but worked well.)

Watch along with us above and then let us know what you think — is the web and app speed worth the upgrade? Are the cameras good enough to use in a pinch?

Apple has just released desktop Safari for Mac and Windows to 4.0.4, which improves full history search performance, has the mandatory stability improvements, and security fixes, but the big news as far as we’re concerned is the number one item on the list — Improved JavaScript performance

Desktop Safari is the big brother of the iPhone’s Mobile OS X Safari, and they share a rendering engine (WebKit), and a JavaScript engine (Nitro), and improvements in desktop Safari and Nitro have traditionally filtered down to Mobile Safari with the subsequent iPhone OS update. That’s right, we’re looking at you iPhone 3.2 (where ever you are!)

Since the current iPhone 3.1 Safari is still outperforming even brand-new devices like the Droid, that may seem a little greedy, but we know Google’s Android and Palm’s webOS aren’t sitting still in the rendering race, and have updates of their own in the pipeline, so once again, competition benefits the end users. Bring. It..

Update: Engadget re-did the math and it looks like the iPhone 3G S is actually 21% faster than the Palm Pre (for now).

According to Anandtech, Dieter was spot on in his iPhone 3G S vs. Palm Pre browser speed test video. (as was our iPhone 3G S vs. iPhone 3G smackdown video)

The bigger story, of course, is not only do we have several great devices pushing competition and better serving users these days, but Mobile WebKit (the rendering engine behind Apple’s Safari, Google’s Chrome Lite, Palm Pre’s browser, and Nokia S60 (tip of the hat to Sascha Segan) has become the mobile internet platform.

That it’s relentlessly standards based, scales elegantly from desktop (where it ironically holds minimal share) to handset, and is continually being improved upon makes us especially happy for all concerned devices.

Two iPhones enter, only one can be left standing. Which one will it be? Well, both devices got the Nitro JavaScript rendering engine boost courtesy of iPhone 3.0, but the iPhone 3G S brought a little gun to this knife-fight in the form of double the RAM, a faster GPU, and a super souped up processor with higher clock speed and phat’er pipes. (Think 486 vs. Pentium on the desktop).

So let’s just load up our friends CrackBerry.com, PreCentral.net, theiPhoneblog.com HQ, and Steve Job’s perennial New York Times test page and see.

(No, not which will win — we already know the answer to that! — but by how much?!)

We so fondly remember Palm’s Roger McNamee stating the Pre would be a million times faster on the web than the iPhone (now retracted), and even our sister-site PreCentral.net jumped on that band wagon, saying the Pre looked to be 4x faster than the iPhone.

Of course, we mentioned that on Sprint, lacking simultaneous voice and data, even a million times zero is still zero. Less flippantly, however, when Safari 4 Beta shipped for the desktop with its new ultra-fast Nitro (formerly SquirrelFish) rendering engine, we figured it would only be a matter of time before that scaled down to the iPhone’s version of Safari (based on the same WebKit foundations as desktop Safari, as is the Palm Pre browser and Android Chrome Lite).

Now Daring Fireball and Wayne Pan posit that turbo boost might have already happened in iPhone OS 3.0:

Wayne Pan has braved the NDA waters and published JavaScript benchmarks for iPhone OS 3.0, and they are impressive — with results ranging between 3× and 10× faster than iPhone OS 2.2. And I’ll confirm that MobileSafari on iPhone OS 3.0 passes my simple “could be Nitro” recursion depth test.

From what we’ve seen of 3.0, it seems that way to us as well. Along with HTML5, CSS, 2D and 3D animation, anti-phishing, AutoFill, etc., it will be interesting to see what Apple and the WebKit team can pull of by the time iPhone 3.0 launches this summer…