summaryrefslogtreecommitdiff
path: root/libs/ui/FramebufferNativeWindow.cpp
diff options
context:
space:
mode:
author Mathias Agopian <mathias@google.com> 2011-01-18 15:51:30 -0800
committer Mathias Agopian <mathias@google.com> 2011-01-18 15:51:30 -0800
commited8a50c9c5bdefe4b347c6de12b8f6b947235164 (patch)
tree7f17abfbd0b95e54e4e38037f5f41dc387633b1d /libs/ui/FramebufferNativeWindow.cpp
parent2e73a0cc5270a59790e7c559408d23ccff89fd10 (diff)
fix [3361121] hang in glClear() - device unresponsive, OTA fails
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. Change-Id: I1f226b1ebdf6918439b687c2723955d55b842c55
Diffstat (limited to 'libs/ui/FramebufferNativeWindow.cpp')
0 files changed, 0 insertions, 0 deletions