Surface flinger CPU usage close to %100 when touch on Dialer app

[wen yi]

Hello,

Noticed this while doing some general performance testing on an
Android based product. I kicked off LTTLite on the device in the
console and navigated to Dialer app. After touch around among the
button I collected the profile. It is a bit surprising to see that
SurfaceFlinger took 80 - 95% of the CPU cycle, of which 70% was spent
in system calls. Possibly as a results, a call from application into
hardware service took about 15 ms to complete.

My question was is this what expected from Android if there is no HW
assistance for surface rendering and composing?

Regards.

- Wen

[Dave Sparks]

There are optimizations in PixelFlinger for ARMv5. If you aren't using
the ARMv5 optimization, rendering is going to be pretty slow.

[David Turner]

On Fri, Jan 23, 2009 at 5:43 PM, Dave Sparks <david...@android.com> wrote:

There are optimizations in PixelFlinger for ARMv5. If you aren't using
the ARMv5 optimization, rendering is going to be pretty slow.

that's true, but that doesn't explain why so much CPU is spent in system calls.
it really depends on what the application is doing. If I remember correctly, the
framework sends touch events to the application's main thread as fast as the
latter can handle them.

if the main UI thread does nothing (e.g. all rendering is done in another thread),
then it can gobble up a lot of CPU for essentially nothing. Some game developers
had the problem of dropping frame rates recently that were caused by this. The
problem was caused by adding a small delay in the UI thread between reading
more events.

Of course, we don't know anything about the product or the application being run,
so all of this is pure conjecture.

[Dianne Hackborn]

The issue of spending lots of time processing events only happens if a separate thread is doing the drawing, which shouldn't be the case for the dialer.

One thought -- maybe the driver has a really inefficient implementation of page flipping?  Such as by doing a copy?

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support.  All such questions should be posted on public forums, where I and others can see and answer them.

[wen yi]

After talking with the display driver engineer, it turns out the
driver was setup in mode in which the framebuffer was copied in its
entirety. The problem has been corrected since.

Thanks a lot!

- Wen

On Jan 23, 11:55 pm, Dianne Hackborn <hack...@android.com> wrote:
> The issue of spending lots of time processing events only happens if a
> separate thread is doing the drawing, which shouldn't be the case for the
> dialer.
>
> One thought -- maybe the driver has a really inefficient implementation of
> page flipping?  Such as by doing a copy?
>
>
>
>
>
> On Fri, Jan 23, 2009 at 7:29 PM, David Turner <di...@android.com> wrote:
>

> > On Fri, Jan 23, 2009 at 5:43 PM, Dave Sparks <davidspa...@android.com>wrote:
>
> >> There are optimizations in PixelFlinger for ARMv5. If you aren't using
> >> the ARMv5 optimization, rendering is going to be pretty slow.
>
> > that's true, but that doesn't explain why so much CPU is spent in system
> > calls.
> > it really depends on what the application is doing. If I remember
> > correctly, the
> > framework sends touch events to the application's main thread as fast as
> > the
> > latter can handle them.
>
> > if the main UI thread does nothing (e.g. all rendering is done in another
> > thread),
> > then it can gobble up a lot of CPU for essentially nothing. Some game
> > developers
> > had the problem of dropping frame rates recently that were caused by this.
> > The
> > problem was caused by adding a small delay in the UI thread between reading
> > more events.
>
> > Of course, we don't know anything about the product or the application
> > being run,
> > so all of this is pure conjecture.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

>
> Note: please don't send private questions to me, as I don't have time to
> provide private support.  All such questions should be posted on public

> forums, where I and others can see and answer them.- Hide quoted text -
>
> - Show quoted text -