Forem: jack

Is 1000Hz possible in Chrome? Bypassing the Event Loop to test Mouse Polling Rate

jack — Thu, 25 Dec 2025 02:01:48 +0000

As a PC gamer, I've always hated installing 500MB of bloatware (looking at you, Razer Synapse and G-Hub) just to verify if my mouse is actually running at its advertised 1000Hz polling rate.

I asked myself: Why can't I just test this in the browser?

The common answer is: "You can't. The browser is too slow. requestAnimationFrame is capped at your monitor's refresh rate (usually 60Hz or 144Hz)."

Challenge accepted. 🛠️

I spent the last few weeks building https://hardwaretest.org/mouse-polling-rate-test/, a privacy-first diagnostic suite. The hardest part was getting accurate, raw input readings that bypass the visual rendering loop.

Here is how I solved the "1000Hz Problem" in Vanilla JS.

The Problem: Visuals vs. Inputs
Most web animations rely on requestAnimationFrame (rAF). If your monitor is 60Hz, rAF fires every ~16.6ms. If you try to measure a 1000Hz mouse (which sends data every 1ms) inside a rAF loop, you will miss 94% of the data.

We need to decouple the Input Thread from the Render Thread.

The Solution: pointermove + performance.now()
We can't rely on the screen painting. We need to listen to the raw pointermove event, which fires much more frequently than the screen updates in modern browsers (Chrome/Edge handle this effectively via "Coalesced Events" logic, though we want the raw stream).

But standard Date.now() isn't precise enough. It gives us milliseconds. For 1000Hz, we need microseconds.

Enter the High Resolution Time API.

The Code
Here is the simplified logic of how I calculate the instant Polling Rate (Hz):

JavaScript

let lastEventTime = 0;
let pollingRateSamples = [];

window.addEventListener('pointermove', (event) => {
// 1. Get the microsecond-precise timestamp
const currentEventTime = performance.now();

// 2. Calculate the delta (time between two events)
const timeDelta = currentEventTime - lastEventTime;

// 3. Convert to Frequency (Hz)
// Hz = 1000ms / delta
const instantaneousHz = 1000 / timeDelta;

// 4. Filter out noise (idle or super slow movements)
if (instantaneousHz > 10 && instantaneousHz < 8000) {
pollingRateSamples.push(instantaneousHz);
}

lastEventTime = currentEventTime;

// NOTE: Do NOT update the DOM here!
// Updating the UI every 1ms will kill the browser performance.
// Store the data, and visualize it in a separate requestAnimationFrame loop.
});
The "Event Loop" Trap
The tricky part is that browsers try to "group" events to save battery.

If you run a heavy operation inside that pointermove listener, the browser will start throttling the event firing rate to match the frame rate.

The trick is:

Keep the event listener extremely lightweight (just math and array pushing).

De-couple the visualization. Use a separate requestAnimationFrame loop to read from the pollingRateSamples array and draw the graph.

The Result
By separating the input capture from the rendering, I managed to get consistent readings matching local software:

You can try the live demo here: Mouse Polling Rate Test

It also includes a Gamepad Tester (for stick drift) and a Dead Pixel test, all running locally in the browser.

Discussion 💬
I built this to prove that modern Web APIs are powerful enough to replace most "utility" desktop software.

What do you think? Are we at a point where we can finally uninstall those 500MB driver suites, or will native apps always be king for hardware interaction?

Let me know in the comments! 👇

Vibe Coded a Hardware Tester in a Weekend. (Spoiler: The UI took 10 mins, the Physics took 2 days)

jack — Wed, 17 Dec 2025 04:15:46 +0000

The Vibe: I wanted to build a simple, privacy-focused tool to test PC hardware (Mice, Keyboards, Screens) without installing shady .exe files.

The Tool: I opened my AI editor (Cursor/Claude), entered "flow state," and started prompting. My goal was www.hardwaretest.org.

Here is what I learned about the reality of Vibe Coding a tool that requires high-precision hardware interaction.

Where Vibe Coding Shines (The UI) This part felt like magic.

"Make it dark mode." -> Done.

"Give me a grid of clickable colors for dead pixel testing." -> Done.

"Make it responsive for mobile." -> Done.

In about 2 hours, I had a beautiful, functional frontend deployed on Vercel. If I were hand-coding the CSS/Tailwind, this would have taken me a full day.

Where the Vibe Died (The Logic) Then I tried to implement the Keyboard Polling Rate Test. I needed to detect if a gaming keyboard was actually reporting at 1000Hz (1ms latency).

I asked the AI: "Write a script to measure key press intervals." The AI confidently spit out code using standard Date.now() and addEventListener.

The Result? Jittery garbage data. The AI didn't understand that:

The Browser Event Loop is often slower than a high-end keyboard.

Date.now() isn't precise enough for sub-millisecond measurements.

DOM updates (rendering the number) cause layout thrashing that slows down the measurement.

The "Manual Mode" Fix I had to snap out of "Vibe Mode" and put on my Senior Engineer hat. I spent the next 48 hours manually debugging and rewriting the core logic.

Switched to performance.now() for microsecond precision.

Implemented a sliding window average algorithm to smooth out the browser's main thread jitter.

Decoupled the Input Loop (data capture) from the Render Loop (requestAnimationFrame).

The Verdict
Vibe Coding is a force multiplier, but it's not a replacement for domain knowledge.

AI built the vessel (UI, Layout, SEO schema).

I had to build the engine (Timing algorithms, Physics).

The tool is now live and stable. It features a Keyboard Tester, Mouse Double-Click Detector, and a Dead Pixel Fixer (Canvas-based).

Check it out here: 👉 www.hardwaretest.org

I'm curious—has anyone else hit a wall where AI implies "it works" but the underlying physics/logic is completely broken?

I Tried "Vibe Coding" a Hardware Test Site: AI is Powerful, But It's Not Magic (Yet) 🛠️

jack — Tue, 09 Dec 2025 01:35:32 +0000

👋 The Backstory
I want to share a recent "experimental project" of mine: HardwareTest.org.

The motivation was simple: I bought some new peripherals and wanted to test them. But I was fed up with the existing tools—screens full of ads, outdated UIs, or sketchy .exe files that I didn't want to download.

As a self-described "average developer," I recently got brainwashed by the concept of "Vibe Coding" (coding by natural language/AI intuition). I thought, "AI is so strong now. I'll just write the prompts, let the AI write the code, and I'll be done in minutes, right?"

Spoiler Alert: I was too naive. 😂
While AI absolutely lowered the barrier to entry and boosted my speed by 10x, taking a tool from "it works" to "it feels good to use" was full of hidden traps.

🚧 The Real Challenges
Here is a breakdown of the actual struggles I faced while pair-programming with AI:

The Tooling Chaos
My workflow was a bit of a mess. I started with Antigravity (it designed the initial UI), but ran out of credits. I switched to Codex to finish the logic. For the blog content, I used Gemini, but integrating that content back into the project via Codex resulted in a formatting nightmare. It was a lot of back-and-forth "fixing" what the AI broke.
Browser Limitations vs. Physics (The Keyboard Test)
I thought testing Keyboard Polling Rate would be simple: just tell the AI to "write an event listener."

The Reality: I discovered that the browser's Event Loop often can't even keep up with a 1000Hz gaming keyboard. The raw data coming out was jittery and unusable. The Fix: I was forced into dozens of rounds of conversation with the AI. We had to optimize the algorithm, add debounce logic, and implement sliding averages just to get a relatively accurate "Real-time Hz Dashboard" on the web.

The Devil is in the Details (The Mouse Test)
I assumed a mouse test was just listening for onClick. The Reality: To properly test for Double Click issues (a gamer's nightmare) and Scroll Wheel rollback, you need very precise counting logic. Also, the AI kept confusing "Middle Click" (pressing the wheel) with "Scrolling" (spinning the wheel). It took a lot of human intervention to separate those events cleanly.
The SEO Battle
Writing the code was just step one. To get this English-language site indexed by Google, I spent ages wrestling with Schema, FAQ, and JSON-LD. The Insight: AI writes syntactically correct code, but often logically nonsensical SEO tags. This led to Google Search Console errors that I had to manually debug and patch.

✨ The Result

Despite the process being more twisted than I expected, I’m still proud of what this experiment produced.
It became a pure static, ad-free, dark-mode online hardware diagnostic suite — and more importantly, a real-world test of what AI-assisted coding can and cannot do well.

The original experiment is available here:
👉 https://hardwaretest.org

Current Features:

⌨️ Keyboard Test: Visualizer with a real-time Hz polling rate dashboard (and Ghosting/NKRO support).

🖱️ Mouse Test: Left/Right/Middle buttons + Scroll Wheel + Double Click detection.

🖥️ Dead Pixel & Fixer: Standard color cycle test, plus a "High-Frequency Noise Repair" feature built with Canvas.

🎧 Audio Test: Left/Right channel separation + Logarithmic Sweep.

This "Vibe Coding" experience taught me a valuable lesson: AI is an incredibly fast junior developer. It can speed up production by 1000%, but it cannot yet replace the human eye for product details, edge cases, and user experience.

🙏 Feedback Welcome! The site just went live, so there are definitely bugs and rough edges. If you have a moment to try it out, I’d love to hear your feedback in the comments!

Update (Several weeks later)

After the initial launch, I ran into a problem I didn’t expect at all — SEO.

The AI-generated structure worked fine visually, but Google treated most pages as duplicates:

very similar raw HTML
reused meta descriptions
canonical pointing to the homepage

As a result, many URLs were canonicalized away in Google Search Console.

Instead of patching the old structure endlessly, I decided to take a more radical approach:
I extracted the most requested feature — mouse polling rate testing — and rebuilt it as a dedicated mouse polling rate testing tool.

This time, I avoided “AI-generated SEO” entirely and relied on proper SEO fundamentals.
The difference in indexing and visibility was immediately noticeable.

This experience reinforced something important for me:
AI can write code fast, but search engines still reward human judgment and structure.