androidgraphicsdouble-bufferingsystrace

Double buffering slows frame rendering | systrace analysis

Im working at a simple 2D Game with Custom View canvas drawing (postInvalidate()) and HardwareAcceleration. After weeks of performance analysis i decided to sync my update and drawing operations with the VSYNC pulse over the Interface Choreographer.FrameCallback. Im thinking thats the right way to get smooth movements.

However im still experiencing choppy movements. I analyzed it with systrace and noticed that is has something to do with my BufferQueue. As soon as double buffering sets in, the frame time exceeds the 16ms. I made a screenshot of my trace with some explanations:

The whole draw operation waits for the buffer release of the SurfaceFlinger (consumer) to dequeue its own new empty Buffer.

Can you tell me if this is a regular behavior or what could be the reason for this?

Solution

  • On your graph, you have a note, "SurfaceFlinger misses VSYNC".

    However, if you look at the BufferQueue row, you can see that the buffer arrived after the VSYNC deadline. SurfaceFlinger woke up, but there was nothing to do.

    Your app then provided an additional buffer, which meant you had two buffers pending. Since you continued to provide a buffer on every VSYNC, the queue never got back down to zero buffers. With the queue stuffed full, every attempt to add additional buffers results in blocking.

    FWIW, your BufferQueue is triple-buffered: two are in the queue, one is on the display.

    There are a few things you can do:

    1. Have the app drop frames if you've missed the deadline.
    2. Specify a presentation time for the frames so SurfaceFlinger will drop them if the time is passed.
    3. Deliberately drop a frame every once in a while to let the queue empty. (Not the preferred approach.)

    #2 only works with GLES on a SurfaceView, so we can ignore that one.

    #1 might work for you; you can see an example in Grafika. It essentially says, "if the next VSYNC is firing in less than 2ms, or has already fired, don't bother rendering the current frame." The View/invalidate approach doesn't give you the same fine-grained control that GLES does though, so I'm not sure how well that will work.

    The key to smooth animation on a busy device isn't hitting every frame at 60fps. The key is to make your updates based on delta time, so things look smooth even if you drop a frame or two.

    For additional details on the graphics architecture, see this doc.