How Does Your Computer Actually "Understand" a Mouse Scroll?

Have you ever stopped to wonder what your mouse scroll actually looks like from a computer's perspective?

For us humans, "scrolling down a bit" is one single, complete, meaningful action. But for a program, it receives a cold stream of numbers: every few milliseconds, the operating system fires off a deltaY value telling the program "the scroll wheel moved by this much." These numbers pour in one after another, and the program has absolutely no idea where one "scroll action" begins, where it ends, or which data points reflect the user's real intent versus random noise from the mouse hardware jittering around.

That's exactly the problem this system is built to solve. It implements two core algorithms:

• Algorithm 1: Stroke Boundary Detection - Slices the continuous stream of numbers into meaningful, discrete "scroll actions"
• Algorithm 2: Jitter Point Recognition - Inspects each slice and flags which individual data points are "noise" that shouldn't be trusted

I'll explain both algorithms in the most straightforward language possible. No programming background needed - if you've used a mouse, you're qualified to read this.

---

Before We Start: What Is a "Stroke"?

There's a key term used throughout the code: Stroke.

The word is borrowed from mechanical engineering, where a "stroke" refers to one complete movement of a piston from one end to the other. Here it means: one complete, continuous scroll action performed by the user.

Imagine you're reading a long article:

1. You flick the scroll wheel and the page moves down - that's Stroke 1
2. You pause to read for a few seconds
3. You flick the scroll wheel again and the page continues down - that's Stroke 2
4. You realize you scrolled past something and scroll back up - that's Stroke 3

Each stroke is an independent, meaningful unit of action. Only by identifying these strokes can a program truly understand what the user is doing.

---

Algorithm 1: Stroke Boundary Detection

The Core Problem: How Do We Know You've "Stopped"?

This is the hardest part of the entire system.

Why is it hard? Because every user's scrolling rhythm is completely different. Some people scroll in fast bursts; others scroll slowly and deliberately. During fast scrolling, two consecutive events might be only 5ms apart. During slow scrolling, the gap might be 80ms.

If we simply hardcode "anything over 50ms means you stopped," then slow scrollers will have every single scroll action chopped into dozens of tiny strokes. Total chaos.

If we say "only 500ms counts as a stop," then a brief natural pause between two separate scrolls gets treated as one continuous action. Also wrong.

So the algorithm's core insight is: don't use a fixed standard - instead, watch your rhythm and use your own rhythm to judge whether you've stopped.

The Sliding Window: Giving the Algorithm a Short-Term Memory

To understand a user's "current rhythm," the algorithm needs to remember the time gaps between recent events. The code uses a sliding window of size 5:

This "window" is the algorithm's short-term memory - it only remembers the time gaps between the most recent 5 events and computes their average. When a new event arrives, the oldest record gets dropped, keeping the window size constant. This is called a Sliding Window Average.

Two Checkpoints: Deciding When to Cut

Armed with "the recent average gap" as a reference, the algorithm sets up two decision checkpoints. Triggering either one causes the current stroke to be finalized and a new one to begin:

Checkpoint 1: Absolute Time Gap (Hard Cut)

Rule: If the gap between two events exceeds 120ms, cut immediately.

120ms is roughly 1/8 of a second. If two consecutive scroll events are separated by that long, it's almost certain the user paused between two distinct actions. This is the "last resort" checkpoint - no matter how slowly you scroll, a gap over 120ms always triggers a cut.

Checkpoint 2: Relative Time Gap (Adaptive Cut)

Rule: If the current gap exceeds "2x the recent average gap" (and at least 25ms), cut.

This is where the algorithm gets genuinely clever. The judgment threshold shifts dynamically with your personal scrolling rhythm, rather than applying the same ruler to everyone:

In mathematical notation:

$$\text{Cut Condition} = \Delta t > 120\text{ms} \quad \mathbf{OR} \quad \Delta t > \max\!\left(\bar{t} \times 2.0,\ 25\text{ms}\right)$$

Where $\Delta t$ is the current time gap and $\bar{t}$ is the sliding window average of the most recent 5 gaps.

The Complete Detection Flow

Strengths and Weaknesses

Strengths

Adaptivity is the standout feature. Different users, different devices, different scrolling speeds - the algorithm adjusts its judgment threshold to match the current context. A trackpad and a mechanical mouse can produce events with rhythms that differ by an order of magnitude, yet this system handles both gracefully.

The dual-checkpoint design is robust. The absolute threshold acts as a safety net for extreme cases; the adaptive threshold handles the normal range. Each one covers the other's blind spots.

Time complexity is $O(n)$ - highly efficient. Each event is processed exactly once, and the window update is a constant-time operation. Perfectly suited for real-time processing in a browser.

Weaknesses

Cold-start problem. Every time a stroke is finalized, the sliding window resets. The first few events of a new stroke have no historical data to work with, so only the absolute threshold (120ms) is available during that brief period.

Parameters are empirical, not universal. windowSize=5, timeGapMultiplier=2.0, absoluteTimeGap=120 - all hand-tuned. Switch to a different input device or a different use case, and these numbers may need revisiting.

Direction-agnostic. This algorithm only looks at time, not direction. If a user scrolls down and then immediately scrolls up, both scrolls land in the same stroke as long as the time gap is small.

---

Algorithm 2: Jitter Point Recognition

The Core Problem: Which Data Points Are "Noise"?

After Algorithm 1 slices the stream into strokes, a new question emerges: can we trust every data point inside each stroke?

Not necessarily. Two scenarios produce noisy data points:

Scenario 1: Direction reversal. The user is scrolling down, but the mouse physically twitches and produces a deltaY = -2 in the opposite direction. That -2 is not the user's intent - it's hardware noise.

Scenario 2: Value spike. The user is scrolling normally with small single-digit deltaY values, and suddenly one event fires with deltaY = 800. Something went wrong - maybe a driver bug, maybe accumulated events being flushed at once.

Algorithm 2's job: within each stroke, find these anomalous points and flag them.

Phase 1: Directional Consistency Check

Core logic: majority rules.

First, count how many positive values (scroll down) and negative values (scroll up) exist in the stroke:

$$\text{Dominant Direction Ratio} = \frac{\max(\text{positive count},\ \text{negative count})}{\text{total non-zero count}}$$

If this ratio exceeds 60%, the stroke has a clear dominant direction. Any points moving in the opposite direction are flagged as jitter noise.

Phase 2: Absolute Value Check

For points not flagged by Phase 1, one more check: if |deltaY| exceeds 500, flag as jitter.

The Complete Two-Phase Flow

Quality Scoring: Giving Each Stroke a Health Score

Each jitter point found deducts 20 points from the stroke's quality score, with a floor of 0:

$$\text{Quality Score} = \max\!\left(0,\ 100 - \text{jitter count} \times 20\right)$$

Strengths and Weaknesses

Strengths

Two complementary detection dimensions with broad coverage. Directional checking catches jitter with tiny values but wrong direction (e.g., deltaY = -1); absolute value checking catches anomalies that move the right way but have absurd magnitudes (e.g., deltaY = 900). Each covers the other's blind spot.

The dominant direction is inferred automatically. The algorithm figures out "which direction this stroke is primarily heading" from the data itself - no prior knowledge needed.

Reason classification aids debugging. Every jitter point is tagged with whether it was flagged for direction (direction_reverse) or magnitude (absolute_threshold), making diagnosis straightforward.

Weaknesses

The 60% threshold has tricky edge cases. With 3 positive and 2 negative values, the ratio hits exactly 60% - those 2 negative points get flagged. With 2 positive and 2 negative, the ratio drops to 50% and nothing is flagged at all. One data point difference, completely opposite outcomes.

Will misfire on legitimately mixed-direction strokes. If a user intentionally scrolls down then back up, the minority-direction points get incorrectly labeled as jitter. That's a false positive.

The hardcoded threshold of 500 is device-dependent. Trackpads typically produce single-digit deltaY values; certain high-DPI mice might produce values well above 500 under normal conditions. This number does not travel well across hardware.

Linear score deduction ignores stroke length. Losing 20 points per jitter point treats a 1-in-100-point anomaly the same as a 1-in-3-point anomaly, even though the latter is far more damaging to data quality.

---

Side-by-Side Comparison

Dimension	Algorithm 1: Stroke Boundary Detection	Algorithm 2: Jitter Point Recognition
Problem	Stream segmentation	Quality filtering
Core idea	Time gap anomaly - cut	Direction/magnitude anomaly - flag
Standard	Dynamic (history-based) + Static (120ms fallback)	Dynamic (auto-inferred direction) + Static (500 fallback)
Adaptivity	Strong	Medium
Main risk	Cold-start accuracy; parameter sensitivity	False positives on mixed strokes; device dependency
Explainability	Every cut has a reason	Every jitter point has a reason
Time complexity	$O(n)$	$O(n)$
Position in pipeline	Step 1	Step 2 (runs on Step 1's output)

---

Potential Improvements Worth Thinking About

Fix the cold-start problem. Instead of fully resetting the sliding window when a stroke ends, carry the window state into the new stroke so the adaptive logic is effective from the very first event.

Make quality scoring proportional. Switch from "absolute jitter count multiplied by 20" to "jitter ratio times some factor." A single bad point in a 3-point stroke is far more damaging than in a 200-point stroke.

Auto-calibrate the absolute threshold. Sample real deltaY values at startup and compute a device-specific threshold (e.g., mean + 3 standard deviations), rather than hardcoding 500.

Machine learning as a long-term play. With enough labeled data, a classifier could outperform hand-written rules - especially on edge cases. Of course, that's a much bigger project.

---

Wrapping Up

At its core, this system is a classic signal processing problem: extracting meaningful structure from a noisy raw signal.

Neither algorithm uses any fancy mathematics. The underlying logic is just: observe, compare, decide. Yet this simple logic tackles a problem that genuinely causes headaches in real-world frontend engineering.

Next time you flick your scroll wheel, maybe spare a thought for the quiet logic running in the background - reading your rhythm, filtering your noise, and doing its best to understand what you actually meant to do.