Generally we never want to lock a buffer for write access if it is at
the "head" on the surfaceflinger side. The only exception (1) is when
the buffer is not currently in use AND there is at least one queued
buffer -- in which case, SurfaceFlinger will never use said buffer
anymore, because on the next composition around, it will be able to
retire the first queued buffer.
The logic above relies on SurfaceFlinger always retiring
and locking a buffer before composition -- unfortunately this
didn't happen during a screenshot.
This could leave us in a situation where a buffer is locked by the
application for write, and used by SurfaceFlinger for texturing,
causing a hang.
Here, we fix this issue by never assuming the exception (1), it was
intended as an optimization allowing ANativeWindow::lockBuffer() to
return sooner and was justified when most of SF composition was
done in software. The actual buffer locking is now ensured by
gralloc. We could have handled screenshots in a similar way to
a regular composition, but it could have caused glitches on screen,
essentially, taking a screenshot could cause to skip a frame.
now that we removed the notion of a "inUse" buffer in surfaceflinger
a lot of code can be simplified / removed.
noteworthy, the whole concept of "unlockClient" wrt. "compositionComplete"
is also gone.
We used to guarantee that a layer in SurfaceFlinger would never be
destroyed before all references (to its ISurface) on the client
side would be released. At some point, this guarantee got
relaxed to allow to free gralloc resources sooner. This last
change was incorrect, because:
- in implementations with reference-counting the gralloc resources
wouldn't be released anyways, until all the mapping were gone
- in implementations without ref counting, the client side
would most likely crash or do something bad
- it also caused the SharedBufferStack slot to be reallocated
to another surface, which could be problematic if the client
continued to use the surface after the window manager destroyed it.
So, we essentially reinstate the guarantee that layers won't be
destroyed until after all references to their ISurface are
released.
NOTE: This doesn't entirely fix 3306150 because there is another
problem there where the Browser continues to use a surface after it
has been destroyed.
also improve SurfaceFlinger 'dumpsys' log
list the purgatory, which shows windows that have been closed,
but for which the client still has references.
we were not clearing the screen entirely, which caused garbage when
the screen wasn't entirely covered by windows.
Change-Id: Ia7aa13c36a8a314e0e8427d419b16b9aa2165ddf
we make sure to call compositionComplete after everytime we do
composition with the GPU (even for the screenshot case), which is
where the buffer locks are released.
Change-Id: I450430d1e4d1ee9ce1023970642378c42cdcfa4c
