Before I got into any real analysis I wanted to get some hands on time with a variety of devices and dig a bit more into what exactly 4.1 changed around compared to previous builds of Android to make things smoother. Have 4.1 running on a couple of 7s, the GS3 and the original Atrix and been testing them out along with another GS3 and original Atrix running 4.0 and 2.3 respectively. Some observations.
JellyBean isn't "faster", in fact it would appear to be slower in ideal situations almost always even compared to GingerBread. It is, however, smoother and loses performance at the top end while giving the impression of making the bottom end perform better.
Based on documentation and observations JB is using a timed loop for all rendering elements of the UI. Triple Buffered and locked at a 16ms target for render state, this means if you have any screen elements that aren't updating fast enough, the last known render state is used and drawn and the next frame is put together. This is actually slower then the previous Android builds in an ideal situation(in performance terms) and appears to be directly comparable to iOS. Slower response, but smooth and constant across the board. Gives the overall impression of being 'faster' to those who wouldn't be able to tell the difference, which is going to be the overwhelming majority of the people and pretty much everyone all the time they are not actively looking for it.
The method they are using isn't one they should have been handling all along either. This is clearly a case where hardware progressed far enough for them to change the way in which they handle the OS interface on a procedural basis. Due to the wide differences in screen elements that Android has, this type of rendering method would have rather severe performance issues on hardware that wasn't capable of keeping up with the timing. The triple buffering will cover you for ~33ms, but the inability of older devices to handle changes in render states faster then that would cause massive performance issues. If they were to do things like remove widgets and live backgrounds, they probably could get away with it on most of the devices released in the last couple of years, but this is the type of rendering setup that will bring a device like the OG Droid to its' knees and probably the majority of the single core phones(not that single core itself is the issue, but the GPUs they shipped with weren't up to the task).
If anyone has ever used an emulator before and turned off the speed limits and seen how insanely fast things went, this is the type of rendering system that JB has moved to. They were always locked by VSync in the past, but the initial response was going to be faster then the new method as was their peak performance(draw it as fast as we can and let VSync limit us).
With JB now using a fixed render time target, moving forward devices should fairly quickly level out in terms of smoothness. There will be some disparity at first as those with less then ideal hardware or additional launcher overhead is going to be just enough to cut into the render time(this will go away with hardware), after that we should have a fairly uniform rendering experience across JB and beyond devices until Google opens up modified render states to the OEMs(motion blur etc).
One other notable thing that was painfully obvious, TouchWiz is still painfully bad, ended up swapping over the SPB for the SGS3, very clunky interface. Unfortunately it isn't likely to change given how incredibly popular Samsung devices are
JellyBean isn't "faster", in fact it would appear to be slower in ideal situations almost always even compared to GingerBread. It is, however, smoother and loses performance at the top end while giving the impression of making the bottom end perform better.
Based on documentation and observations JB is using a timed loop for all rendering elements of the UI. Triple Buffered and locked at a 16ms target for render state, this means if you have any screen elements that aren't updating fast enough, the last known render state is used and drawn and the next frame is put together. This is actually slower then the previous Android builds in an ideal situation(in performance terms) and appears to be directly comparable to iOS. Slower response, but smooth and constant across the board. Gives the overall impression of being 'faster' to those who wouldn't be able to tell the difference, which is going to be the overwhelming majority of the people and pretty much everyone all the time they are not actively looking for it.
The method they are using isn't one they should have been handling all along either. This is clearly a case where hardware progressed far enough for them to change the way in which they handle the OS interface on a procedural basis. Due to the wide differences in screen elements that Android has, this type of rendering method would have rather severe performance issues on hardware that wasn't capable of keeping up with the timing. The triple buffering will cover you for ~33ms, but the inability of older devices to handle changes in render states faster then that would cause massive performance issues. If they were to do things like remove widgets and live backgrounds, they probably could get away with it on most of the devices released in the last couple of years, but this is the type of rendering setup that will bring a device like the OG Droid to its' knees and probably the majority of the single core phones(not that single core itself is the issue, but the GPUs they shipped with weren't up to the task).
If anyone has ever used an emulator before and turned off the speed limits and seen how insanely fast things went, this is the type of rendering system that JB has moved to. They were always locked by VSync in the past, but the initial response was going to be faster then the new method as was their peak performance(draw it as fast as we can and let VSync limit us).
With JB now using a fixed render time target, moving forward devices should fairly quickly level out in terms of smoothness. There will be some disparity at first as those with less then ideal hardware or additional launcher overhead is going to be just enough to cut into the render time(this will go away with hardware), after that we should have a fairly uniform rendering experience across JB and beyond devices until Google opens up modified render states to the OEMs(motion blur etc).
One other notable thing that was painfully obvious, TouchWiz is still painfully bad, ended up swapping over the SPB for the SGS3, very clunky interface. Unfortunately it isn't likely to change given how incredibly popular Samsung devices are
Facebook
Twitter