I'm not so much concerned about Chrome performance - even though the numbers show a dramatic difference, I don't feel any scrolling slowness - it's still 60fps (or close to it), after all.
I'm more concerned about weaker (mobile) devices, e.g. about the first retina iPad which had a bad pixels/CPUGPUpower ratio.
But as always, actual devices behave different than one expects: it seems to completely ignore "background-attachment:fixed" (the one applied at the body). The background SCROLLS! That one is running iOS 6. The same for iPad mini and iPhone 5 with iOS7.
The background of the sap.m.App control is constructed in a way that it is fixed even without "background-attachment:fixed", so I tested this as well with the mentioned devices. And it felt perfectly fine, very fast.
On a Galaxy S2 with Android 4.1.2 it does not feel very smooth, but there the same is the case for regular we pages or even native apps. Making the background solid does not change the performance there.
So overall it does not seem like there is a notable impact for the user on actual devices.
And one has also to consider that scrolling inside Page controls is done by JavaScript, using the iScroll library, so this makes it automatically slower and any perceived slowness (e.g. on Android) is more likely to be caused by that fact.
When you look at the recording of the frame painting in the third example with sap.m.App, you'll notice that one the one hand the painting takes considerable time, and more than in your optimized version.
But on the other hand it only takes 8.x milliseconds for each frame and you see how the browser is idle half of the time because for the 60fps (which are apparently the targeted frame rate) the browser has 16.7 milliseconds for each frame.
So the browser could draw it faster (up to ~120fps) but does not see any need to do so. So I'm not sure how it would feel slow to a user...
Still, thanks again a lot for your great effort! The video is a fine guide for anyone who wants to track down performance issues. And the particular example could have turned out to be a really big issue.
Even if it is not really slower on Chrome, it certainly consumes more CPU cycles the way scrolling (and the theme) is implemented right now - and when thinking of mobile device battery life, this actually is a concern.
Regards
Andreas