> sometimes a new texture must be uploaded to the GPU, and it must
> be done from the rendering thread, because [on Android] it has the
> only OpenGL context!
My understanding is that in principle you can have multiple OpenGL contexts on Android, but in practice (according to gurus on the Android forums) this is likely to be unreliable in practice due to implementation bugs. Since there are many different OpenGL implementations on Android - one per GPU vendor - you would need to do a lot of testing before trying to use this.
(This was one of several bad things that I discovered about Android when I experimented with it last year; another was that the debugger didn't work with multi-threaded programs. I was actually quite shocked by how poor at lot of it was once I poked below the surface. I believe some things have got better in the meantime.)
> On iOS there's also a slight pause in the animation during the
> texture upload.
On iOS, you can definitely have multiple OpenGL contexts, one per thread, both in theory and in practice.
> objC was new to me, and xcode 4 is fairly buggy and crashes quite
> often, and then there's all that additional complexity around object
> allocation initialization, and autorelease pools and references that
> you need to explicitly care for. The class files are longer than their
> java counterpart, and the need to free every little object explicitly
> adds a chance for making mistakes. I really don't believe in requiring
> programmers to forcibly care about this sort of stuff when most of
> these allocations that add to the programming-type complexity are so
> small that it doesn't even matter if they hang around for a while and
> are taken care of by GC at some convenient time later.
Right, I agree. So does Apple, and they now have GC on Mac OS and "automatic reference counting" on iOS.
However, my suggestion would be to use C++ with smart pointers. This has the advantage of working on every platform that you might ever want to use - even WebOS! - but not Windows Mobile.