fix(odds-ticker): stop the marquee freezing on its own background work

[ChuckBuilds]

The symptom

The odds marquee stuttered visibly where the other scrolling plugins did not — and its frame statistics said it shouldn't. Over 45 minutes on hardware, odds-ticker, leaderboard, stocks and news all sat at a 10.00 ms median with 0.08–0.16% stalls, and all four resolve to the same pacing (100.0 px/s — 1px every 1 refresh = 100.0 fps, smooth).

The medians hid it. The maxima did not:

odds-ticker   80.6 fps over 404 frames | median 10.00ms | max  981.96ms
odds-ticker   56.3 fps over 282 frames | median 10.00ms | max 2201.61ms
odds-ticker    3.8 fps over  19 frames | median 10.00ms | max 4829.02ms
odds-ticker   80.2 fps over 402 frames | median 10.00ms | max 1010.12ms
leaderboard  100.0 fps over 501 frames | median 10.00ms | max   22.08ms   <- worst real frame

A handful of multi-second frames barely move a stall percentage, but they are exactly what the eye catches.

The cause

display() tests current_time - self.last_update >= current_interval to decide whether to refresh live game data. last_update is written only inside _perform_update, so the test kept passing: 6,661 firings in 80 minutes, essentially one per frame.

Most of those cost nothing — _perform_update has its own early return — beyond one journald write per frame. But when the interval genuinely elapsed, one of them ran the full ESPN fetch plus a _create_ticker_image recomposite on the render thread. display() runs on the shared display loop, so that freezes the whole rotation, not just this plugin. 495 Total width calculation lines in that window confirm ~22 recomposites, and the 1–5 s frames line up with them.

The fix

• Stamp the interval when the refresh is requested, not when it lands. That is what the interval was always meant to measure. 6,661 firings → 2.
• Defer whenever the core can. The old code required is_currently_scrolling(), which is False on the first frame of a display cycle — exactly when the interval is most likely to have elapsed — so the blocking round trip could still reach the render thread.

Two further blocking paths in display() are removed as well. Both were written as a thread immediately followed by a blocking get():

t = threading.Thread(target=work); t.start()
q.get(timeout=5)                    # <-- on the render thread

which is a blocking call wearing a thread as a disguise — the thread bought nothing, and could not have helped anyway since the work is requests and PIL. In fairness these were dead code on the test rig (0 trips in 80 minutes, at WARNING level, in a window carrying 79 other warnings). They are fixed because they are reachable on a Vegas rig and when a fetch returns no games, not because they caused this. They now start the work once and collect it on a later frame, with a per-job backoff.

Three consequences of no longer blocking, handled here:

• A half-built strip could become visible. _create_ticker_image bound self.ticker_image and then drew the separator bars into it and rebuilt cached_array. It now builds into a local and publishes last.
• Invalidation would have flashed "No odds data". Core clears the helper's cache whenever the plugin reports an update — about once a minute on a live rig — and rebuilding without blocking would have shown the placeholder over perfectly good games, the exact symptom the invalidation handling was written to stop. It does not need a rebuild: _perform_update calls _create_ticker_image before the invalidation lands, so ticker_image is already current and core cannot clear it. display() now re-seeds the helper from the strip in hand — two attribute writes, and the marquee never stops. Array before image: _get_visible_portion_integer reads cached_image.width and cached_array separately, and a new image against an old array is short by the difference, which reaches Image.frombytes as "not enough image data".
• Per-frame log spam. Two warnings and the fallback's three info lines fired once per rebuild while display() blocked; they would now fire once per frame. Removed and demoted.

Verification

30 minutes on hardware (hdpi, 2×128×64 HUB75), rotation-gap windows excluded so only in-scroll frames are compared:

plugin	windows	frames	median	p95	max	stalls
odds-ticker	29	15,031	10.00 ms	13.52 ms	19.98 ms	0.08%
news	45	22,509	10.00 ms	11.68 ms	20.02 ms	0.06%
stocks	15	7,502	10.00 ms	12.17 ms	26.13 ms	0.11%

Worst in-scroll frame 4829 ms → 19.98 ms; interval check 6,661 → 2 firings; zero fallback frames, zero tracebacks, zero not enough image data.

Tests: test_display_defers_network.py pins the stronger deferral guard, the interval stamp, the absence of any blocking get() in display(), and publish-after-cached_array ordering. test_scroll_cache_invalidation.py pins that invalidation re-seeds rather than recomposites. 7 passing.

Manifest bumped 1.4.2 → 1.4.3 and plugins.json regenerated.

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 827a8d28-cbf0-4e04-b4b7-1940083fa848

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 32 complexity

Metric	Results
Complexity	32

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}