title: Android triple buffering - expected behavior?
body: <p>I'm investigating the performance of my app since I noticed it dropping some frames while scrolling. I ran systrace (on a Nexus 4 running 4.3) and noticed an <a href="https://dl.dropbox.com/s/1zxdcfnjwhbtren/Screen%20Shot%202014-04-24%20at%205.22.26%20PM.png" rel="nofollow">interesting section</a> in the output.</p>
  
  <p>Everything is fine at first. <a href="https://dl.dropbox.com/s/p325seejs88z9lv/Screen%20Shot%202014-04-24%20at%205.23.23%20PM.png" rel="nofollow">Zooming in on the left section</a>, we can see that drawing starts on every vsync, finishes with time to spare, and waits until the next vsync. Since it's triple buffered, it should be drawing into a buffer that will be posted on the following vsync after it's done.</p>
  
  <p>On the 4th vsync in the zoomed in screenshot, the app does some work and the draw operation doesn't finish in time for the next vsync. However, we don't drop any frames because the previous draws were working a frame ahead.</p>
  
  <p>After this happens though, the draw operations don't make up for the missed vsync. Instead, only one draw operation starts per vsync, and now they're not drawing one frame ahead anymore.</p>
  
  <p><a href="https://dl.dropbox.com/s/5wsknj1r1ptiici/Screen%20Shot%202014-04-24%20at%205.23.57%20PM.png" rel="nofollow">Zooming in on the right section</a>, the app does some more work and misses another vsync. Since we weren't drawing a frame ahead, a frame actually gets dropped here. After this, it goes back to drawing one frame ahead.</p>
  
  <p>Is this expected behavior? My understanding was that triple buffering allowed you to recover if you missed a vsync, but this behavior looks like it drops a frame once every two vsyncs you miss.</p>
  
  <hr>
  
  <p>Follow up questions</p>
  
  <ol>
  <li><p>On the right side of <a href="https://dl.dropboxusercontent.com/s/4z7cikapzjsp7pb/systrace_annotated.png" rel="nofollow">this screenshot</a>, the app is actually rendering buffers faster than the display is consuming them. During performTraversals #1 (labeled in the screenshot), let's say buffer A is being displayed and buffer B is being rendered. #1 finishes long before the vsync and puts buffer B in the queue. At this point, shouldn't the app be able to immediately start rendering buffer C? Instead, performTraversals #2 doesn't start until the next vsync, wasting the precious time in between.</p></li>
  <li><p>In a similar vein, I'm a bit confused about the need for waitForever <a href="https://dl.dropboxusercontent.com/s/p325seejs88z9lv/Screen%20Shot%202014-04-24%20at%205.23.23%20PM.png" rel="nofollow">on the left side here</a>. Let's say buffer A is being displayed, buffer B is in the queue, and buffer C is being rendered. When buffer C is finished rendering, why isn't it immediately added to the queue? Instead it does a waitForever until buffer B is removed from the queue, at which point it adds buffer C, which is why the queue seems to always stay at size 1 no matter how fast the app is rendering buffers.</p></li>
  </ol>