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 interface.

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).