{"id":"bbfe04b3-7b29-4e45-9c2a-4714cf9b1528","arxiv_id":"2608.11566","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":7,"one_line_summary":"A requestVideoFrameCallback-based capture-clock methodology exposes a 20-50ms real inference latency in browser webcam gaze trackers that commonly report about 0ms.","lead":"Browser webcam gaze trackers often report about zero inference latency because they timestamp when a gaze estimate is emitted, not when the camera frame was captured. This paper supplies a capture-clock method using the browser's per-frame video timestamps and an open implementation that exposes a real 20-50 millisecond delay.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Eq. (4)'s opaque-engine lower bound assumes rVFC callbacks precede any consumer's frame access; WebGazer can consume a frame before its callback runs, so the WebGazer latency floors may be overestimates, not lower bounds.","rationale":"The central claim requires that Eq. (4) be a verifiable lower bound for opaque engines; that is the least secure condition because it depends on browser task ordering that the paper neither proves nor probes. The concern is internal to the derivation, not a disagreement with consensus. If the ordering probe shows consumption precedes callback, the WebGazer latencies in Table 1 become upper bounds (or at least unvalidated quantities), and the abstract's 'verifiable lower bound' phrase for engines like WebGazer must be withdrawn or rederived with an instrumented frame-access wrapper. The FaceMesh+KRR exact pairing and the 22 ms exact-pairing result are independent and survive, so the paper is not wholly invalidated; hence CONDITIONAL rather than REJECT. The N=1 and lack of counterbalancing are disclosed and limit generality, not the method. The absence of a public repository is a reproducibility condition but secondary. The reader's verdict already conditional on this scheduling assumption; the concrete test above is the specific check that would settle it.","tokens_in":16027,"tokens_out":9747,"duration_ms":97330,"concrete_test":"Run a 30-second probe in Chrome 150 using the released harness: before each WebGazer gaze emission, log (a) the harness's current tilde_t_c and (b) the presentation/capture time of the specific video frame WebGazer reads, obtained by wrapping the 2D drawImage/video access with a shim that records video.currentTime and maps it to rVFC metadata once that frame's callback fires. If any consumed frame's clock exceeds the concurrently recorded tilde_t_c, Eq. (4) is violated. A minimal synthetic-video variant can isolate the mechanism: in a rAF callback, drawImage(video) and record whether the rVFC callback for that frame has already fired; one counterexample of consumption-before-callback refutes the ordering premise.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The weakest load-bearing point is the derivation of Eq. (4) in §3.3. The paper asserts tilde_t_c >= t_true_c with the justification that the source frame 'can never have arrived after the moment the engine emitted a sample derived from it.' This assumes that a frame becomes available to WebGazer only after that frame's rVFC callback has run. That is not a property the paper establishes: rVFC schedules a task when a frame is presented for compositing, and the video frame can be read by a consumer (e.g. drawImage from the video element inside WebGazer's own rAF loop) before that task executes. If WebGazer consumes frame F_k while F_k's rVFC callback is still queued, the maximum observed frame clock at emission time is the clock of an earlier frame, so tilde_t_c < t_true_c(F_k). Then t_e - tilde_t_c exceeds the true inference latency by up to roughly one frame interval (about 33 ms at 30 Hz), which is the same order as the reported 32.8-34.0 ms WebGazer medians. Eq. (4) would therefore report an upper bound, not a verifiable lower bound, and the WebGazer latency floors in Table 1 would not support the 'fails the 50 ms budget' conclusion. The paper explicitly says WebGazer's queue depth is unobservable, so no internal check rescues the inequality; the FaceMesh+KRR exact-pairing column is unaffected because the harness controls frame handoff.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper proposes a capture-clock methodology for measuring browser webcam-gaze inference latency. It distinguishes capture time, emission time, and render-handoff time, uses requestVideoFrameCallback as a per-frame capture clock, and pairs gaze samples to source frames exactly for engines that expose their inference loop (FaceMesh+KRR) while applying a claimed lower-bound tag for opaque engines such as WebGazer. The authors report that naive timestamps collapse to ~0 ms median inference latency, whereas the corrected measurements give 22-34 ms medians (27-52 ms p95), a gap that can change whether a 50 ms interactive-latency budget is met. They also feed the gaze into a published weakly-supervised polyp-segmentation pipeline, where expert EyeLink gaze trains a usable segmenter (Dice 0.68) and non-expert webcam gaze does not (Dice ~0).","tokens_in":16339,"tokens_out":10830,"duration_ms":109637,"significance":"If the methodology is correct, this is a useful and simple contribution: the FIFO pairing via rVFC cleanly eliminates the zero-latency artifact for engines whose pipeline is observable, and the open TypeScript implementation and raw CSVs are concrete reproducibility assets. The paper is also admirably explicit about N=1, fixed run order, excluded degraded runs, and confounds in the clinical probe. The exact-pairing part (Section 3.2) is sound under its stated assumptions. However, the claimed lower bound for opaque engines rests on an unproven scheduling-order property (Section 3.3), and because that property supports the WebGazer latency columns and the budget-failure conclusion in Section 4.2, the central claim is not yet fully supported.","major_comments":[{"comment":"The inequality tilde_t_c >= t_true_c is not established. The justification that a source frame 'can never have arrived after the moment the engine emitted a sample derived from it' establishes only t_true_c <= t_e, not t_true_c <= tilde_t_c. Because WebGazer reads the video element directly (for example, via drawImage inside its own rAF loop), it can consume frame F_k before the rVFC callback for F_k has executed; the most recent observed rVFC clock at emission can then be the clock of an earlier frame, so tilde_t_c < t_true_c(F_k). In that case Eq. (4) yields an upper bound rather than a verifiable lower bound. The paper explicitly states that WebGazer's queue depth is unobservable, so no internal check can verify the ordering. The FaceMesh+KRR exact-pairing column is unaffected because the harness controls frame handoff through the FIFO queue.","section":"§3.3, Eq. (4)"},{"comment":"Because the WebGazer latency columns depend on Eq. (4), the statements that 'WebGazer reports 32.8-34.0 ms median' and that 'WebGazer's lower bound already exceeds the budget at 51-52 ms p95, so its true latency fails it by at least that margin' are unsupported as written. If Eq. (4) is actually an upper bound, the true WebGazer p95 could be below 50 ms, and the abstract's '20-50 ms gap' would not be established for opaque engines. The paper should validate the rVFC-before-consumer ordering empirically on the target browser, instrument WebGazer's frame access point, or relabel the opaque-engine numbers and remove the budget-failure inference for WebGazer.","section":"§4.2, Table 1"}],"minor_comments":[{"comment":"The text says captureTime was present on every frame in the 30 s clock probe, yet the runs reported in the paper used the presentationTime fallback; please clarify whether captureTime was unavailable in the engine's rVFC integration or explain why the fallback was deliberately chosen, since the tightness claim is otherwise confusing.","section":"§3.2"},{"comment":"The dagger for WebGazer latency cites 'lower-bound capture clock (§3.4)', but the lower-bound pairing methodology is described in §3.3, not §3.4; also, FaceMesh+KRR latencies inherit the small presentationTime-vs-captureTime offset, so both columns should carry appropriate annotations or the asymmetry should be explained.","section":"Table 1"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear [Colleague],\n\nThe paper is worth reading for anyone who uses webcam gaze in the browser, but the WebGazer latency claim needs a fix before it can be trusted.\n\nWhat is actually new is the use of requestVideoFrameCallback's per-frame clock to recover a capture timestamp instead of the usual performance.now() at the emit site. The FIFO exact-pairing for engines like their FaceMesh+KRR is simple, correct, and clearly explained. I believe them when they say common practice makes latency read ~0ms; I've seen similar artifacts. The paper is also admirably honest about N=1, fixed run order, calibration confounds, and the exclusion of degraded runs. That level of disclosure is rare and should be credited.\n\nThe soft spot is Section 3.3. Equation (4) asserts that the most recent rVFC frame clock at emission time, tilde_t_c, is at least the true capture time of the frame the engine used. That requires the rVFC callback for a presented frame to run before any consumer can read that frame. The paper gives no evidence for that ordering, and it is likely false: WebGazer reads the video element from its own requestAnimationFrame loop, and rVFC callbacks are queued as tasks that can run after the rendering steps where rAF fires. So WebGazer can consume a frame whose rVFC callback is still pending, making tilde_t_c older than the source frame. Then t_e - tilde_t_c is larger than the true latency, so the reported 'lower bound' is actually an upper bound. The WebGazer medians of 32.8-34.0ms should be read as 'no more than' values, not 'at least.' The conclusion that WebGazer fails a 50ms budget is therefore unsupported; the true median could be lower. The paper even admits WebGazer's queue depth is unobservable, so no internal check rescues the inequality.\n\nThe FaceMesh+KRR numbers are unaffected because the harness hands frames to the engine only after the rVFC callback, so the exact pairing holds. The downstream segmentation experiment is a reasonable reality check, and the negative result is honestly framed.\n\nThis is a significant flaw but a fixable one. The authors could verify the ordering with a targeted probe, or report the WebGazer latencies as an upper bound, or instrument WebGazer to expose frame timestamps. I would send it to peer review, but with a clear request to correct the WebGazer interpretation before acceptance.\n\nFor context: this belongs at CHI or UIST, and a reading group discussion would be worthwhile. I would cite the exact-pairing method, but not the WebGazer numbers.","headline":"The capture-clock method is a real fix for a real bug, but the opaque-engine 'lower bound' for WebGazer is likely mislabeled and flips the paper's headline latency claim.","tokens_in":16898,"tokens_out":4784,"would_cite":true,"duration_ms":46407,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Common timestamping hides webcam gaze latency; a capture-clock method measures honest medians of 22–34 ms.","keywords":["webcam gaze tracking","latency measurement","requestVideoFrameCallback","capture clock","weakly-supervised segmentation","gaze-prompted segmentation","WebGazer","kernel ridge regression"],"falsifier":"Instrument an engine to log, in the same process, both the rVFC callback firings and the frame identity each gaze sample consumed; a single sample whose source frame's callback fires after emission falsifies the ordering premise behind the lower bound.","tokens_in":15788,"feed_emoji":"👁️","tokens_out":6064,"duration_ms":60716,"temperature":0.7,"pith_summary":"This paper establishes that reported inference latency for browser webcam gaze trackers is near zero only because samples are timestamped when emitted, not when their source frame was captured. It proposes recovering the per-frame capture clock from the browser's requestVideoFrameCallback API, pairing each gaze sample with its source frame exactly when the engine exposes its pipeline, or at least as a verifiable lower bound when it does not. On one commodity-laptop session, honest medians are 22–34 ms with p95 up to 52 ms, a 20–50 ms gap that can decide whether a 50 ms interactive-latency budget is met. It also separates spatial spread from temporal jitter, and probes downstream utility by feeding webcam gaze into a fixed clinical weak-supervision segmentation pipeline, where the webcam signal fails as a lesion-level label.","feed_headline":"Honest webcam gaze latency is 22–34 ms, not ~0","feed_subtitle":"Emission-time timestamps hide real inference cost; a browser capture clock exposes a 20–50 ms gap.","key_machinery":"The carrier of the argument is the rVFC frame clock: a per-frame timestamp the browser attaches to each decoded video frame, provided as $captureTime$ for local camera streams and as $presentationTime$ otherwise. It supplies the missing $t_c$ in the latency identity $\\ell_I = t_e - t_c$. Exact pairing uses a FIFO queue of frame clocks, dequeued at each gaze emission, so each sample is tagged with its true source frame's clock when the engine processes frames in arrival order. For opaque engines, a single scalar keeps the most recently observed frame clock, and the paper proves the inequality $\\tilde{t}_c \\ge t_c^{\\mathrm{true}}$: a sample cannot be derived from a frame that arrived after the latest observed frame clock at emission time, so $t_e - \\tilde{t}_c$ is a verifiable lower bound on the true inference latency.","core_discovery":"The paper's central claim is that the ~0 ms inference latencies commonly reported by browser webcam gaze trackers are a measurement artifact: the source frame's capture time is never recorded at the gaze callback, so the emit timestamp silently doubles as the missing capture timestamp, making $\\ell_I = t_e - t_c$ read zero for every sample. The fix is to recover a per-frame capture clock from the requestVideoFrameCallback (rVFC) API, using $captureTime$ for local camera streams and $presentationTime$ otherwise. When the engine exposes its per-frame pipeline, a FIFO queue of frame clocks pairs each gaze sample with its exact source frame. When the engine is opaque, as with WebGazer, the most recently observed frame clock gives a verifiable lower bound: $\\tilde{\\ell}_I = t_e - \\tilde{t}_c \\le t_e - t_c^{\\mathrm{true}}$. On one commodity-laptop session, honest medians are 22–34 ms with p95 of 27–52 ms, a 20–50 ms gap against the naive ~0 ms reading.","pith_inferences":["Because the method only needs a video element and rVFC, it should transfer to any browser perception engine that consumes camera frames — face tracking, hand pose, object detection — wherever emission-time timestamps hide per-frame cost.","For opaque engines, the gap between the reported lower bound and the true latency is the engine's internal queue depth times the frame interval (~33 ms at 30 Hz); instrumenting the engine to expose queue depth would turn the floor into an estimate.","The $presentationTime$ fallback is tight on the tested hardware (median 0.6 ms behind $captureTime$), but the gap is platform-dependent, so runs should keep recording which clock served; the harness's $capture\\_clock\\_source$ header already does this.","The paper's own ablation suggests that accuracy differences below the roughly 4.6° between-run band are not interpretable at N=1; a replicate-per-condition protocol with per-kernel regularization tuning would settle whether webcam gaze can reach lesion-level prompting."],"forward_implications":["A reported all-zero inference-latency column should be read as evidence that the capture timestamp is missing, not as proof that the engine is fast.","With exact pairing, the FaceMesh+KRR engine shows 22.0–22.8 ms median and 26.8–27.0 ms p95 inference latency; with lower-bound pairing, WebGazer shows 32.8–34.0 ms median and 50.6–52.0 ms p95.","Against a 50 ms interactive-latency budget, FaceMesh+KRR's p95 pipeline latency of 27–28 ms clears the target on 30 Hz video, while WebGazer's lower bound already exceeds it at 51–52 ms p95, so its true latency fails by at least that margin.","Spatial spread and temporal jitter are separate quantities: radial p95 is nearly identical between engines (6.13° vs 6.21°) while within-fixation $v_{p99}$ differs by 1.6–3.5×, so reporting only one precision number under-describes an engine.","With a published weak-supervision segmentation pipeline held fixed, expert eye-tracker gaze trains a usable polyp segmenter (test Dice 0.679) while webcam gaze does not (Dice ≈0), an upper bound on the hardware-only penalty because annotator expertise and viewing instruction changed along with the tracker."],"supporting_citations":[{"why":"Supplies the rVFC API's per-frame $captureTime$ and $presentationTime$ clocks, the core mechanism that replaces the missing capture timestamp.","marker":"[12]"},{"why":"Defines the WebGazer baseline, the opaque-engine case that motivates the lower-bound pairing of Section 3.3.","marker":"[7]"},{"why":"Provides the MediaPipe FaceMesh landmarks used as the 13-dimensional feature vector for the new FaceMesh+KRR engine.","marker":"[4]"},{"why":"Gives the kernel ridge regression formulation used by the FaceMesh+KRR engine's closed-form mapping from features to screen coordinates.","marker":"[2]"},{"why":"Contributes the GazeMedSeg weak-supervision pipeline and expert gaze dataset used as the fixed downstream probe in Section 5.","marker":"[14]"},{"why":"Supplies the Kvasir-SEG polyp dataset on which the downstream segmentation comparison is run.","marker":"[3]"}],"fun_headline_variants":["Gaze latency you can trust: 22–34 ms, not 0","Why webcam gaze reports 0 ms? Capture-clock fix","Capture-clock reveals true webcam gaze latency","From ~0 to 22–34 ms: honest latency measurement"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that a gaze sample can never be derived from a frame whose rVFC callback fires after the sample is emitted, since otherwise the reported lower bounds on latency would not be guaranteed.","fun_headline_variants_meta":{"raw":{"variants":["Gaze latency you can trust: 22–34 ms, not 0","Why webcam gaze reports 0 ms? Capture-clock fix","Capture-clock reveals true webcam gaze latency","From ~0 to 22–34 ms: honest latency measurement"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000154,"raw_usage":{"total_tokens":1226,"prompt_tokens":973,"completion_tokens":253,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":589,"completion_tokens_details":{"reasoning_tokens":181}},"tokens_in":589,"tokens_out":253,"duration_ms":3113,"temperature":1.0,"reasoning_tokens":181,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T00:35:36.214197+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Instrument an engine to log, in the same process, both the rVFC callback firings and the frame identity each gaze sample consumed; a single sample whose source frame's callback fires after emission falsifies the ordering premise behind the lower bound.","supporting_citations":[{"cited_title":"W3C WICG Editor’s Draft (2024), editor: T","cited_arxiv_id":null,"evidence_quote":"Supplies the rVFC API's per-frame $captureTime$ and $presentationTime$ clocks, the core mechanism that replaces the missing capture timestamp."},{"cited_title":"In: Proceedings of the 25th International Joint Conference on Artificial Intelligence (IJCAI)","cited_arxiv_id":null,"evidence_quote":"Defines the WebGazer baseline, the opaque-engine case that motivates the lower-bound pairing of Section 3.3."},{"cited_title":"The Annals of Statistics36(3), 1171–1220 (2008).https://doi.org/10.1214/ 009053607000000677","cited_arxiv_id":null,"evidence_quote":"Gives the kernel ridge regression formulation used by the FaceMesh+KRR engine's closed-form mapping from features to screen coordinates."},{"cited_title":"Weakly-supervised Medical Image Segmentation with Gaze Annotations","cited_arxiv_id":"2407.07406","evidence_quote":"Contributes the GazeMedSeg weak-supervision pipeline and expert gaze dataset used as the fixed downstream probe in Section 5."}],"review_version":1}