get_metrics() draw_calls / ui_elements / render counters read 0 in windowed builds #341

New issue

Closed

opened 2026-07-03 00:49:40 +00:00 by john · 1 comment

john commented

2026-07-03 00:49:40 +00:00

Owner

Found during the Gauntlet benchmark implementation (#340, DESIGN.md deviation 4): in the 0.2.8 windowed Linux build, mcrfpy.get_metrics() returns 0 for draw_calls, ui_elements, and the per-frame render counters (grid_cells_rendered, entities_rendered), even mid-trial with thousands of live objects rendering. frame_time / fps / runtime work correctly (they drive the Gauntlet's scoring and HUD).

Two other metric quirks documented in the same deviations list, worth resolving or documenting while in here:

frame_time is in milliseconds despite the docstring saying seconds (docstring at src/McRFPy_API.cpp get_metrics entry) — fix whichever side is wrong.
fps is a cumulative average since startup, not instantaneous; the Gauntlet derives instantaneous FPS from frame_time instead. Consider documenting or adding an instantaneous field.

Impact: the Gauntlet HUD displays draw calls honestly as 0 and scores on frame_time alone; the Phase 5.2 benchmarks and any future profiling work would benefit from these counters actually counting.

Likely area: the counters may only be incremented in code paths that were refactored during the GridView/chunk work, or the accumulate/reset happens after the Python-visible snapshot is taken. Verify in src/GameEngine.cpp metrics plumbing and wherever drawCalls is incremented.

Related: #340 (Gauntlet), #255 (perf tracking).

Found during the Gauntlet benchmark implementation (#340, DESIGN.md deviation 4): in the 0.2.8 windowed Linux build, `mcrfpy.get_metrics()` returns 0 for `draw_calls`, `ui_elements`, and the per-frame render counters (`grid_cells_rendered`, `entities_rendered`), even mid-trial with thousands of live objects rendering. `frame_time` / `fps` / `runtime` work correctly (they drive the Gauntlet's scoring and HUD). Two other metric quirks documented in the same deviations list, worth resolving or documenting while in here: - `frame_time` is in **milliseconds** despite the docstring saying seconds (docstring at `src/McRFPy_API.cpp` get_metrics entry) — fix whichever side is wrong. - `fps` is a cumulative average since startup, not instantaneous; the Gauntlet derives instantaneous FPS from `frame_time` instead. Consider documenting or adding an instantaneous field. Impact: the Gauntlet HUD displays draw calls honestly as 0 and scores on frame_time alone; the Phase 5.2 benchmarks and any future profiling work would benefit from these counters actually counting. Likely area: the counters may only be incremented in code paths that were refactored during the GridView/chunk work, or the accumulate/reset happens after the Python-visible snapshot is taken. Verify in `src/GameEngine.cpp` metrics plumbing and wherever `drawCalls` is incremented. Related: #340 (Gauntlet), #255 (perf tracking).

john added the

Bugfix

priority:tier2-foundation

system:performance

labels

2026-07-03 00:49:40 +00:00

john added a new dependency

2026-07-11 15:17:36 +00:00

#346 [Performance] Document web-build (WASM) profiling workflow — DevTools + emcc, sibling to #345

john referenced this issue

2026-07-11 15:18:45 +00:00

[Performance] Document web-build (WASM) profiling workflow — DevTools + emcc, sibling to #345 #346

john commented

2026-07-11 15:18:49 +00:00

Author

Owner

Refinement (2026-07-11): now gates #346

Linked as a dependency of #346. The web-build profiling workflow designates the in-engine ProfilerOverlay/ProfilingMetrics HUD as the one instrument identical across desktop and web — that claim is only true once these counters actually populate. Fixing this unblocks #346's central deliverable.

Kept at tier2 as the paired near-term instrumentation push alongside numpy #337 (also bumped to tier2): numpy-native data views + working render counters are the two "make the agent environment measurable" pieces.

## Refinement (2026-07-11): now gates #346 Linked as a dependency of #346. The web-build profiling workflow designates the in-engine `ProfilerOverlay`/`ProfilingMetrics` HUD as the one instrument identical across desktop and web — that claim is only true once these counters actually populate. Fixing this unblocks #346's central deliverable. Kept at tier2 as the paired near-term **instrumentation** push alongside numpy #337 (also bumped to tier2): numpy-native data views + working render counters are the two "make the agent environment measurable" pieces.

john referenced this issue

2026-07-11 15:18:55 +00:00

Jupyter Notebook Interface #54

john referenced this issue from a commit

2026-07-14 12:01:03 +00:00

fix(metrics): report counters Python can actually observe

john closed this issue

2026-07-14 12:01:03 +00:00

john referenced this issue from a commit

2026-07-14 12:01:04 +00:00

test(suite): unrot 82 tests that were passing without ever running

john referenced this issue from a commit