Skip to content

SYSTEM Cited by 1 source

Pinterest PerfView interfaces

Definition

PerfImageView / PerfTextView / PerfVideoView are three opt-in marker interfaces in Pinterest's Android client. Product engineers implement them on the specific image / text / video views that participate in a surface's Visually Complete definition; the BaseSurface iterates the view tree and inspects any Perf* instance to compute a per-surface User Perceived Latency timestamp (Source: sources/2026-04-08-pinterest-performance-for-everyone).

Interface shape

"Each of them contains a few methods to report their rendering status: isDrawn(), isVideoLoadStarted(), x(), y(), height(), width(), etc." (Source: sources/2026-04-08-pinterest-performance-for-everyone).

  • PerfImageView — exposes isDrawn() plus geometry for visibility checks. Reports ready once the image has rendered.
  • PerfTextView — exposes isDrawn() plus geometry. Reports ready once the text has rendered.
  • PerfVideoView — exposes isVideoLoadStarted() plus geometry. Reports ready once video playback has begun (not on full download — the Visually Complete definition for video surfaces is "the full-screen video starts playing").

The geometry methods (x(), y(), width(), height()) are used by BaseSurface to filter to visible views during the tree walk — off-screen-but-in-tree views don't block Visually Complete.

Role in the Visually Complete pipeline

PerfView interfaces are the opt-in contract between product code and the platform:

  • Platform side (BaseSurface): walks the view tree, inspects interface instances, emits the timestamp.
  • Product side: the engineer's only responsibility is to have their ImageView / TextView / VideoView implement the right Perf* interface, so the platform counts it toward Visually Complete.

This is a canonical opt-in performance interface pattern — marker interface semantics repurposed as a product-engineer declaration that a view is perf-critical. The opt-in (rather than auto-detect-every-ImageView) is a deliberate design choice: not every view matters for the user-perceived done-state, and auto-inclusion would create false "still loading" signals from decorative loaders, chrome, and background imagery.

Why three separate interfaces and not one

The post doesn't spell out the rationale, but the split is load-bearing:

  • Image readiness ≠ video readiness: "start playing" and "fully drawn" are different predicates — the Visually Complete definition for Video Pin Closeup is "the full-screen video starts playing", not "the full video is loaded."
  • Text readiness differs again: fonts may be fallback-rendered before custom webfonts load; Pinterest's Search Auto Complete page's Visually Complete is "the search autocompleted suggestions' text rendered along with the avatar images" — the avatar is a PerfImageView, the text is a PerfTextView, and both must be ready.
  • Three interfaces let product engineers pick the right one without cross-type leakage in the ready predicate.

Caveats

  • Stub — method signatures are only partially disclosed ("etc." in the post); full interface definition, inheritance from Android base classes, and threading model are not specified.
  • Correctness-of-tagging not guarded — the post doesn't describe lint rules, annotation processors, or code-review guardrails that catch "forgot to mark the hero image as PerfImageView" (false early completion) or "marked the decorative shimmer as PerfImageView" (completion never fires). In practice this is the load-bearing correctness question for any opt-in instrumentation scheme.
  • Visibility semantics — the post names geometry methods but doesn't specify how "visible" is computed (within screen bounds? not covered by opaque overlay? isShown() plus bounds check?).
  • iOS / Web analogues unspecified — the cross-platform extension is mentioned in the post but interface-level names and shapes aren't disclosed.

Seen in

Last updated · 319 distilled / 1,201 read