Not necessarily. High-performance apps on Android are written in C++ and RenderScript anyhow, not Java/Dalvik.

Missing the point: you can write a blazingly fast android app in c++ with opengl; but it cant do anything useful because it can't use ui components, and will be stuck with sucky custom in-game ui components which, I think it's fair to say, are universally terrible (the QT port being the one exception to this).

If you can in _any way_ achieve a method of using the existing android ui components and making them faster, this is a massive win.

Actually the trend on both mobile platforms seems to be away from stock components to either heavily re-skinned components or completely bespoke components. Games in particular tend to go their own way on this, probably partly because they need to be x-platform.

Games (and often multimedia creation apps) have been rolling their own UI for a long time.

I think you still miss his point - games have been rolling their UIs out of necessity for a long time, in large part because in most OSes (mobile or otherwise) native UI widgets simply do not mix with a big real-time rendered DirectX/OpenGL surface.

So games have always been the fastest, most optimized performers on any platform.

This isn't about games though - this is about regular ol' apps, many of which are incredibly slow and could really use the 8x performance improvement that these folks have been able to achieve.

As a mobile dev myself, I don't think mobile platforms are moving away from Obj-C or Java. Sure, we have a lot of custom-built widgets to overcome shortcomings in what Google/Apple provides, but ultimately they're subject to the same performance limitations that plague the stock widgets. Nobody out there is digging into low-level OpenGL optimizations to write a custom navigation bar, for example.

Sure. Game devs don't build UIs in C++ and OpenGL because it's faster. It's because it's the lowest common denominator on the platforms they care about, which is why I was observing that it's funny that C++ is in a very pragmatic sense more portable than Java now.

Most devs use some kind of wrapper library like Cocos2d to take the pain out of raw OpenGL, of course, and they can usually get by with much simpler library of widgets than the OS itself has to provide.

That is useful for this discussion globally, but is irrelevant for my comment: with that in mind the performance of Mono vs. anything doesn't matter at all, much less specifically vs. .NET (which is the contention of the user I was responding to).

Not if they want to run on Google TV, which doesn't support the NDK.

Google TV has to support the NDK if they want games for it and I think they do.

IMHO, the biggest problem with Windows Phone 7 (that wasn't emphasized much in all comparisons to iOS or Android) is the lack of support for native code. Whether this was done for legitimate reasons (like portability between ARM and x86) is not really important, what's important is that C++ is the language most games are written in and if you lack the support for it, then most games will only get ported if your platform is a clear winner, which is not the case yet for Windows Phone or Google TV ... therefore from what I know, Windows Phone 8 will have support for native code, because it badly needs it.

So I wouldn't worry too much about it.

Well it doesn't support the Intel Atom ones, but they are going to use ARM soon for all the new ones, and it should work then. If they move fast, it could become quite a nice mini-console platform for set top boxes that you can get for $100, allowing you to play all the native and emulator games from Android on your TV.