So what exactly did they do technically to double the performance of stock ICS?
I read the article and watched a few minutes of the video and there was no detailed answer. The article itself didn't seem to link to any detailed resource either.
Everyone is saying "nothing", but I reviewed the patches (I did /not/ bother watching the video, however, as it was long and I was in a place where I felt uncomfortable playing sound; so maybe the video says "we didn't do anything" ;P), and what they did is to remove all of the non-strict pointer aliasing (one of C's optimization weaknesses) and thereby were able to kick the optimizer up to -O3, which is helping some already tightly-coded algorithms actually avoid touching memory.
It's not double the performance. It's a demo that if you use the software GLES implementation (which isn't used in production) they can run that benchmark at 60fps. The non-linaro toolchain GLES renders at less that 60 fps for this benchmark and then degrades to 30fps because the setup is double buffered and vsync'd.
Vsync doesn't convert anything in the range of 31..59 FPS to 30 FPS. Vsync prevents fractional frame updates. You can still have any integer number of frames per second with vsync enabled. Anything less than 60FPS will just look like a dropped frame.
(Double-buffering isn't particularly relevant to FPS that I can see. It just prevents you seeing the frame while it's being drawn, in practice it's mostly useful for reducing flicker from overdraw.)
It's related to double buffering and vsync together. If the pure rendering performance was 45fps, when the render is complete the next render can't progress until the buffer currently being displayed is available - hence degrades to 30 fps.
Ah OK. I was assuming a world in which triple-buffering was a given; in other words, that vsync in practice was a rendering implementation detail for avoiding tearing, rather than something that blocked the renderer. I can see how things are different on a resource-constrained device that can't afford triple-buffering.
I'll add that usually you don't see a constant rate of rendering performance. Render time for a frame wanders above or below 16.67ms (with the design target being under that, if 60fps is the aim) depending on complexity or how busy other tasks are. It's not usually the case that every frame takes 22ms (i.e. 45fps) to produce; so it would be very unusual to see a game / app flip from 60fps straight to a locked 30fps. Rather, the odd frame will take slightly more than 16.666, with most falling under. The statistical distribution will give an FPS rate somewhere between 30 and 60.
I read the article and watched a few minutes of the video and there was no detailed answer. The article itself didn't seem to link to any detailed resource either.