F7.12.3Degrade motion on low-end devicesdesign

On low-end devices, complex motion should degrade or stop, not scale uniformly

Aliases: low-end degrade · not just shorter · capability fallback

What it is

On a low-end phone, cutting a 400 ms blur-scale to 200 ms leaves work per frame almost unchanged; dropped frames only pack denser. What has to fall is effect complexity, not the same curve squeezed shorter. Uniformly scaling duration is paying a perceptual ledger against a performance one: shorter is still heavy, and heavy strain is more obvious. Low-end needs blur, shadows and layout animation turned off, or the clip not played.

Why it happens

Cost per frame is fill, layer upload and layout extent, not the designed duration. Halve the duration and you halve the frame count; a single frame may still blow the budget. Worse, the same work is packed into fewer vsyncs, so the tail densifies. Blur and large-radius shadows are fill-rate killers, an order of magnitude dearer than translation on a weak GPU. On a weak CPU, animation that touches layout also fights input and list recycling on the main thread.

Capability degrade is a cheaper path: transform instead of layout, solid colour instead of blur, fade instead of scale, a cut instead of anything. The test is whether this device can hold the frame budget, not screen size — a small flagship can be strong; a large entry-level tablet is often weaker.

Where it stops holding

  • When the user has reduced motion on, take that branch; do not also keep a performance-degraded translation. Two leftover translations will fight.
  • “Low-end” has to be binned by measured frame time, not by OS year alone.
  • After degrade, critical states must remain perceptible, or performance safety becomes change blindness.

Applying it

  • Give complex motion three rungs — off / simplified / full — chosen from runtime frame time or device class, biased toward the lower rung.
  • Do not treat high-end duration times a coefficient as the low-end design.
  • Check: on an entry-level device, compare full versus degraded. If full stutters and degraded is stable, keep the degrade; if degraded is only a faster stutter, complexity was not actually reduced.

Related

  • Same group: F7.12.1 Motion work can contend for the main thread and cause jank · F7.12.2 Dropped frames hurt more than no motion because they expose strain · F7.12.4 Simultaneous motions stack cost beyond a single-motion budget
  • Nearby: R3.16 Low-end devices and degrade strategy · R3.08.3 Animation must degrade with device capability · F7.08.2 Reduced is not off; a fade can replace travel
  • Search terms: low-end degrade · frame budget · fill rate

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/F7.12.3