[LG Optimus 2x] TrymHansen:
I didn't say I had the answers, I just said I think you should read it. At least then everybody will have some common ground before speculating more.

<no-fact zone>

As I understand, from that article and more, (we're talking GB and below here), unless Android has been modifed to sync with the refresh rate (think Samsung), there is no smooth scrolling in Android. The solution so far has been to "render everything as fast as we can" and hope that that gives an appearance of smoothness. It doesn't matter if the refresh-rate was 60 or 72, it wasn't accounted for anyway.

I just examined 3 phones, all of them GB. A Sony, the O2X and a Huawei. None of them have "true" smooth scrolling, even if the hardware is capable enough. (You get the same "jitter" as the O2X.)

Even if you use OpenGL, there is no true syncing to the display. I've just created a game and depending on scene-complexity, number of lights and so on I get a max of 116.66 fps. (At default settings it runs at 55-75 fps, depending on what's going on) So it seems to be capped at 117, yes. Why not cap at 72? The following might explain:

The game runs horribly on the SGS2 (with the default setttings.) I tested it before I had the FPS-display ready, but at the time it seemed like since it wasn't able to achieve 60fps, it reduced it to 30. That would be excellent for scrolling menus and such, and horrible for a game. (Then again, it might not be related to this at all, just much weaker hardware on the SGS2, which as far as I know is not the case. I honestly thought it'd outperform the O2X.)

As for tearing, I don't think this can happen. The compositor always has the last word, and that is truly synced to vsync.

Currently, if you want to achieve butter-smooth scrolling, you have to:

* take charge of the rendering yourself. (OpenGL)

* Measure the time it takes to render one frame, including swapping buffers and such.

* Sleep for the remaining part of the 13.88ms you have at your disposal between each frame (72fps)

* ... and just hope that the timing is accurate.

(If you use native code you can do some more exciting stuff I think, like syncing to vsync, but the point is that there is no direct support for this for regular apps.)

Even if you *could* sync to the display, that's only a tiny piece of the smooth-scroll puzzle. It's easy enough when you can move a constant amount of pixels per frame, but what do you do when for instance slowing down a flinged menu? (This part may be accounted for in the APIs actually, I think they can operate on subpixels.)

Let me make it very clear I in no way pretend to be an authority. If someone could tell me how to sync to the actual display-rate in regular 2D-apps I'd be thrilled to be wrong, it would mean a lot for upcoming projects.

</no-fact zone>

On the Commodore 64, and later the Amiga, there was a beatiful feature: You could create an interrupt when the graphics-chip was about to draw a certain scan-line. For a full-screen scroll you'd set this to just below the last scan-line, and you'd have the entire blanking-interval at your disposal to draw all your stuff.

(It had other tricks as well, as the ability to shift the entire display one pixel. This, in combination with the interrups made smooth scrolling a breeze.)

(On the Amiga this was heavily used in the OS. You could have several screens of different resolutions displayed simultaneously. The interrupt was set, when it was called it switched the graphics resolution, and repeat for each screen at next vertical position. Very simple and elegant. Man how I wish we could have something similar on Android, hardware-wise.)

I guess this veered off-topic.

Anyway, ICS will fix most of this. Now app-developers have to learn to fetch data in separate threads. Many of the hiccups today are caused by apps fetching data in the middle of scrolling.

I guess by Android 6 we will achieve the smoothness we desperately seek. ;-)