Follow up to “Android graphics true facts”, or The Reason Android is Laggy • Hacker News Board

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#91

Post by saurik » Tue, Dec 06, 2011, 6:49 AM UTC

freemarketteddy wrote: post #89

saurik wrote: post #80

Earlier quoted context omitted.

The user complaints are with regards to delays in event processing ("sloppy" or "laggy" touch events), not general animation that does not involve user input; the specific examples in this article demonstrating how this "dedicated" UI thread with "real-time priority" exists detail touching the screen and watching the system lock up as it is now busy handling the scroll events. Also, it is my understanding that surfac…

I think one subtle difference is that in iOS there is some degree of parallelism even in the UI Updates as they happen in the NSRunLoop of the main thread(main NSRunLoop). So that an UI Update that is waiting for hardware can be delayed and the next UI update in the loop can be processed. I dont seem to recall any such pattern for Java main thread UI Updates.

An NSRunLoop is normally a CFRunLoop, and a CFRunLoop is pretty much just "get next task; run that task; loop": if one task blocks, it cannot run the next one; the only way for it to look like it is doing multiple things at once is for code to reenter the runloop using CFRunLoopRun(), which is hardly ever used (it increases the size of the stack pretty quickly and breaks assumptions about single-threaded concurrency). Any concurrency with hardware compositing is going to happen at the kernel or hardware levels, not in the app.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#92

Post by saurik » Tue, Dec 06, 2011, 6:55 AM UTC

babebridou wrote: post #70

As I said in the other thread, there are two patterns, one is a Delegate pattern (IOS) where draw method lookup per pixel coordinate is trivial, and the other is a listener pattern, where view layout, composition and superposition is trivial. One is easy 98% of the time and super hard 2% of the time (iOS) and the other is relatively slow all the time but with much more potential for cross-process interactions. In And…

What keeps you from having a translucent popup from App #1 appear on top of any sort of screen from App #2 is not iOS's rendering architecture: it is that you are not allowed to, as one application, do any sort of computation while another one is happening.

To be clear, we do this all of the time on jailbroken devices (where we have access to write apps with true multitasking, and can also just add code as required to SpringBoard itself, which is acting as the window manager): you just create a transparent UIView and put it in a new UIWindow; there are seriously no issues doing this.

In the end, every UIView is backed by a CoreSurfaceBuffer (I think "Core" got renamed to "IO" at some point, if you look this stuff up), which are managed by a kernel driver that allows processes to pass these buffers (which may be backed by video, not system, memory) to each other, and in the end they mostly composited (with alpha blending) in hardware.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#93

Post by pflanze » Tue, Dec 06, 2011, 7:03 AM UTC

beatle wrote: post #88

blinkingled wrote: post #87

Earlier quoted context omitted.

Huh? thread management they're required to trap into the kernel to acquire a mutex. Of course GC is handled by the VM. That's not the point here though - the point I thought you made was that the GC uses mutexes and they're required to trap into the kernel. (At least that's how it reads above) That's not the case on Linux. GC uses mutexes which are implemented as futexes[1] that stay in user space for most of the tim…

HeapWorker.c uses pthreads. doing a quick check on one of the functions dvmLockMutex (in Thread.h) uses pthread_mutex_lock. // Grab a plain mutex. INLINE void dvmLockMutex(pthread_mutex_t pMutex) { int cc __attribute__ ((__unused__)) = pthread_mutex_lock(pMutex); assert(cc == 0); } and here's pthread_mutex_lock. int pthread_mutex_lock(pthread_mutex_t mutex) { if (mutex->kind == PTHREAD_MUTEX_NORMAL) { if (atomic_exch…

Regarding the pthread_mutex_lock code you posted: I'd say this shows that in the non-contention case there is no kernel call involved, assuming the used mutexes are of kind PTHREAD_MUTEX_NORMAL; atomic_exchange is likely entirely in user space[1] and thus only if the mutex is already locked will pthread_mutex_lock reach "wait" (wait_event ?) which is probably the kernel call; i.e. those are futexes.

Although I don't understand how the memory management makes use of mutexes (once a (any?) thread realizes that the GC needs to be run, how does it wait until all threads have reached a safe point?), and I don't have time to check ATM.

[1] http://www.insomniacgames.com/tech/articles/0807/files/multi... mentions the pthread_mutex_lock and unlock code including an implementation of atomic_exchange

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#94

Post by beatle » Tue, Dec 06, 2011, 7:17 AM UTC

beatle wrote: post #88

blinkingled wrote: post #87

Earlier quoted context omitted.

Huh? thread management they're required to trap into the kernel to acquire a mutex. Of course GC is handled by the VM. That's not the point here though - the point I thought you made was that the GC uses mutexes and they're required to trap into the kernel. (At least that's how it reads above) That's not the case on Linux. GC uses mutexes which are implemented as futexes[1] that stay in user space for most of the tim…

HeapWorker.c uses pthreads. doing a quick check on one of the functions dvmLockMutex (in Thread.h) uses pthread_mutex_lock. // Grab a plain mutex. INLINE void dvmLockMutex(pthread_mutex_t pMutex) { int cc __attribute__ ((__unused__)) = pthread_mutex_lock(pMutex); assert(cc == 0); } and here's pthread_mutex_lock. int pthread_mutex_lock(pthread_mutex_t mutex) { if (mutex->kind == PTHREAD_MUTEX_NORMAL) { if (atomic_exch…

yeah pthreads is implemented using futex. I don't care about the implementation details. It doesn't matter since it's still lock-based (albeit more efficient due to fewer system calls). My original point is, threading is still lock-based. Replacing your lock-based code with queues eliminates many of the penalties associated with locks and also simplifies your remaining code. Instead of using a lock to protect a shared resource, you can instead create a queue to serialize the tasks that access that resource. Queues do not impose the same penalties as locks. For example, queueing a task does not require trapping into the kernel to acquire a mutex (or however mutex is implemented)

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#95

Post by exDM69 » Tue, Dec 06, 2011, 10:56 AM UTC

therockhead wrote: post #59

Hmm ... is this still an issue with dual core Android phones ? I have two Android phones, Galaxy S2 and Galaxy Nexus and both are as smooth as butter. Both feel faster than my first gen Ipad.

Yes.

A lot of Android's rendering takes place on the CPU and a lot of it is small batches of serial work that isn't very well suited for concurrent execution on multiple cores.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#96

Post by gnaffle » Tue, Dec 06, 2011, 10:56 AM UTC

sedev wrote: post #2

The takeaway for me is this: Android and iOS' creators made different tradeoffs in their UI programming. The iOS creators, overall, correctly predicted that a fast, smooth, responsive UI was something that users would care about enough that it was okay to pay a performance cost in other areas in order to make the UI as responsive as it is on iOS devices. Android's creators made a different tradeoff, and the UI on And…

I'm not so sure that the iOS creators predicted anything. They started off with OS X, which already had a smooth, responsive, GPU backed UI (Cocoa/Quartz Extreme). I don't think that they had to compromise on performance, but they did have to spend extra money on a GPU.

Likewise, a good low latency sound system with MIDI support was added to iOS not because Apple correctly predicted that smartphones and tablets would be popular for music production, but because those were features already present in OSX.

AFAIK, the Android designers started out making a Blackberry clone, and creating a similar software stack would have been a lot more work at a time when the competitors were all running 2D GUIs with no GPU acceleration or fancy animations.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#97

Post by jrockway » Tue, Dec 06, 2011, 12:00 PM UTC

beatle wrote: post #94

beatle wrote: post #88

Earlier quoted context omitted.

HeapWorker.c uses pthreads. doing a quick check on one of the functions dvmLockMutex (in Thread.h) uses pthread_mutex_lock. // Grab a plain mutex. INLINE void dvmLockMutex(pthread_mutex_t pMutex) { int cc __attribute__ ((__unused__)) = pthread_mutex_lock(pMutex); assert(cc == 0); } and here's pthread_mutex_lock. int pthread_mutex_lock(pthread_mutex_t mutex) { if (mutex->kind == PTHREAD_MUTEX_NORMAL) { if (atomic_exch…

yeah pthreads is implemented using futex. I don't care about the implementation details. It doesn't matter since it's still lock-based (albeit more efficient due to fewer system calls). My original point is, threading is still lock-based. Replacing your lock-based code with queues eliminates many of the penalties associated with locks and also simplifies your remaining code. Instead of using a lock to protect a share…

Acquiring a mutex on Linux involves reading an integer from memory.

Also, the way a queue prevents two consumers from popping off the same element is the same way a mutex is implemented.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#98

Post by jrockway » Tue, Dec 06, 2011, 12:27 PM UTC

pace wrote: post #28

Isn't Google's staff working under NDA? I love the open discussion about Android's weakest point and I appreciate opinions from all side, in particular those from inside Google -- but this uncoordinated communication on G+ addressing problems w/o delivering a solution damages Android's image to some extent.

It's an open source project. Google doesn't make any money from Android. It's just something they do for fun to advance their other business goals.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#99

Post by bad_user » Tue, Dec 06, 2011, 12:42 PM UTC

megablast wrote: post #84

bad_user wrote: post #56

Earlier quoted context omitted.

If that's because Android's interface is laggy, then why do people keep buying Androids? IMHO, iOS users spend more on apps because iTunes is better than Android's Marketplace - this may have been a deliberate decision by Google nonetheless. Did you know that I am not allowed to sell Android apps in the Marketplace because my country is still not approved for registering a Google Merchant account? That's right, it's…

People keep buying Android for lots of reasons, they can be a lot cheaper, they have more options (keyboards, big screens), they are pushed a lot by carriers, lots of carriers don't carry the iPhone. The interface problem with Android might come in to play when people are considering their second smartphone, and devices are a lot faster these days. Of course, no one should need a dual core or quad core CPU for a smoo…

That doesn't answer the question, which has a context: if people don't buy Android apps because the interface is laggy, then why do they keep buying Androids?

I have an iPhone 3GS and a Galaxy S which recently upgraded to Gingerbread. The iPhone experience is indeed more "smooth", however that doesn't bother me because the advantages that my Galaxy S gives me outweigh the smoothness of the iPhone.

As an example, on my Galaxy S I was free to install a calls / SMS blocker. You can blacklist certain numbers and then it's as if those numbers don't exist - not only it blocks the calls / messages, but it also removes all traces from the logs. Last time I checked these types of apps where banned from iTunes. On Android it isn't so cut and dry either, as these apps are using private APIs that aren't documented, however they are allowed on the Marketplace.

Another example would be the kickass integration my device has with my Google Apps account. For instance all my phone numbers are synchronized with Google Contacts. And don't get me wrong, I'm sure this is only a matter of preferences and I could probably do the same thing on the iPhone, however this works both ways and I'm having an easier time with my Android to do what I want.

The only annoyance I have with my Galaxy S is the slow upgrade cycle. It will probably take forever for Samsung to deliver to me an upgrade to Android 4. Which is why my next phone will be a Google Galaxy Nexus, or whatever blessed phone will come next after it.

Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy

#100

Post by msh » Tue, Dec 06, 2011, 12:43 PM UTC

hack_edu wrote: post #78

conr wrote: post #75

Earlier quoted context omitted.

iOS has the advantage that all apps go through an approval process. If someone is doing lots of work on the main thread and blocking the UI, the reviewer can catch it and suggest to the developer to make their code suck less.

Do people actually get any feedback like this?

Yes, i had an app that in one place didn't asynch a webrequest and locked up the main thread. They emailed me about this.