ranger/rangerhq-reader
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

fix: high-WPM chunk modes were clamped by 1500ms minimum-display floor (v1.1.2)

Browse Source 
After v1.1.1 raised the WPM cap to 3000 for Sentence and Paragraph modes,
David noticed pushing the slider from 1500 to 3000 didn't actually speed
up reading. The chunks still sat on screen for the same amount of time.

Root cause: the v1.1.0 minimum-display floor was 1500ms per chunk. At
3000 WPM, any sentence under ~60 words mathematically wants to display
for under 1500ms — but the floor clamped them all to 1500ms, so the
calculated speed-up never reached the user.

Lowered floors:
- Sentence mode: 1500ms → 400ms
- Paragraph mode: 1500ms → 800ms

Max cap stays at 12s for very long paragraphs at very low WPM.

At 3000 WPM with the new floors, a 20-word sentence now displays for
500ms (was 1500ms, 3x faster) and the slider behaves the way users
expect — higher WPM = faster reading, all the way to 3000.

The reader does NOT iterate word-by-word inside a chunk; the whole
sentence/paragraph is rendered in one DOM update. Word count is used
only to estimate the auto-advance interval, not as a per-word loop.
This commit is contained in:
David Keane
2026-05-27 02:43:36 +01:00
parent 669aabf5f2
commit a5819f0c72
2 changed files with 39 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+24
View File
@@ -9,6 +9,30 @@ Format: [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/) — versi
---
## [1.1.2] — 2026-05-27
### Fixed — High WPM in Sentence / Paragraph modes was clamped by a too-conservative minimum-display floor
After v1.1.1 raised the WPM cap to 3000 in Sentence and Paragraph modes, David noticed that pushing the slider from 1500 to 3000 didn't actually speed up reading — the chunks were still sitting on screen for the same amount of time.
Root cause: the v1.1.0 minimum-display floor was **1500 ms per chunk** (set conservatively to prevent flash-frame illegibility). At 3000 WPM, any sentence under ~60 words mathematically wants to display for under 1500 ms — but the floor clamped them all to 1500 ms, so the calculated speed-up never reached the user.
Lowered floors:
- **Sentence mode**: 1500 ms → **400 ms** (eye can absorb a short sentence in well under half a second once it's on screen)
- **Paragraph mode**: 1500 ms → **800 ms** (paragraphs are denser; need slightly more time even at high WPM)
Maximum cap stays at 12 s for very long paragraphs at very low WPM.
At 3000 WPM with the new floors, a 20-word sentence displays for **500 ms** (was 1500 ms — 3× faster) and a 60-word paragraph displays for **1750 ms** (was 1500 ms — uncapped formula now visible).
This makes the WPM slider actually behave the way users expect: higher WPM = faster reading, all the way up to 3000.
### Clarification
The reader does NOT iterate word-by-word inside a chunk in Sentence or Paragraph modes. The whole sentence or paragraph is rendered in one DOM update; only the auto-advance interval is calculated from word count. The word count is used as a proxy for "how long does a reader need to absorb this chunk," not as a per-word display loop.
---
## [1.1.1] — 2026-05-27
### Changed — Mode-aware WPM ceiling