[Galaxy Note 3 General] scott.deagan:
Double posting...

I've posted this elsewhere in these forums, but am double posting it here as this thread is very similar to the other one...

I'm going to take a guess at what this quality issue is (I'm by no means an Android expert, so this is just a stab in the dark based on my experiences). But first, let's define the terms everyone's throwing around:

1. Lag: to fall behind, not keep pace.

A demonstration of "lag" on the Galaxy Note 3 can be seen by doing the following:

Remove the s-pen.

Go into the "Galaxy Plus" folder.

Start the "SketchBook for Galaxy" application.

Start drawing (it doesn't have to be too quick).

Observed results: the line rendered on the screen "lags" behind the s-pen.

Desired results: the line rendered on the screen should have zero lag (i.e. should be rendered directly under the s-pen's point of contact).

2. Micro-stutter: when the UI momentarily and abruptly stops during a scrolling operation (even if it's only for a couple of milliseconds). Micro-stutter interrupts what would otherwise be a smooth and fluid scrolling experience.

What causes micro-stutters? The simple answer is "jank": Problematic blocking of a software application's user interface due to slow operations. In order to maintain smoothness and fluidity in a UI, it is now generally acknowledge that a consistent 60 frames per second is needed. What this means is you have to complete all computations for everything that needs to be rendered in a single frame within 16.6 milliseconds. Failure to do so will result in "jank" (also referred to as "micro-stutter", or "frame-skip").

Firstly, I suspect (again, I'm not an Android expert) that since Android is a virtualized environment (that uses the DVM, or Dalvik Virtual Machine), it struggles to perform computations fast enough in order to complete computations within the required 16.6 milliseconds. This is why smoothness on Android devices is always second rate compared to platforms that run code natively. No matter what arguments are put forward, "native" always performs better that "virtualized".

Secondly, it looks like there's something fundamentally wrong with Android's architecture when it comes to the touch paradigm (which is now standard on just about every smartphone platform). The UI should be running in it's own non-blocking thread. No network or disk/storage operations should interfere with whatever the UI is doing (including UI inputs etc). This is not the case on Android - you can see the UI stutter wherever "lazy loading" is implemented (one example: the Play Store - stutter occurs when network operation is executed).

Thirdly, Android doesn't appear to use the GPU for screen rendering throughout the platform. From what I can remember, developers can set this within an applications manifest.xml file. I have no idea why any architect would choose to use the CPU rather than the GPU for rendering operations. In any event, you can see the difference in some applications by going into the Developer Options and turning on "Force GPU rendering". and then repeating the steps for testing the Engadget app mentioned in one of my previous posts in this thread. Scrolling is much, much smoother, but janking (micro-stutters) still occur.