I like big butts!
I was currently investigating Android's raw bitmap rendering performance, to see if a Mocha Doom for Android branch would be feasible. Yeah I know someone already made a prBoom-derivative port for it, but good luck getting that closed-source binary blob to run on an unrooted phone, or getting it updated.
The good news is that the current Mocha Doom codebase is "digested" by the Android API, so if someone wanted to use the Mocha Doom logic to create a Doom-like game, it would be definitively possible, provided my "AWTDoom" app is replaced by one suitable for Android's system events.
Android's canvas drawing functions can be very fast, provided you use line, circle, filling etc. drawing primitives, and even pre-loaded bitmaps can be draw with scaling and clipping at a reasonable speed, even on pre-2.2 devices (hence, with no JIT). We're easily talking hundreds of updates per second, when using Canvas.drawxxx(...) functions.
As for max. screen update frequency, my Sony Xperia 8 (Android 2.1)is able to update a 320 x 400 pixel area more than 60 times per second, using a raw int array as a screen buffer and filling it manually each time using a modified arrayfill function, and that's without using OpenGL. If the array is already stored somewhere in memory (e.g. uncompressed animation), the time to draw it to screen is really negligible. These are the good news.
However, it goes downhill from here: Android doesn't support any form of indexed display, and even 16-bit bitmaps are treated as hicolor RGB and are forcibly blown to a full 32-bit Canvas before being drawn.
The problem is that Doom is a game that relies on indexed palette manipulation for its lighting and colormap tricks, and on the ability to set an arbitrary palette of colors for some of its visual effects, so if I keep the inner working intacts.
I benchmarked how long it takes for Android to copy the contents of an int array to another and then display that to the screen, and usining an optimized array fill operation resulted in a 60 fps update at 320x480 resolution. However, converting a byte array to an int one using a palette table (which is what a Doom source port will need to do at the end of each frame.some point) was SHIT SLOW. It doesn't help that there's no native function to do that, and no JIT in 2.1.
So slow in fact, that it can't be performed faster than 10-12 fps at vanilla resolution, at least on a JIT-less Android implementation (still stuck with 2.1, sigh). Even the existing mixed-code Doom for Android that uses a prBoom binary blob is quite slow to update, and I think that one actually uses a GL surface to force hardware palette conversion, which means creating a new GL texture each frame. Unsurprisingly, that one doesn't run very smooth either.
So, either I wait and see if 2.2 will definitively solve this bottleneck on the same hardware, if Google decides to add native support for indexed 8-bit or even 16-bit images (which is why Mocha Doom works so quickly on the desktop), or if there is a way to implement a 32-bit renderer without using colormaps. Another way would be to write a special primitive-based renderer for Doom e.g. draw sprites as clipped and scaled bitmaps, which are generally hardware accelerated even without using OpenGL. If this could be extended to textures too, it would make an awesome novel implementation of Doom's renderer (at least some pure 2D elements like the menus, automap and sprites could be def. drawn this way).