pmndrs / pmndrs/react-three-examples

compute-reduce / storage-buffer: bring back the DOM timing readout the originals use to make their point

Open
#1 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
TypeScript
Stars
2
Forks
1
PR merge metrics
No merged PRs in 30d

Description

What

Two ports render a faithful, correct WebGPU canvas that nonetheless fails to show what
the demo is about, because the substance lives in DOM the shell doesn't render:

  • compute-reduce (webgpu_compute_reduce): the original's canvas is two flat white
    planes — ours matches exactly (verified against pnpm shot:original webgpu_compute_reduce,
    a live oracle capture). The actual point of the demo — comparing reduction kernels — is
    conveyed entirely by DOM text around the canvas: per-side pass counts and GPU timings
    ("18 pass in 0.024541ms" vs "2 pass in 0.013125ms"), a subgroup-reduction explainer, and
    an animated thread-value diagram.
  • storage-buffer (webgpu_storage_buffer) drops the same kind of trackTimestamp
    readout for the same reason.

Both ports followed the standing convention correctly — "examples never build their own
titleblock UI" — but the convention as written has no escape hatch for a demo whose whole
point is a DOM readout, so the result is a canvas that "conveys almost nothing on its own."

Why it matters

Single-demo (two demos) fidelity issue, not site-wide — the port is technically correct,
just uninformative. Worth fixing because the corpus's whole premise is teaching techniques
clearly, and these two currently don't for their headline comparison.

Recommendation already on file

From docs/REVIEW-QUEUE.md #1: bring back the timing readout only, scoped tightly to the
timing comparison, as in-example DOM — which needs a new convention since AGENTS.md
currently says examples never build their own titleblock UI. This is a "yes, and here's
the shape" question, not a "should we" question — worth deciding the shape once (e.g. a
small shared src/utils/ readout component) since it applies to at least two examples now.

Pointer

docs/REVIEW-QUEUE.md §1 ("compute-reduce: the canvas is faithful, but the DEMO was in
the DOM we dropped") and §6 ("storage-buffer drops the original's WebGL-vs-WebGPU
comparison", which references the same DOM-readout question for its trackTimestamp UI).

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with docs/REVIEW-QUEUE.md sections 1 and 6, then inspect the compute-reduce and storage-buffer examples and the convention in AGENTS.md. Define the shared readout shape before wiring it into both ports. Done means each example shows the original timing comparison and explanatory DOM readout without changing the faithful canvas.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, three.js, typescript
Domain
frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.