Blog · arXiv Analysis · Published: August 12, 2026 · Modified: August 12, 2026 · Last reviewed: August 12, 2026

The Gaze Sample Becomes the Capture Clock

A gaze point can be spatially plausible and temporally untraceable.

Before a browser-gaze latency number becomes evidence, the sample must be paired with the frame that caused it.

The Paper

The source is Chi-Sheng Chen and Gabriel A. Brat's Measuring Browser Webcam Gaze Honestly: A Capture-Clock Methodology and Open Reference Implementation, arXiv:2608.11566v1 [cs.HC], submitted August 12, 2026. The arXiv record says it was accepted at DEMI 2026, a MICCAI 2026 workshop. The paper studies two browser pipelines, WebGazer and a FaceMesh-plus-kernel-ridge-regression implementation, and asks whether their reported inference latency begins at the camera frame or merely at the moment a gaze result is emitted.

The Missing Start Time

A browser gaze sample crosses asynchronous stages: frame capture, inference, callback, DOM update, and rendering handoff. The paper's capture-clock analysis shows the measurement trap. If code records performance.now() when a callback emits a gaze point, but never recorded the source frame's time, it can reuse the emission time as both endpoints. The subtraction then reports approximately zero milliseconds regardless of the work already performed. The number is tidy because its beginning is missing.

Exact Pairing and Honest Floors

The proposed repair uses the browser's requestVideoFrameCallback metadata. The implementation prefers captureTime and records a fallback to presentationTime, which makes the result a lower bound on capture-referenced latency. For the pipeline that exposes each processed frame, a FIFO queue pairs an emitted sample with its source-frame timestamp exactly under the paper's ordering assumptions. WebGazer hides its internal queue, so the authors pair each result with the most recent observed frame. They prove that this is a floor, not an estimate; unknown queue depth can only make the true latency longer.

What the Clock Changed

In the paper's single-user runs, naive timing produced about zero milliseconds. Capture-clock timing reported FaceMesh-plus-KRR medians of 22.0 to 22.8 milliseconds and 95th percentiles of 26.8 to 27.0 milliseconds. WebGazer's lower-bound medians were 32.8 to 34.0 milliseconds, with 95th percentiles of 50.6 to 52.0 milliseconds. Those figures can change whether a 50-millisecond interaction budget appears to pass. They demonstrate a measurement defect on this setup, not universal latency for either engine. The distinction is explicit in the reported results.

Restraint Before Ranking

The authors do not turn the session into an accuracy leaderboard. Cross-engine accuracy differences sit inside an approximately 4.6-degree between-run variability band derived from an ablation whose conditions were not true replicates. They use that band only to refrain from ranking, not to certify noise. The harness also separates spatial cluster spread from within-fixation velocity, two behaviors an aggregate precision number can blur. This is the paper's best discipline: improve the measurement before enlarging the claim.

The Clinical Probe

The paper also feeds gaze into a held-fixed polyp-segmentation pipeline. Its downstream comparison reports test Dice 0.679 from an EyeLink control and approximately zero from the authors' webcam collection. But hardware, annotator expertise, and viewing instructions changed together, making the difference an upper bound on a hardware-only penalty. Thirty-six of 900 webcam training images had no usable pseudo-mask and were excluded, and both arms used one training seed. The result supports a narrow warning: this non-expert webcam signal did not supply lesion-level weak labels under this pipeline. It does not isolate what another user, protocol, or tracker would do.

One Session Is Not a Population

The headline evaluation is one user, four runs, and one session. Engine and task order were fixed rather than counterbalanced, one pursuit calibration was shared, and there was no recalibration between runs. The appendix says the collection-time browser build was not logged. The paper therefore offers a strong method demonstration and a fragile population claim. It cannot establish performance across faces, lighting, posture, cameras, browsers, disabilities, clinical roles, or deployment sites.

The Missing Reproduction Path

The paper's reproducibility section says raw per-sample CSV logs and analysis scripts accompany the source. I inspected the version-one source package: it contains the manuscript, bibliography and style files, a README, and figures, but no TypeScript, JavaScript, Python, or CSV files. I therefore did not rerun the analysis or independently reproduce the tables. A methods paper about provenance needs its own artifact path to close.

The Capture-Clock Receipt

A browser-gaze receipt should record the camera and resolution, browser and operating system, tracker version, calibration path, viewport geometry, viewing distance, frame rate, clock source, fallback status, source-frame pairing rule, opaque-queue limitation, capture, emission, and render-handoff times, filtering, fixation rule, exclusions, run order, participant count, consent, retention, downstream task, uncertainty, code and data release, reviewer, and correction history. A latency without its clock source is not a performance fact.

The Governance Standard

The paper's deployment note says its pipeline processes frames in-browser, persists only coordinates, and should use opt-in sessions with a visible indicator. That is a sensible floor. Never promote a gaze coordinate into attention, comprehension, diagnosis, or intent without a separately validated inference. For consequential use, preserve the source-frame link and label every lower bound. The system should reveal where observation ends, where estimation begins, and which artifacts let another reviewer check the boundary.

Sources

Return to Blog