D-VSync: Decoupled Rendering and Displaying for Smartphone Graphics

A phone's screen refreshes on a strict clock, and every frame of the interface must be drawn before the next tick or it gets dropped, causing the stutters you feel when scrolling a heavy page — even though most frames finish with time to spare and only a rare few are too heavy to make the deadline; this work from Shanghai Jiao Tong University and Huawei rebuilds the rendering system to unhook drawing from the screen's clock, drawing predictable frames early using the slack the easy frames leave behind, cutting dropped frames by 73 percent, and it now ships in HarmonyOS.

The argument in one glance

Problem

A rigid screen clock drops the rare heavy frame

Smartphones draw the interface in lockstep with the screen refresh (VSync): every frame must finish before the next fixed signal or the old frame is shown again — a stutter. Screens have grown larger and faster and effects heavier, so occasional key frames cannot finish in time. The core conflict is a fixed display period versus a fluctuating rendering workload.
What people did

Add more buffers (triple buffering)

Use triple buffering so that when a frame misses its deadline, the next rendered frames can queue in an extra buffer slot rather than being lost outright.
Why it fell short

Buffering trades drops for latency

When a frame drops, subsequent frames get stuffed into the extra buffer and wait an additional refresh period, so end-to-end rendering latency climbs (measured at 24 to 46 milliseconds), well above the roughly 15 milliseconds at which people start to notice lag. Buffering hides drops but delays what the user sees.
This paper's idea

Decouple rendering from the display clock (D-VSync)

D-VSync breaks the tight coupling between rendering execution and the periodic VSync signal, letting a frame be rendered several VSync periods before it is displayed. Its insight is that the many short frames leave idle time that the rare long frames can borrow, giving a larger window to absorb workload spikes. A Frame Pre-Executor renders deterministic frames early, and a Display Time Virtualizer gives them the correct future timestamp. It cuts frame drops by 72.7 percent, stutters by 72.3 percent, and latency by 31.1 percent, and ships in HarmonyOS NEXT.

Why this problem is worth solving

Smooth scrolling and animation are a core part of how a phone feels, and the decade-old architecture behind them is buckling.

Smartphones draw their interface in synchrony with the screen using Vertical Synchronization, or VSync, an architecture that dates to Google’s Project Butter in 2012 and is used by Android, iOS, and OpenHarmony. The screen refreshes at a fixed rate — 60 or 120 times a second — and just before each physical refresh it emits a hardware VSync signal, every fixed period (16.7 milliseconds at 60 Hz, 8.3 milliseconds at 120 Hz). That signal drives the whole rendering pipeline: the app runs its logic, the frame is rendered, composited, and finally displayed, all paced by VSync. The rule is strict: a frame must be completely rendered before the next VSync deadline. If it is not, the screen has nothing new to show and simply keeps displaying the previous frame for another period — a dropped frame, or jank, which the user perceives as a stutter. Displaying content only at VSync boundaries also avoids screen tearing, where a mismatched swap would show pieces of two frames at once. To soften the impact of an occasional slow frame, systems use triple buffering, keeping extra frame buffers so rendering can work ahead — but the fundamental deadline remains.

The architecture is failing now because the workload has changed shape while the clock has not.

Two trends have overwhelmed VSync. First, screens have become far larger, sharper, and faster — a modern phone renders on the order of 25 times more pixels per second than an early smartphone. Second, applications now lean on expensive visual effects and physics-based animations — Gaussian blur, dynamic shadows, particle effects — that concentrate heavy work on particular key frames. The authors’ measurements make the pattern concrete: frame rendering times follow a power-law distribution. The large majority of frames, at least 95 percent, are short and finish comfortably within a single VSync period, but a small minority, under 5 percent, are heavy key frames that cannot finish in time. Those rare heavy frames are what cause the trouble: on a state-of-the-art 120 Hz phone, common actions like clearing notifications reached only 95 to 105 frames per second instead of 120, producing visible stutters, and measured end-to-end rendering latency ran from 24 to 46 milliseconds across devices — well above the roughly 15 milliseconds at which the human eye begins to notice lag. The root cause is a structural mismatch: the display refreshes on an always-fixed period, while the rendering workload fluctuates between many short frames and a few long ones. Forcing that fluctuating work onto a rigid clock is what makes the heavy frames drop.

What people did before, and where it broke

Render each frame strictly within its VSync period. Keep rendering locked to the screen’s clock, finishing every frame before the next signal. Where it broke. Heavy key frames cannot finish within a fixed period, so under a rigid deadline they inevitably drop, causing stutters.
Add triple buffering. Keep extra buffers so a late frame does not immediately cause a gap. Where it broke. When a frame drops, later frames get stuffed into the extra buffer and wait an additional period, so rendering latency climbs above the threshold where users notice lag.
Wait for faster silicon. Rely on hardware improvements to render the heavy frames in time. Where it broke. The growth in pixels and effect complexity far outpaces silicon advances, so the gap widens rather than closes.
The gap. No approach relaxed the rigid coupling between rendering and the fixed display clock so that the slack from short frames could absorb the rare long ones. Doing exactly that is what D-VSync contributes.

How D-VSync works

From rendering locked to the screen clock to rendering decoupled and ahead

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Unhook rendering from the fixed display clock. D-VSync’s central move is to stop forcing every frame to finish within its own VSync period and instead let rendering run ahead, so a frame can be produced several periods before it is displayed and a heavy frame is no longer trapped against a rigid deadline. Breaking a tight coupling between two things that were locked together — here, the timing of rendering and the timing of display — so that a burst of work is no longer bound to a fixed schedule, is the same move the LLM-serving work covered elsewhere on this site makes, decoupling one resource from the rigid allocation of another so that spikes can be absorbed instead of causing stalls.

Spend the slack that easy frames leave on the hard ones. The power law is the key: because at least 95 percent of frames finish quickly and leave the processor idle before the next refresh, that idle time is normally wasted, and D-VSync instead uses it to render upcoming frames early, so the rare heavy frame has effectively already been given extra time. Taking capacity that is sitting idle in one place and directing it to the work that actually needs it, rather than letting it go to waste, is the same harvesting the idle-flash-bandwidth storage work covered elsewhere on this site performs, reclaiming a resource that some requests are not using so that the requests that are starved for it can proceed.

Render ahead correctly by virtualizing the future. Rendering early only works if the frame is still correct, and an animation must sample its motion for the moment the frame will actually be shown, not the moment it is computed — so D-VSync’s Display Time Virtualizer presents each early-rendered frame with its true future display time, letting apps and the framework compute exactly the right content in advance. Adding a precise mechanism that preserves correctness when an operation is performed opportunistically ahead of its normal point, rather than letting the early execution produce a subtly wrong result, is the same care the copy-on-write pinning work covered elsewhere on this site takes, introducing an exact rule so that an optimization done out of its usual order still yields the correct outcome every time.

Following a heavy key frame through D-VSync

Absorbing a heavy animation frame without a drop

A trace of D-VSync handling a bursty key frame, following the paper's Frame Pre-Executor and Display Time Virtualizer.

Step 1 of 5

A smooth animation, mostly cheap frames

An animation is playing. Most of its frames are cheap and finish well within their VSync period, leaving CPU time idle before the next screen refresh.

This is the common case — the short side of the power law.

Why it works

Frame work is bursty, but the deadline is rigid. Because a few heavy key frames cannot finish within a fixed VSync period while most frames finish early → forcing every frame onto the same fixed deadline guarantees the heavy ones drop → so relaxing that rigid coupling is the key to smoothness.
Short frames leave slack that long frames could use. Because at least 95 percent of frames finish quickly and leave the processor idle before the next refresh → that idle time is wasted under strict VSync → so letting long frames borrow it gives a larger window to complete.
Deterministic work can be done ahead safely. Because animations and simple interactions are predictable → their frames can be rendered before their VSync signal without guessing wrong → so pre-execution is both feasible and correct in exactly the common smooth-scrolling cases.
Rendering ahead needs the right sense of time. Because an animation must sample its motion for the moment the frame is displayed, not when it is computed → virtualizing the future display time lets an early-rendered frame use the correct timestamp → so decoupling does not corrupt the content.
The cost is tiny next to the benefit. Because pre-executing frames uses otherwise-idle CPU time → it adds only a fraction of a percent to power while cutting frame drops and latency sharply → so the trade strongly favors the user experience.

What it costs (trade-offs and scope)

Pre-rendering is limited to predictable scenarios. The Frame Pre-Executor renders ahead only when it can determine that pre-rendering is feasible — during deterministic animations and simple interactions. Highly unpredictable input cannot simply be rendered ahead, so an input-prediction extension is needed to widen coverage, and unpredictable cases benefit less.
Correctness across decoupling is non-trivial. Rendering a frame before its display time means some inputs may not yet be final, and animations must be sampled for the future moment. The Display Time Virtualizer exists precisely because naive early rendering would produce wrong content; getting this right is essential and adds design complexity.
It changes the rendering architecture. D-VSync replaces the timing, pacing, pre-rendering limit, and buffer management that VSync handled implicitly with explicit control, and it needs new decoupling interfaces for apps — including custom-rendering apps like games and browsers that bypass the OS framework. This is a substantial system change, not a drop-in tweak.
Slight extra power and resource use. Pre-executing frames consumes CPU time that would otherwise be idle, adding a measured 0.13 to 0.37 percent more power. This is small, but it is not free, and aggressive pre-rendering could use more.
The benefit depends on there being slack to borrow. D-VSync works because short frames leave idle time. A workload that is uniformly heavy, with little idle time between frames, offers less slack for long frames to borrow, so the gains would be smaller.
Results are tied to the tested platforms. The improvements are measured on specific OpenHarmony and Android devices and workloads; the numbers reflect those cases, though integration into a shipping OS is strong evidence of general benefit.

The evaluation

Three approaches to smartphone frame rendering

Property	VSync	VSync + triple buffering	D-VSync
Absorbs rare heavy key frames
Rendering tied to the display clock
Rendering latency	High on drops		31.1 percent lower
Correct animation timing when ahead	Not applicable	Not applicable
Result	Frame drops and stutters	Fewer gaps, more latency	72.7 percent fewer drops, 72.3 percent fewer stutters

Three approaches to smartphone frame rendering, as evaluated in the paper. Strict VSync forces every frame to finish within a fixed period, so the rare heavy key frame drops. Triple buffering softens dropped frames but, by stuffing later frames into an extra buffer, raises end-to-end latency (measured at 24 to 46 milliseconds, above the roughly 15-millisecond threshold where people notice lag). D-VSync decouples rendering from the display clock: because frame times follow a power law where most frames are short and finish early, its Frame Pre-Executor renders deterministic frames ahead of time using the idle slack, and its Display Time Virtualizer gives each early frame the correct future timestamp so its content stays right. Across 75 OpenHarmony use cases (Mate 40 Pro, Mate 60 Pro), 25 Android apps (Google Pixel 5), and simulations of 15 mobile games, D-VSync reduces frame drops by 72.7 percent, user-perceptible stutters by 72.3 percent, and rendering latency by 31.1 percent, with only 0.13 to 0.37 percent more power. It has been integrated into HarmonyOS NEXT.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

D-VSync is a clean, well-motivated systems contribution to something every phone user feels: the little stutters when scrolling a heavy page or triggering a fancy animation. Its diagnosis is precise and backed by real measurements — frame rendering times follow a power law, where the vast majority of frames are short and finish early but a rare few heavy key frames cannot meet the fixed VSync deadline, and the structural culprit is the mismatch between a rigid display clock and a fluctuating rendering workload. The fix is elegant: decouple rendering from the display, render predictable frames ahead of time using the idle slack that short frames leave, and use a Display Time Virtualizer to keep early-rendered content correct by giving it its true future display time. The engineering is thorough, handling deterministic animations, custom-rendering apps like games and browsers, and unpredictable input via a prediction layer. The results are strong and, importantly, validated in production: a 72.7 percent reduction in frame drops, 72.3 percent fewer perceptible stutters, and 31.1 percent lower rendering latency for only a fraction of a percent more power, across dozens of real use cases and apps on OpenHarmony and Android — and it now ships in HarmonyOS NEXT, which is unusually strong evidence for an academic paper. Read the scope precisely. Pre-rendering only helps where the future is predictable, so unpredictable interaction benefits less and relies on input prediction; the decoupling requires careful correctness machinery and a real change to the rendering architecture with new app interfaces; the power cost, while tiny, is nonzero; and the benefit depends on there being idle slack to borrow, which a uniformly heavy workload would not provide. The durable idea is that when a fluctuating workload is forced onto a rigid clock, the fix is to relax the coupling and let the easy common case create a time buffer for the hard rare case.

Background

Why decoupling a rigid schedule to absorb bursts keeps recurring

It helps to see D-VSync within a broad and durable pattern: many performance problems come from forcing a bursty, uneven workload to meet a single rigid deadline or schedule, and the fix is to relax that coupling so the slack of the common cheap case can cover the rare expensive one. Here the rigid thing is the screen’s fixed refresh clock and the uneven thing is the mix of short and long frames. The secure-undervolting work covered elsewhere on this site rests on the same power-law shape from a different domain, observing that only a rare few operations need the worst-case margin while the overwhelming majority are cheap, and then handling that rare minority specially so the common case can run leaner. The common thread is the skew: workloads are rarely uniform, and a design that plans for the worst case everywhere, or forces everything onto one fixed timing, wastes the headroom the easy majority leaves behind. Systems perform far better when they recognize the split between the cheap common case and the costly rare one and arrange for the former to subsidize the latter — by pre-computing ahead, by borrowing idle time, or by reserving special handling only where it is truly needed. As screens, models, and effects keep growing faster than the hardware beneath them, this instinct — decouple the rigid from the fluctuating, and let the common case buy time for the exception — is likely to matter more, not less.

If you remember only three things

1. Smartphones render their interface in lockstep with the screen refresh using Vertical Synchronization (VSync): the screen signals every fixed period (16.7 milliseconds at 60 Hz, 8.3 at 120 Hz), and each frame must finish rendering before the next signal or the old frame is shown again — a dropped frame, felt as a stutter. Screens have grown roughly 25 times larger in pixels-per-second and effects heavier (blur, shadows, physics animations), concentrating work on occasional key frames. Frame rendering times follow a power law: at least 95 percent of frames are short and finish early, but under 5 percent are heavy key frames that miss the fixed deadline. The structural conflict is a rigid display clock versus a fluctuating workload; triple buffering hides drops but raises latency (measured at 24 to 46 milliseconds, above the roughly 15-millisecond threshold people notice).
2. D-VSync decouples rendering execution from the periodic VSync signal, allowing a frame to be rendered several VSync periods before it is displayed. Its key insight is that the idle time left by the many short frames can be borrowed by the rare long frames, giving a larger window to absorb spikes. A Frame Pre-Executor renders frames ahead of the screen's signal when pre-rendering is safe (deterministic animations, simple interactions), using that idle CPU time; a Display Time Virtualizer gives each early-rendered frame its correct future display time so animations sample the right moment and content stays correct; dual-channel decoupling interfaces extend it to custom-rendering apps like games and browsers, and an input-prediction layer widens coverage to less predictable interactions.
3. Across 75 OpenHarmony use cases (Mate 40 Pro, Mate 60 Pro), 25 Android apps (Google Pixel 5), and simulations of 15 mobile games, D-VSync reduces frame drops by 72.7 percent, user-perceptible stutters by 72.3 percent, and rendering latency by 31.1 percent, with only 0.13 to 0.37 percent more power — and it has been integrated into HarmonyOS NEXT, unusually strong evidence of practicality. Scope: pre-rendering only helps where the future is predictable, correctness across decoupling needs careful machinery (the Display Time Virtualizer), it changes the rendering architecture and needs new app interfaces, the power cost is small but nonzero, and the benefit depends on there being idle slack to borrow. The durable lesson is that when a fluctuating workload is forced onto a rigid clock, the fix is to relax the coupling and let the easy common case create a time buffer for the hard rare case.

Check yourself

Check your understanding

1. Under the VSync architecture, why does a frame get dropped?
2. What is the power-law observation at the heart of D-VSync?
3. How does D-VSync use the idle time left by short frames, and how does it stay correct?
4. What do D-VSync's results and deployment tell us?

Sources

The paper is “D-VSync: Decoupled Rendering and Displaying for Smartphone Graphics” by Yuanpei Wu, Dong Du, Chao Xu, Yubin Xia, Ming Fu, Binyu Zang, and Haibo Chen, published at ASPLOS 2025, DOI 10.1145/3669940.3707235. The authors are at the Institute of Parallel and Distributed Systems (IPADS), Shanghai Jiao Tong University, and Huawei.

This explainer is based on the full text of the paper, obtained as the open-access author copy hosted by the authors’ research group. The problem framing (the VSync rendering architecture with triple buffering from Project Butter; the fixed screen refresh and VSync deadline; frame drops and screen tearing; the growth in pixels and effect complexity; and the measured frame drops, per-second frame-drop rates, frames-per-second shortfalls, and 24-to-46-millisecond rendering latencies against a roughly 15-millisecond just-noticeable-difference threshold), the central observation (the power-law distribution of frame rendering times, with at least 95 percent short frames and under 5 percent heavy key frames, and the structural conflict between a fixed display period and a fluctuating workload), the D-VSync design (decoupling rendering execution from the periodic VSync signal to render frames ahead; the Frame Pre-Executor and its decoupled signal for deterministic scenarios; the Display Time Virtualizer that virtualizes the future display time for correctness; the dual-channel decoupling interfaces for custom-rendering apps; and the input-prediction extension), and the evaluation results (across 75 OpenHarmony use cases on Mate 40 Pro and Mate 60 Pro, 25 Android apps on Google Pixel 5, and simulations of 15 mobile games, an average 72.7 percent reduction in frame drops, 72.3 percent reduction in user-perceptible stutters, and 31.1 percent reduction in rendering latency, with a 0.13 to 0.37 percent increase in power consumption, and integration into HarmonyOS NEXT) are all drawn directly from the paper. Background explanations of frame buffers, buffer queues, refresh rates, and rendering pipelines are standard and provided to make the paper’s contribution understandable.