UNDERSTANDING ANDROID GRAPHICS INTERNALS – SURFACEFLINGER (II)
Prior to Jelly Bean, the threadLoop in SurfaceFlinger.cpp processes composition
and rendering sequentially in a thread loop. Newly enqueued graphic buffer won’t be handled until the rendering of current frame buffer is complete. As a result, animation shown on display may appear jumpy or tearing in rendering. To address this issue, Android
introduces vsync event into SurfaceFlinger.
In android, a vsync event relates to timestamp. For each display device, android assigns a DisplayEventReceiver::Event ( defined in framework/native/include/gui/DisplayEventReceiver.h) structure, i.e. mVSyncEvent. mVSyncEvent.header.timestamp. Even though
the timestamp value is refreshed with system time, the significance is whether it is non-zero. If it is nonzero, SurfaceFlinger will trigger either a refresh action or an invalidate action on the corresponding display and reset timestamp to zero.
vsync events can be generated from several sources.
Periodical vsync event sources
If hwcomposer module is present, it will be generated either from the vsync signal emitted from the frame buffer device driver; or faked from the hwcomposer module.
If the hwcomposer module is not present, the VSyncThread will generate it.
Spontaneous vsync event sources
A UI view may instantiate DisplayEventReceiver and thus obtain an IDisplayEventConnection interface through createDisplayEventConnection() call. Whenever the view has a graphic buffer to update, it may sound a requestNextVsync() call on the IDisplayEventConnection
To establish concurrency between composition and rendering, SurfaceFlinger in Jelly Bean made two major changes in threading model and asynchrocy, adding a new EventThread thread to handle DisplayEventReceiver::Event events, adopted a Looper/Handler/MessageQueue
paradigm in SurfaceFlinger main thread. As a side note, the EventThread also handles display hotplug event ( hwcomposer module may listen on uevent).