Martin Gräßlin 93b5e13308 [hwcomposer] Rework the vsync code ... This changes how we synchronize through vsync. We use a mutex and a wait condition to synchronize the threads. When presenting the frame our main gui thread blocks and will be woken up by the vsync event (or a timeout of max 1 frame time slot). In order to minimize the blocked time we use the blocksForRetrace functionality from the GLX compositor. Given this change we no longer need to tell the compositor that we are swapping the frame, it's blocked anyway. Also we don't need the failsafe QTimer anymore. With this change applied on a Nexus 5 it's succeeding the "Martin tortures phone test". It doesn't tear anymore and has a smooth experience. I'm rather disappointed by the fact that we need to block in order to get vsync. This means Android/hwcomposer is as bad as GLX. So much for the "Android stack is so awesome", in fact it's not. Anybody thinking it's awesome should compare to DRM/KMS and especially atomic modesetting. Yes it's possible to present frames without tearing and without having to block the rendering thread. Reviewed-By: Marco Martin and Bhushan Shah		2015-10-20 13:16:05 +02:00
..
CMakeLists.txt	[backends/hwcomposer] Drop dependency on hybrissync library	2015-10-14 14:33:49 +02:00
egl_hwcomposer_backend.cpp	[hwcomposer] Rework the vsync code	2015-10-20 13:16:05 +02:00
egl_hwcomposer_backend.h
hwcomposer.json	SVN_SILENT made messages (.desktop file) - always resolve ours	2015-10-18 11:06:54 +00:00
hwcomposer_backend.cpp	[hwcomposer] Rework the vsync code	2015-10-20 13:16:05 +02:00
hwcomposer_backend.h	[hwcomposer] Rework the vsync code	2015-10-20 13:16:05 +02:00
logging.cpp
logging.h
screens_hwcomposer.cpp
screens_hwcomposer.h