Skip to content

Add a circular progress indicator and explicit phase labels #36

Closed

Description

@PurpleSentinel

Parent: #23

Summary

Use the round display to show session progress and clearly identify track, warning, overtime, and rest phases.

Acceptance criteria

  • Keep the countdown as the primary visual element.
  • Update progress no more often than needed for smooth, efficient rendering.
  • Use labels or symbols so phase changes do not depend only on colour.
  • Guarantee no clipping around the circular edge.
  • Measure redraw cost and input responsiveness on hardware.

Implementation

Implemented by #82 with a 36-segment, two-pixel perimeter ring, explicit phase labels, and a lazily loaded Timer-only graphics module that preserves the RP2040 startup memory margin.

Roadmap group

Driver display and alerts

Activity

  1. PurpleSentinel commented on Aug 13, 2026

    @PurpleSentinel
    ContributorAuthor

    Development has started on the isolated local branch feature/issue-36-session-progress-ring as a deliberately reversible prototype.

    Current prototype behavior:

    • a two-pixel, 36-segment high-contrast perimeter arc empties in proportion to scheduled track and rest time;
    • the primary countdown, MAX-G value and lower display retain their existing positions and sizes;
    • explicit labels show TRACK, final-third WARNING, OVERRUN, and REST;
    • FINAL LAP is used only when the user has selected LAPS LEFT and the average-based estimate reaches one lap or less;
    • the existing once-per-visible-frame refresh policy is retained.

    Validation so far:

    • 211 hardware-independent tests pass;
    • geometry tests keep every arc point within the 240 × 240 circular panel and keep the longest label clear of MAX-G;
    • measured on the supported RP2040-Touch-LCD-1.28-B: a worst-case full ring adds about 5.5 ms of framebuffer work; the measured warm full frame was approximately 80.7 ms render plus 19.1 ms LCD transfer;
    • deployed to the connected reference device through the Docker device-access workflow with its existing user.json preserved.

    The prototype has intentionally not been committed, pushed, or merged pending physical/UI assessment.

  2. PurpleSentinel commented on Aug 13, 2026

    @PurpleSentinel
    ContributorAuthor

    Implemented and merged in #82.

    Final behaviour:

    • a two-pixel, 36-segment perimeter ring empties proportionally during track and rest sessions;
    • TRACK, WARNING, conditional FINAL LAP, OVERRUN, and REST labels provide non-colour state cues;
    • the primary countdown remains fixed and dominant;
    • the MAX-G line now uses a smaller MAX caption with a larger tabular value and unit;
    • Timer-only drawing code is lazy-loaded so it does not consume the RP2040's startup heap.

    Validation completed:

    • 211 host tests passed locally and both GitHub Actions runs passed;
    • the full ring added approximately 5.5 ms of framebuffer work on the reference device;
    • after correcting the startup module lifetime, the real device booted with approximately 54 KB free after startup imports and loaded the Timer graphics with approximately 27 KB free;
    • the final firmware was deployed and reset through the required Docker /dev/ttyACM0 workflow with device settings preserved.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    NewFeatureCandidate product capability for future development

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions