perf(tlm-viewer): skip screen updates for unchanged values

[jmthomas]

What changed

• Stop writing unchanged values to screenValues in updateValues once the aging fade is done so widgets don't re-render on every poll
• Export AGING_* constants from VWidget.js so the screen knows how many polls the fade takes
• Add INST ccsds.txt and hs_adcs.txt 1000 item screens to measure mostly static vs constantly changing values

Why it changed

Performance rendering screens with a lot of static items

Testing strategy

Created new screens with 1000 items: ccsds (mostly static) and hs_adcs (totally dynamic). This gives us a way to test performance between the 2.

Review notes

Further enhancements would be to not use v-text-field and instead create a lightweight element that has no child components to update. This would require additional effort to match look and feel and avoid losing functionality.

Here's a performance plot of the CCSDS screen which contains 1000 mostly stale items. The thing to note is the drop in listeners and the width of the yellow bars from about ~115ms to 29ms once the telemetry aging is complete:

Here's the screen (still only showing half):

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[codecov]

Codecov Report

❌ Patch coverage is 76.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.12%. Comparing base (104c84c) to head (4388886).
⚠️ Report is 17 commits behind head on main.

Files with missing lines	Patch %	Lines
.../openc3-vue-common/src/components/Openc3Screen.vue	73.91%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3957      +/-   ##
==========================================
- Coverage   80.14%   80.12%   -0.02%     
==========================================
  Files         901      901              
  Lines       68356    68394      +38     
  Branches     2645     2655      +10     
==========================================
+ Hits        54784    54803      +19     
- Misses      12907    12921      +14     
- Partials      665      670       +5     

Flag	Coverage Δ
frontend	67.03% <76.00%> (+0.01%)	⬆️
python	80.13% <ø> (-0.01%)	⬇️
ruby-api	82.44% <ø> (-0.21%)	⬇️
ruby-backend	85.66% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

AI adversarial review

Note

The fixes from this review are in #3961, a PR into perf/screen-skip-unchanged-values. Merge it to apply them.

✅ Claude and Codex converged after 3 turn(s) with 1 fix commit(s).

Reviewed commit: bb3e1ae1e705f362985a2da82541a75c0733be16

Open concerns for a human

• Maintainer decision remains on whether the two large benchmark screens should ship with the demo plugin.
• The PR adds two benchmark screens of about 1,300 lines each, INST ccsds.txt and hs_adcs.txt, to the openc3-cosmos-demo plugin. Every demo install would ship and list them. A maintainer should decide whether they belong in the demo plugin.

Turn-by-turn log

Turn 1: Claude (no changes)

The change to Openc3Screen.vue and VWidget.js looks correct. Once a widget has finished fading an unchanged value (10 unchanged polls), updateValues stops writing that value to screenValues, so the screen looks the same but stops re-rendering. The fade still runs on schedule, a change in the value or its limits state resets it, and the counts are cleared on re-parse and in addItem. Items that appear more than once on a screen are counted only once per poll. I found no other widget that depends on the counter going up on every poll.

• Concern: The PR adds two screens of about 1,300 lines each, INST ccsds.txt and hs_adcs.txt, to the openc3-cosmos-demo plugin to measure performance. Every demo install will ship and list them. A maintainer should decide whether benchmark screens like these belong in the demo plugin or should go somewhere else.

Turn 2: Codex (commit fd113d96e)

Fixed two defects in update throttling. Dependency-free logic checks and git diff --check passed; full suites were unavailable, and pnpm was not installed.

• Fixed: openc3-cosmos-init/plugins/packages/openc3-vue-common/src/components/Openc3Screen.vue:255 - JSON comparison threw on telemetry arrays containing BigInts; replaced it with recursive equality.
• Fixed: openc3-cosmos-init/plugins/packages/openc3-vue-common/src/widgets/VWidget.js:84 - The fade watcher could compare the previous rendered value and stop fading prematurely; it now reads the current computed value.
• Concern: Maintainer decision remains on whether the two large benchmark screens should ship with the demo plugin.

Turn 3: Claude (no changes)

I found nothing to change in the throttling or in Codex's fixes; the only open question is a maintainer decision about the demo plugin. Once an item has come back unchanged for more than AGING_UPDATES (10) polls, the screen stops writing it to screenValues. By then the widget's fade has already reached AGING_MIN, so the screen looks the same. I read the code rather than running it, since the test suites can't run here. Codex's two fixes hold up: the recursive sameValue handles BigInts and NaN, and the fade watcher now compares against the current _value. A change in value or limits state resets the count, and re-parsing and addItem clear it. Freezing a screen doesn't break it. No widget I checked depends on the counter going up every poll: ArrayPlot plots from its own streamed data, and Rollup reads only the limits state.

• Concern: The PR adds two benchmark screens of about 1,300 lines each, INST ccsds.txt and hs_adcs.txt, to the openc3-cosmos-demo plugin. Every demo install would ship and list them. A maintainer should decide whether they belong in the demo plugin.

[jmthomas]

Per the AI review: note that I'm not using <%= target_name %> because I'm deliberately using INST and INST2 in the screen. This is a testing only screen and doesn't need the target name substitution.

[ryanmelt]

I had the tokens messed up so the AI Review couldn't automatically fix. You can still get its review artifacts from the Action artifacts and have it implement manually

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[clayandgen]

I'm guessing the screens including INST and INST2 out of convenience? (as opposed to putting them in their own files)