Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

plus.google.com

Post reply on HN
Print view View original

81–90 of 118 posts

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

#81

Post by aaronblohowiak »

billjings wrote: post #72
code_duck wrote: post #18

I'd be interested to learn what the deal is with sound on Android. I'm a musician and love the software instruments on the iPhone/iPod touch... they're a joy to play. On my relatively modern Android phone (Motorola Droid 2), instruments are so laggy they are absolutely unplayable. A key press results in a sound up to half a second later, sometimes never. The response improved slightly with the upgrade to Gingerbread,…

Android is all around inhospitable to music apps. The link in a sibling post here is just part of the problem - as far as I can tell, Android has no libraries that are useful for serious A/V work. On iOS, in the span of a short morning I can hook up a button or slider to send out MIDI messages over WiFi to my MBP and route it to any device I want; I have no idea how to get the equivalent setup on Android. What if I w…

IIRC, you can use OpenSL (which is somewhat like OpenAL) on Android, and that "should" provide you with a lower latency audio feed, but you're right that it isn't anywhere as nice as specifying your PCM format of choice and passing in your block reference to the audio component like you get on iOS.

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

#82

Post by usaar333 »

pragmatic wrote: post #76

Can someone explain what is "laggy" about android? I have a Droid bionic (second Android phone) and a Kindle Fire. What lag should I be suffering?

Can't speak for the bionic, but on a Kindle if you scroll in a webpage, you will notice a very low framerate. It is far less smooth than on, say, an iPad.

Other lag is also present in the initial part of scrolling. Android takes a bit longer than iOS to respond to your fingers' movements. Its on the order of milliseconds, but it is noticeable if you compare it to an iOS device.

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

#83

Post by campnic »

conr wrote: post #75
saurik wrote: post #50

Earlier quoted context omitted.

Yet on iOS, if you do silly work in the main/UI thread (which is very easy to do, as that really is your main thread on which you handle all events, and is thereby something many/most applications you find actually do quite often), it will block all UI updates for that process; claiming that iOS is solving UI lag by having a dedicated UI thread that is marked "real-time priority" is, AFAIK, wrong. In fact, it is this…

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.

If we are going to give an advantage I think it would go to Android if thats the only way you get feedback on iOS. Android pops up an Application Not Responsive message if your main thread violates responsiveness thresholds. This is a meta issue to mechanisms for debugging main thread vs. side thread coding.

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

#84

Post by megablast »

bad_user wrote: post #56
reidmain wrote: post #49

Earlier quoted context omitted.

"Proven itself" can mean that iOS grosses more than Android. Last I checked iOS users spend more on apps/services than their Android counterparts.

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 smooth experience on their phone.

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

#85

Post by seanp2k2 »

podperson wrote: post #63
saurik wrote: post #10

"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" """On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. T…

Right -- the first thing I did after reading a few paragraphs was load a complex web page and try scrolling it -- it continues to render just fine (on a single core iPhone 4). I've got a very old iPod Touch which does seem to lock up page draw when I scroll. I think that the simple answer is that there's no simple answer -- which is what the earlier post was pretty much saying.

There is a simple answer, but it's not one that most people who are in a position to fix it will like; "it sucks now and I couldn't care less why. Fix it ASAP because it's killing your UX"

And as far as the author of this article goes…maybe he is off on the technical stuff, but he understands the most important, which is that UX is broken in Android for this, among a few other reasons.

Someone open a big report against AOSP? All versions, high priority; "UI Anmations Broken"

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

#86

Post by beatle »

blinkingled wrote: post #79
beatle wrote: post #71

Earlier quoted context omitted.

Here's another problem with HeapWorker.c (The android code that does garbage collection, etc.). This is just poor programming imo. Android's thread management is stuck in the 90s. With this type of thread management they're required to trap into the kernel to acquire a mutex. There are obviously severe performance issues with this which partly explains some of the blocking and performance issues in Androids garbage c…

With this type of thread management they're required to trap into the kernel to acquire a mutex. There are obviously severe performance issues with this which partly explains some of the blocking and performance issues in Androids garbage collector Android runs on Linux. Linux uses Futexes (Fast Userspace Mutexes) for locking abstractions like semaphores and mutexes. From Wikipedia - "A futex consists of a kernelspac…

Android's garbage collection is handled by Dalvik.

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

#87

Post by blinkingled »

beatle wrote: post #86
blinkingled wrote: post #79

Earlier quoted context omitted.

With this type of thread management they're required to trap into the kernel to acquire a mutex. There are obviously severe performance issues with this which partly explains some of the blocking and performance issues in Androids garbage collector Android runs on Linux. Linux uses Futexes (Fast Userspace Mutexes) for locking abstractions like semaphores and mutexes. From Wikipedia - "A futex consists of a kernelspac…

Android's garbage collection is handled by Dalvik.

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 time.

[1] http://www.mail-archive.com/uclibc@uclibc.org/msg02787.html

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

#88

Post by beatle »

blinkingled wrote: post #87
beatle wrote: post #86

Earlier quoted context omitted.

Android's garbage collection is handled by Dalvik.

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_exchange(&mutex->lock, 1) != 0) { while (atomic_exchange(&mutex->lock, -1) != 0) {

        if (wait(mutex->event, INFINITE) != 0) return EINVAL;

      }

    }

  }
  else

  {

    pthread_t self = pthread_self();

    if (atomic_exchange(&mutex->lock, 1) == 0)
    {
      mutex->recursion = 1;

      mutex->owner = self;

    }

    else

    {

      if (pthread_equal(mutex->owner, self))

      {
        if (mutex->kind == PTHREAD_MUTEX_RECURSIVE)
          mutex->recursion++;
        else
          return EDEADLK;
      }
      else
      {
        while (atomic_exchange(&mutex->lock, -1) != 0)
        {
          if (wait(mutex->event, INFINITE) != 0) return EINVAL;
          mutex->recursion = 1;
          mutex->owner = self;
        }
      }
    }
  }

  return 0;
}

and here's an excerpt of dalvik/vm/Thread.c

Notes on Threading

All threads are native pthreads. All threads, except the JDWP debugger thread, are visible to code running in the VM and to the debugger. (We don't want the debugger to try to manipulate the thread that listens for instructions from the debugger.) Internal VM threads are in the "system" ThreadGroup, all others are in the "main" ThreadGroup, per convention.

The GC only runs when all threads have been suspended.

...

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

#89

Post by freemarketteddy »

saurik wrote: post #80
buymorechuck wrote: post #77

Earlier quoted context omitted.

On iOS, updates to the UI happen on the main thread, but all animation, surface compositing, and rendered graphics run on the dedicated Core Animation rendering thread.

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.

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

#90

Post by saurik »

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…

It is somewhat difficult to read this code (due to the formatting), but this seems like a futex to me: if the lock is not being contended, the atomic_exchange() will take the lock without entering kernel space. If you want to argue with blinkingled, you should look at whether this specific lock is under contention or not, not paste large blocks of code that just demonstrate and prove his argument. ;P
Post reply on HN