Export overlay draws multiple white lines at specific timestamps (reproducible) — probable drawing of N marks per large frametime

[guimaraf]

---

Version / Environment

• TRDrop: trdrop-release-a0b4563
• OS: Windows 11
• GPU: NVIDIA RTX 3060, driver 581.57
• CPU / RAM: Intel i7-11700K, 32 GB DDR4
• Tested on the above hardware

---

Short Summary

When exporting frames with overlays (FPS / tear / frametime plots), TRDrop draws multiple white lines (clusters of horizontal/vertical lines) at specific timestamps. The source video does not contain these lines — they only appear in exported images that include the overlay. The behavior is reproducible across multiple source files (PC emulators and Mister FPGA). Analysis of the exported CSV shows that the problematic timestamps correspond to large frametime spikes that are integer multiples of the frame interval (≈ 16.6667 ms), which suggests the overlay is drawing one mark per aggregated frame (i.e., N marks when frametime ≈ N × frame_interval).

---

Observed Behavior

• White lines appear only in frames exported with overlay applied.
• The original source (played directly or extracted as PNGs) shows no such lines.
• The issue occurs at specific timestamps (example for the sample provided: roughly 16–23 s; in other videos the user observed around 0:39 and 0:59).
• The issue occurs with exports in both .jpg and .tiff.
• Exporting the overlay only (separate overlay export) reproduces the same problem, so it is not limited to JPEG compression.
• Changing plot color (white → cyan/purple), adjusting Pixel difference (0 → 20), toggling Delta rendering, and other UI options did not resolve the issue.
• Exporting in shorter blocks and restarting TRDrop between blocks reduces the incidence (workaround).

---

Exact Steps to Reproduce

1. Open sample_part01.mkv (attached) in TRDrop.
2. Enable Enable framerate analysis, Enable tear analysis, and Enable frametime analysis.
3. Use the following settings (based on screenshots provided by the user):
   • Analysis range = 360 (each panel)
   • Max FPS = 60
   • Pixel difference: values tested 0 / 5 / 20 (all tested)
   • Tear plot color: white (also tested other colors)
   • Frame graph centering = enabled
   • Enable Graph Background Shadow = enabled
4. Export frames with overlay (choose .jpg or .tiff) for the segment that includes roughly 16–23 s (or 0:35–1:05).
5. Open exported frames and compare them with frames extracted from the original (without overlay) — observe clusters of white lines in exported frames at the indicated timestamps.

Helpful ffmpeg commands used in testing:

# Extract a short sample (no re-encode)
ffmpeg -ss 00:00:35 -i input.mkv -to 00:00:30 -c copy sample_part01.mkv

# Extract frames from the original (for direct comparison)
ffmpeg -ss 00:00:35 -i input.mkv -frames:v 300 frame_%06d.png

---

Suggested Attachments (please attach these to the issue)

• sample_part01.mkv — short reproducible snippet (e.g., 0:35–1:05).
• frame_orig_XXXXX.png — original frame (extracted directly from the source) at the affected timestamp.
• frame_trdrop_export_XXXXX.jpg or .tiff — frame exported by TRDrop showing the white lines.
• trdrop_analysis.csv — CSV exported by TRDrop (attached by the user).
• trdrop_monitor.csv — optional: process memory/CPU log captured during export (if available).
• error_reference_image.png — screenshot provided by the user showing the problem.
• Screenshots of TRDrop configuration panels (the ones already shared by the user).

---

Analytical Evidence (based on the attached CSV)

• The provided CSV contains 790 frames and an estimated duration of ~26.40 s.
• There is a cluster of frametime spikes between ~16 s and 23 s: multiple frames report Frametime = 283.33 ms and a peak at 450.00 ms.
• The largest recorded samples in the CSV (frame | time(s) | frametime(ms)):
  • frame 622 | time 22.917 s | frametime 450.00 ms
  • frame 604 | time 17.650 s | frametime 283.33 ms
  • frame 609 | time 19.067 s | frametime 283.33 ms
  • frame 615 | time 20.767 s | frametime 283.33 ms
  • frame 599 | time 16.233 s | frametime 283.33 ms
  • frame 613 | time 20.200 s | frametime 283.33 ms
  • frame 612 | time 19.917 s | frametime 283.33 ms
  • frame 611 | time 19.633 s | frametime 283.33 ms
  • frame 610 | time 19.350 s | frametime 283.33 ms
  • frame 608 | time 18.783 s | frametime 283.33 ms

Interpretation:

• 283.33 ms ≈ 17 × 16.6667 ms → suggests that the frametime corresponds to aggregation of ~17 frames;
• 450 ms ≈ 27 × 16.6667 ms → similar aggregation of ~27 frames.
• This strongly suggests the overlay may be drawing one mark per aggregated "dropped" frame, resulting in N marks drawn simultaneously when frametime ≈ N × frame_interval, causing the visible cluster of lines in exported images.

---

Expected Behavior

The overlay should visually represent events such as high frametime or dropped frames without drawing dozens of thin marks that "pollute" the image. Preferable behaviors include:

• Draw a single marker for the event and annotate it with a counter (e.g., "x17"); or
• Cap the number of lines drawn per frame (configurable, e.g., max_lines_per_frame); or
• Render an aggregated visual (bar/rectangle) scaled to the frametime instead of N discrete marks.

---

Tests & Attempts (detailed list of what was tried)

• Exported .jpg and .tiff (both reproduce the problem).
• Changed plot color (white → cyan/purple) — issue persists.
• Varied Pixel difference (0, 5, 20) — no change to occurrence.
• Reduced Analysis range (tried smaller values) — did not remove issue, though exporting in blocks and restarting TRDrop reduces occurrence (workaround).
• Toggled Delta rendering, Graph background shadow, Frame graph centering in multiple combinations — issue persists.
• Exported overlay-only (separate) — issue still reproduces.
• Restarted TRDrop between exports — issue still occurs at deterministic timestamps.
• Exported in short blocks and restarted TRDrop between blocks — decreases incidence (workaround).

---

Hypotheses / Diagnosis

1. Overlay iterates per unit of frametime: when frametime = N × frame_interval, the overlay renderer draws N marks (one per aggregated frame), producing a visible cluster.
2. Redraw / flush periodicity: the analysis windows (Analysis range) might trigger redraws that, combined with large frametimes, produce many drawn traces.
3. Driver/acceleration interaction: while possible, the evidence points more strongly to overlay logic that multiplies marks based on aggregated frametime rather than GPU corruption.
4. Not a pure compression issue: artifacts appear with TIFF and with overlay-only exports; JPEG compression only increases visibility but is not the root cause.

---

Concrete Fix Suggestions (for implementers)

• Group / cap marks per event: When frametime > frame_interval, draw a single marker with a count (e.g., "x17") instead of drawing 17 lines.
• Add configurable max_lines_per_frame (default e.g., 8) to avoid drawing excessive marks.
• Clamp frametime for drawing purposes: clamped_frametime = min(frametime, max_frametime_for_plot) and/or use a logarithmic scale for extreme values.
• Add an “overlay-compact” export mode (diagnostic): export one marker per event plus a CSV/JSON counter.
• Add export options: "Export frames without overlay" + "Export overlay as JSON/CSV/PNG separate" to allow safe composition externally.
• Add timestamped rendering logs in overlay code to help reproduce exactly when multiple marks are drawn.
• Provide a synthetic test generator (script) that creates frametime sequences with N× intervals (e.g., 17×, 27×) to aid regression testing.

---

Severity & Reproducibility

• Reproducible: Frequently / Consistently across different source files (user tested 3 different sources).
• Severity: High for users exporting frames with overlay — visual output is significantly degraded and unusable for publication/analysis in affected segments.

---

What I (the user) can provide

• sample_part01.mkv (short snippet) — attached.
• Original frames (PNG) and exported frames (JPG/TIFF) for direct comparison.
• trdrop_analysis.csv (attached) — the CSV used in the analysis.
• trdrop_monitor.csv — optional memory/CPU log captured during export.
• A short screen capture of the export process (if needed) or a mini-dump of the process when the artifact occurs.
• Willing to test any patch/branch and provide feedback.

---

Short summary for top of the issue

Export overlay draws multiple white line clusters at timestamps where frametime is a large multiple of the frame interval (e.g., 283.33 ms = ~17 × 16.6667 ms). The overlay appears to draw one mark per aggregated frame, producing dozens of lines in some frames. Reproducible with JPG/TIFF and overlay-only export; happens across multiple source types. Suggested fixes: cap marks per frame, group marks into a single marker with a counter, or export overlay separately.

---

If you want, I can also attach these files to the issue for you (if you provide the small sample files and screenshots), or paste this same content directly into the GitHub issue body for quick submission.

[ImplyingKinpatsu]

Those are to indicate screen tears, which I've found you have to play a little bit with the dismissed percentage when a game does have screen tearing, but there's no reason why anything in your set up there would cause tearing in the video, right? I set dismissed tear percentage to 100% and uncheck "enable tear analysis" when working with games without screen tearing