1ffdccc46e
When turning the screen off we could have 2 waiters on the vsync condition: The main vsync waiter as well as one in onScreenReleased(). We were only signaling the condition though, so it it would be possible to wake onScreenReleased() without waking the main vsync thread which would then be stuck in .wait(). We fix this by just using broadcast() when receiving a vsync event. We also add a broadcast() to signal when the state of mUseSoftwareVSync changes. This is important particularly for the transition from hardware to software vsync because the main vsync waiter might have observed mUseSoftwareVSync == false and decided to block indefinitely pending a hardware vsync signal that will never arrive. Removed a potentially deadlocking wait for a signal in onScreenReleased(). The function was trying to wait for the last vsync event from the hardware to be delivered to clients but there was no guarantee that another thread would signal it to wake up again afterwards. (As far as I can tell, the only other other thread that might wake it up at this point would be a client application issuing a vsync request.) We don't really need to wait here anyhow. It's enough to set the mUseSoftwareVSync flag, wake up the thread loop and go. If there was a pending vsync timestamp from the hardware, then the thread loop will grab it and use it then start software vsync on the next iteration. Bug: 6672102 Change-Id: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e |
||
|---|---|---|
| build | ||
| cmds | ||
| data/etc | ||
| include | ||
| libs | ||
| opengl | ||
| services | ||
| MODULE_LICENSE_APACHE2 | ||
| NOTICE | ||