DEV Community: sgamer宇

Building a Privacy-Friendly AI Music Tool That Runs Entirely in the Browser

sgamer宇 — Sun, 25 Oct 2026 09:59:19 +0000

Building a Privacy-Friendly AI Music Tool That Runs Entirely in the Browser

When people think about AI-powered web applications, they usually imagine a familiar architecture:

The user uploads a file, a backend sends it to an AI service, and the server returns the result.

That approach works, but it isn't the only option.

Modern browsers can perform surprisingly complex machine learning tasks locally.

For certain workloads, this makes it possible to build useful AI applications without sending a user's private file to a processing server.

Music chord recognition is an interesting example.

Let's look at the architecture, technical trade-offs, and user experience challenges involved in running audio analysis directly in the browser.

1. Why Run AI Locally?

Consider an application that detects chord progressions from uploaded audio.

A conventional implementation might look like this:

User selects audio
        ↓
Upload to server
        ↓
Server preprocesses audio
        ↓
AI model runs
        ↓
Return chord predictions
        ↓
Display results

This introduces several challenges.

Large audio uploads consume bandwidth.

Server-side inference requires compute resources.

Users may be uncomfortable uploading private recordings.

And as usage increases, inference costs can become difficult to predict.

An alternative is to move the audio processing and model inference into the browser.

User selects audio
        ↓
Browser decodes audio
        ↓
Extract audio features locally
        ↓
Run downloaded AI model
        ↓
Post-process predictions
        ↓
Display chord timeline

The file doesn't need to leave the user's device for processing.

This changes both the privacy model and the infrastructure economics.

2. Browsers Can Decode Audio Locally

The Web Audio API provides browser-native audio processing capabilities.

For example, you can decode a user-selected audio file into an AudioBuffer:

async function decodeAudio(file) {
  const context = new AudioContext();

  try {
    const bytes = await file.arrayBuffer();

    const audioBuffer =
      await context.decodeAudioData(bytes);

    console.log({
      duration: audioBuffer.duration,
      sampleRate: audioBuffer.sampleRate,
      channels: audioBuffer.numberOfChannels
    });

    return audioBuffer;
  } finally {
    await context.close();
  }
}

This example assumes the selected file uses an audio format supported by the browser.

It doesn't upload the file.

Instead, the browser decodes it locally into audio samples that can be used for further processing.

But decoding is just the first step.

The next challenge is converting the audio into information that a machine learning model can understand.

3. Turning Sound into Musical Features

A raw audio waveform contains changes in sound pressure over time.

A chord recognition system needs to estimate harmonic relationships from those samples.

One common technique is the Constant-Q Transform (CQT).

Unlike a conventional FFT with equally spaced frequency bins, CQT uses logarithmically spaced frequency bins.

This is useful for many musical tasks because musical pitch relationships are logarithmic.

For example, moving up one octave doubles the frequency.

A feature extraction stage can transform the audio into a time-frequency representation:

Audio samples
      ↓
Resampling / preprocessing
      ↓
CQT feature extraction
      ↓
Time-frequency matrix
      ↓
Chord recognition model

The exact preprocessing steps must match what the model expects.

A mismatch in sample rate, normalization, frequency bins, or tensor layout can seriously reduce prediction quality.

This is an important engineering lesson:

A good model is only one part of a good inference pipeline.

4. Running ONNX Models in a Browser

ONNX provides a portable format for representing machine learning models.

With ONNX Runtime Web, a compatible model can execute in the browser using supported backends such as WebAssembly.

A simplified inference flow might look like this:

import * as ort from "onnxruntime-web";

// The model URL and tensor shapes are examples.
// Real applications must match the model's inputs.

const session =
  await ort.InferenceSession.create(
    "/models/chord-model.onnx",
    {
      executionProviders: ["wasm"]
    }
  );

// Input preparation depends on the model.
// The feature matrix must be converted
// into the expected tensor representation.

The difficult part isn't simply loading the ONNX file.

You also need to handle:

Model download and initialization
Audio preprocessing
Tensor creation
Memory usage
Inference execution
Chord label decoding
Prediction smoothing
Timeline generation

And because this work runs on the user's device, performance characteristics vary.

A powerful desktop may handle a model comfortably, while a low-memory mobile device may struggle.

5. Designing the First Model Download

Local AI introduces a user experience problem that traditional web applications don't always have.

The model needs to be downloaded before inference.

Depending on its size and the user's internet connection, this may take noticeable time.

A good interface should make the process understandable.

For example:

[1] Audio selected
      ↓
[2] Model download required
      ↓
[3] Downloading model
      ↓
[4] Initializing AI runtime
      ↓
[5] Preparing audio features
      ↓
[6] Analyzing chords
      ↓
[7] Displaying results

These stages communicate different kinds of work.

A download progress indicator should represent actual network progress when measurable.

An analysis progress indicator should not pretend to provide exact percentages unless the application can calculate them.

And if the model can be cached, the interface should explain that subsequent use may not require downloading the same resources again.

Good feedback matters because users don't know what the browser is doing behind the scenes.

6. A Real Example: ChordFold

One example of a browser-based approach is ChordFold, an AI chord finder for analyzing music recordings.

It uses a BTC-based chord recognition model with ONNX Runtime.

Users can select MP3, WAV, or other browser-supported audio files within the site's size and duration limits.

The audio is decoded and analyzed locally on their device, rather than being uploaded to a remote inference server.

The interface allows users to:

Explore estimated chord progressions
Follow chord changes over time
Replay sections of the recording
View supported guitar chord diagrams
Inspect corresponding piano notes

This is particularly interesting because the output isn't just a static prediction.

The chord labels are connected to the original audio, creating a practical tool for listening and musical exploration.

7. Why Chord Recognition Isn't Perfect

Automatic chord recognition is a difficult problem even with deep learning.

An audio recording might contain several instruments playing simultaneously.

Guitar distortion introduces additional harmonics.

The melody may contain notes outside the underlying chord.

Extended chords and inversions create further ambiguity.

For example, a simple progression:

C → G → Am → F

might be relatively straightforward in a clean piano recording.

But a dense arrangement with vocals, bass, electric guitars, and effects can produce much more ambiguous features.

There's also a timing problem.

The model may identify the correct chord but place the transition slightly too early or late.

This is why a useful interface should let people inspect the results rather than treating the model's predictions as unquestionable facts.

For music learning, a partially correct chord timeline can still be valuable.

It gives users a starting point for listening, checking, and practicing.

8. The Trade-Offs of Local Inference

Browser-based AI isn't automatically better for every application.

It has meaningful advantages:

Privacy

Selected user files can remain on the device.

Predictable server inference costs

The server doesn't need to process every uploaded recording.

Lower dependency on remote inference availability

Once the application and model resources are loaded, inference can happen locally.

But the disadvantages matter too.

Initial download

Models may require a significant download.

Device limitations

Memory and CPU performance vary dramatically.

Browser compatibility

Not every browser supports the same acceleration backends.

Resource management

Large audio files and intermediate feature arrays can use substantial memory.

Model updates

Changing the model requires managing new resources and potentially invalidating cached versions.

A robust product must handle these trade-offs carefully.

9. When Should You Consider This Architecture?

Local inference makes sense when:

The model fits reasonably within client-device limits.
Data privacy is important.
Inference doesn't require extremely large hardware resources.
The application can tolerate device-dependent performance.
You want to avoid a server inference request for every user action.

Audio analysis, image classification, certain text-processing tasks, and other specialized workloads may fit this pattern.

However, large generative models or applications requiring powerful GPUs may still benefit from server-side infrastructure.

The correct choice depends on the workload, user devices, and product requirements.

Final Thoughts

Browser-based AI has become a practical architecture for more than simple demonstrations.

With the Web Audio API, machine learning runtimes, and efficient preprocessing, web applications can perform meaningful analysis locally.

A music chord finder is a useful example because it combines several engineering challenges:

Audio decoding
Musical feature extraction
Model inference
Temporal prediction processing
Interactive visualization
Privacy and memory management

The result can be an application that doesn't require users to upload personal recordings to a processing server.

If you're interested in seeing this approach from the user's perspective, you can explore ChordFold's browser-based chord finder.

It demonstrates how local AI can turn an ordinary audio file into an interactive musical learning tool.

For developers, the larger opportunity is clear: not every AI feature needs a cloud inference endpoint.

Sometimes, the browser itself is enough.

# Your Browser Says 60 FPS — But Is Your GPU Actually Fast?

sgamer宇 — Sun, 25 Oct 2026 09:58:19 +0000

Your Browser Says 60 FPS — But Is Your GPU Actually Fast?

You open a browser performance test and see a steady 60 FPS.

Does that mean your graphics card is powerful?

Not necessarily.

This is a surprisingly common misunderstanding when evaluating browser graphics performance.

A smooth animation, a GPU stress benchmark, and a WebGPU compatibility check all measure different things.

Let's explore the differences and build a small frame-timing experiment using JavaScript.

1. What Does Browser FPS Actually Measure?

Browsers expose requestAnimationFrame(), an API that schedules callbacks before visual updates.

Here's a simple example:

let lastTime = performance.now();

function frame(now) {
  const delta = now - lastTime;

  if (delta > 0) {
    const fps = 1000 / delta;
    console.log(`FPS: ${fps.toFixed(1)}`);
  }

  lastTime = now;
  requestAnimationFrame(frame);
}

requestAnimationFrame(frame);

This measures the interval between animation callbacks.

It can help you investigate animation timing.

But it doesn't directly measure the maximum rendering capability of your GPU.

Why?

Because requestAnimationFrame() is influenced by the browser's rendering schedule and the display's refresh rate.

On a typical 60 Hz display, a lightweight animation may produce approximately 60 callbacks per second.

That doesn't mean the GPU couldn't render a much heavier or lighter workload at a different rate.

2. Build a More Useful Frame-Timing Test

Instead of only displaying an instantaneous FPS value, collect multiple frame intervals.

const intervals = [];

let previousTime;
let startTime;

function measureFrame(now) {
  if (startTime === undefined) {
    startTime = now;
    previousTime = now;

    requestAnimationFrame(measureFrame);
    return;
  }

  intervals.push(now - previousTime);
  previousTime = now;

  if (now - startTime < 5000) {
    requestAnimationFrame(measureFrame);
    return;
  }

  const total = intervals.reduce(
    (sum, value) => sum + value,
    0
  );

  const averageFPS =
    (intervals.length * 1000) / total;

  const sorted = [...intervals].sort(
    (a, b) => b - a
  );

  const slowCount = Math.max(
    1,
    Math.ceil(sorted.length * 0.01)
  );

  const slowIntervals = sorted.slice(
    0,
    slowCount
  );

  const slowMean =
    slowIntervals.reduce(
      (sum, value) => sum + value,
      0
    ) / slowIntervals.length;

  const onePercentLow = 1000 / slowMean;

  console.log({
    averageFPS,
    onePercentLow,
    frameCount: intervals.length
  });
}

requestAnimationFrame(measureFrame);

This collects roughly five seconds of animation intervals.

It then calculates two useful metrics:

Average FPS: The number of completed intervals divided by total measurement time.

1% Low FPS: An estimate based on the slowest 1% of recorded intervals.

Be careful with short measurements. Tail metrics are especially noisy when the sample contains relatively few frames.

This example is an educational timing experiment, not a calibrated GPU benchmark.

3. Why Frame Time Matters More Than You Think

Consider two hypothetical rendering sessions.

Session A

Average FPS: 60
Most frames: 16–17 ms
Few large spikes

Session B

Average FPS: 60
Frequent irregular intervals
Occasional 50–100 ms delays

Both report the same average FPS, but Session B may feel much less responsive.

This is why frame-time consistency is important.

A 16.7 ms interval corresponds to approximately 60 FPS.

A 33.3 ms interval corresponds to approximately 30 FPS.

And a 100 ms interruption can create a noticeable pause.

When investigating stuttering, don't focus only on average frame rate.

Inspect the distribution of frame intervals and repeat your measurements under similar conditions.

4. A Lightweight FPS Test Is Not a GPU Stress Test

This is the most important distinction.

A simple animation loop might barely use the GPU.

Even if the browser updates smoothly at 60 FPS, the test may not be generating enough rendering work to meaningfully challenge the graphics hardware.

A proper graphics stress workload needs to perform sustained rendering operations.

Depending on the implementation, this can involve:

Shader execution
Procedural geometry
Fragment processing
High-resolution rendering
Repeated frame submission

The workload should remain consistent enough that results can be compared.

For example, WebGPUStress provides a browser-based WebGL stress test with configurable resolution, quality, duration, and target FPS.

It reports metrics including average FPS, 1% low FPS, dropped frames, and frame-time consistency.

The test is useful for observing how a browser handles sustained graphics work.

However, it cannot directly measure GPU temperature or certify hardware stability.

5. WebGPU Compatibility Is Another Separate Question

WebGPU is a modern browser API for graphics and compute workloads.

You can check whether the API exists:

console.log(Boolean(navigator.gpu));

But API availability is not the same as successful execution.

A more useful compatibility test needs to verify several operations:

Request a GPU adapter.
Create a GPU device.
Compile a WGSL shader.
Execute a rendering pipeline.
Run a compute workload.
Verify the resulting output.

The WebGPU compatibility checker performs these kinds of checks directly in the browser.

That helps distinguish a missing API from a failure during device creation, shader compilation, or pipeline execution.

But passing the test doesn't prove that your GPU is faster than another GPU.

Compatibility and performance are separate measurements.

6. How to Run a Meaningful Comparison

Suppose you've just updated your graphics driver and want to know whether browser GPU performance changed.

A reasonable approach is:

Before updating:

Use a fixed browser version.
Choose a benchmark profile.
Close unnecessary GPU-intensive applications.
Run the test several times.
Save the results.

After updating:

Keep the same hardware and power mode.
Use the same benchmark profile.
Repeat the runs.
Compare both averages and frame-time consistency.

Try to change only the variable you want to evaluate.

For laptop testing, keep the device plugged in and use a consistent power profile.

For sustained tests, pay attention to whether performance remains steady or gradually declines.

And if you suspect thermal throttling, use separate monitoring software to check temperatures and clock speeds.

7. Common Benchmarking Traps

Background tabs

Browsers can throttle or pause background animation callbacks.

Display refresh limits

A frame-timing test may reflect display scheduling rather than maximum GPU throughput.

Different rendering APIs

WebGL, WebGPU, and Canvas 2D workloads should not be treated as interchangeable.

Short measurement windows

A few seconds of data may not capture meaningful sustained performance behavior.

Different browsers

Browser implementations and graphics backends can affect results.

No consistent workload

Comparing FPS values from two unrelated animations doesn't establish which GPU is faster.

Final Thoughts

When someone says their browser runs at 60 FPS, the first question should be:

What exactly was being measured?

A lightweight JavaScript animation can help measure callback timing.

A WebGL stress benchmark can investigate rendering performance under a defined load.

A WebGPU compatibility test can verify whether modern graphics and compute operations actually work.

These tools answer different questions.

Understanding those differences makes browser performance testing much more useful, whether you're debugging a graphics application, comparing driver changes, or investigating inconsistent rendering performance.

If you want to experiment with sustained browser graphics workloads, you can try WebGPUStress without installing a separate benchmarking application.

Why Your Website Prints Incorrectly: 6 CSS Print Problems and How to Debug Them

sgamer宇 — Sun, 25 Oct 2026 09:57:42 +0000

You build a beautiful invoice page. It looks perfect in Chrome.

Then someone presses Ctrl + P.

Suddenly, the table breaks across pages, background colors disappear, and the right edge of the document gets cut off.

Sound familiar?

Printing is one of the most overlooked parts of frontend development. Browsers are optimized for screens, but printed documents have fixed dimensions, physical margins, and very different layout constraints.

Here are six common problems I've encountered when working with printable web pages, along with practical ways to debug them.

1. Your Screen Layout Is Not Your Print Layout

The browser doesn't automatically convert a responsive screen layout into a well-designed printed document.

A layout that fits a 1440px monitor might be completely unsuitable for A4 paper.

The first step is to create print-specific styles:

@media print {
  .navigation,
  .sidebar,
  .no-print {
    display: none !important;
  }

  body {
    margin: 0;
    background: white;
    color: black;
  }

  .document {
    width: 100%;
    max-width: none;
    box-shadow: none;
  }
}

This removes interface elements that make sense on a screen but not on paper.

It also prevents decorative shadows and fixed-width containers from creating unexpected printed layouts.

The important thing is to treat the printable document as its own output format.

2. A4 and US Letter Are Not Interchangeable

One of the easiest mistakes is designing for one paper size and printing on another.

A4 measures 210 × 297 mm.

US Letter measures 8.5 × 11 inches, approximately 216 × 279 mm.

The difference may seem small, but it becomes significant when you're printing invoices, forms, or documents with precise page boundaries.

You can control page margins with the CSS @page rule:

@page {
  margin: 12mm;
}

You can also request a specific paper size when that is appropriate:

@page {
  size: A4;
  margin: 12mm;
}

However, the browser and printer settings can still affect the final output.

Don't assume that specifying size: A4 guarantees the user's physical printer contains A4 paper.

For applications serving international audiences, letting users select the intended paper size is usually a better approach.

3. Browser Print Scaling Can Break Your Layout

Suppose your CSS is correct, but the printed document still looks smaller than expected.

The problem might not be your code.

Browser print dialogs often provide scaling options such as:

Default
Fit to page
Actual size
Custom percentage

These settings can change the dimensions of the resulting document.

A useful debugging technique is to compare a known reference sheet against the same printer settings.

For example, PrintPageCheck provides free printable test pages for checking paper margins, scaling, text, and fine lines.

It supports A4 and US Letter with both browser printing and downloadable PDFs.

I find this kind of reference useful because it separates two possible problems:

Problem A: The printer or print dialog is applying unexpected scaling.

Problem B: The application's CSS layout is incorrect.

If even a reference sheet prints at the wrong size, changing your application's CSS probably isn't the first thing to investigate.

4. Background Colors Disappear

This issue is particularly common with dashboards, charts, and invoices that use colored table headers.

Your website displays a colored section correctly, but the printed document has a white background.

Browsers may omit background graphics depending on print settings.

You can request more faithful color reproduction:

@media print {
  .invoice-header {
    background: #e8eef5;
    print-color-adjust: exact;
    -webkit-print-color-adjust: exact;
  }
}

But here's the catch:

print-color-adjust: exact is not a guarantee.

Browser settings, printer drivers, and device limitations may still affect the output.

For important documents, avoid relying exclusively on background colors to communicate essential information.

Use borders, labels, text, and sufficient contrast so the document remains understandable in black and white.

5. Tables Break Across Pages

A long HTML table may look fine on a screen but become difficult to read when printed.

For example, a row might be split between two pages.

You can request better pagination behavior:

@media print {
  thead {
    display: table-header-group;
  }

  tr {
    break-inside: avoid;
    page-break-inside: avoid;
  }
}

This encourages browsers to keep rows together and repeat table headers where supported.

However, page-break behavior varies by browser and content structure.

If a single row is taller than the available page space, the browser may still need to split or overflow content.

Always test realistic datasets rather than only a short example table.

6. Printed Text Looks Blurry or Thin

Not every printing problem comes from CSS.

Sometimes the page structure is correct, but the physical output contains broken letters, inconsistent lines, or faint text.

Possible causes include printer quality settings, paper, consumables, or hardware-related issues.

A useful way to investigate is to print a page containing several font sizes and line thicknesses.

Look for:

Small characters that lose detail
Horizontal lines with unexpected gaps
Vertical strokes that appear faint
Irregular text darkness
Differences between regular and bold text

If these problems also appear on a dedicated text and fine-line test sheet, the issue may be outside your web application.

Use the printer manufacturer's diagnostic procedures to investigate further.

A Practical Print Debugging Workflow

Instead of randomly changing CSS properties, I recommend this process:

Step 1: Verify the HTML layout

Make sure the content is structured correctly before applying print-specific styling.

Step 2: Test print media rules

Use your browser's developer tools to inspect styles under print media where supported.

Step 3: Check the paper size

Confirm that the CSS, print dialog, and physical paper are consistent.

Step 4: Check scaling

Compare Actual Size against automatic fitting when investigating dimension problems.

Step 5: Print a reference page

Use a dedicated printer test page to distinguish a browser layout issue from a physical output issue.

Step 6: Test multiple browsers

Chrome, Firefox, and Safari can differ in their print rendering behavior.

Step 7: Test the actual printer

A PDF preview is useful, but it cannot guarantee what a physical printer will produce.

Final Thoughts

Printing from the web is more complicated than displaying content on a screen.

There are several layers involved:

HTML structure
CSS print styles
Browser print rendering
Print dialog configuration
Printer driver behavior
Physical printer output

Debugging becomes much easier when you investigate each layer separately.

If you're building printable web applications, use controlled test documents and consistent printer settings rather than guessing.

A reference tool such as PrintPageCheck can help you check the physical output, while your browser's developer tools help you investigate the CSS.

Good print design isn't just about making the preview look right.

It's about making the final document reliable.

PondMath

sgamer宇 — Wed, 30 Sep 2026 08:21:56 +0000

I recently built PondMath, a free browser game that turns mental math practice into a small frog adventure.

The basic idea is simple:

Solve a math problem correctly, and the frog moves forward across the pond.

Instead of presenting arithmetic as another worksheet or calculator-style interface, I wanted the practice itself to feel more like a lightweight web game.

PondMath currently includes:

Addition
Subtraction
Multiplication
Division
Mixed arithmetic
Endless Challenge
A new Daily Challenge

There’s no signup and nothing to install — you can just open it in the browser and start playing.

A surprisingly interesting design problem was figuring out how much “game” to add.

Too little, and it feels like a normal math worksheet with a frog pasted on top.

Too much, and the game starts distracting from the actual mental math practice.

I ended up keeping the core loop very simple: solve → jump → progress.

I’m continuing to experiment with level design, difficulty progression, animations, and ways to make repeated practice feel less repetitive.

If you’d like to try it:

https://pondmath.com/

Feedback on the game loop or difficulty progression would be really useful.

DeskRoster

sgamer宇 — Wed, 30 Sep 2026 08:21:44 +0000

I’ve been working on DeskRoster, a free browser-based classroom seating chart maker designed for teachers.

The idea came from a pretty simple problem: creating a classroom seating plan often means moving names around manually, rebuilding desk layouts, or working with tools that are much more complicated than the task itself.

So I wanted to make something lightweight.

With DeskRoster, teachers can:

Add or paste a student list
Arrange desks to match the classroom
Generate seating assignments
Add seating preferences and constraints
Drag students around to fine-tune the result
Print or save the finished seating chart

The tool runs directly in the browser, and there’s no account required.

One of the more interesting parts to build was balancing automatic seat generation with manual control. A fully random seating chart is easy to generate, but real classrooms have constraints: some students need to sit apart, some should stay in the same group, and teachers often want to lock certain seats before generating the rest.

I’m still improving the workflow and would especially love feedback from anyone who has built tools involving drag-and-drop layouts or constraint-based assignment.

You can try it here:

https://deskroster.com/

I Built a Free Collection of Focus Games That Runs Entirely in the Browser

sgamer宇 — Wed, 16 Sep 2026 10:03:11 +0000

I Built a Free Collection of Focus Games That Runs Entirely in the Browser

I recently built DailyFocus Games, a free collection of short browser-based games for practicing attention, memory, reaction speed, and cognitive control.

The idea started from a very simple question:

Can focus practice feel more like playing a quick game than starting a complicated training program?

I wanted something you could open in a browser, play for a few minutes, and leave.

No account.

No installation.

No onboarding flow.

Just choose a game and start.

What is DailyFocus Games?

DailyFocus Games currently includes short interactive exercises such as:

Stroop Test
Schulte Table
Visual Search
Reaction Time
Go / No-Go
N-Back
Visual Memory
Sequence Memory
Number Memory
Task Switching

Users can practice any game individually or start a Daily Challenge made up of several different games.

The project is available here:

👉 DailyFocus Games

Why browser-based?

A lot of cognitive and focus apps immediately ask users to:

Download an app
Create an account
Start a subscription
Complete onboarding
Track a long-term program

That can make sense for some products, but I wanted DailyFocus to feel more lightweight.

The core workflow is simply:

Open → Choose a game → Play

This also means the games work across desktop and mobile devices without installing anything.

Designing very short games

One interesting part of the project has been deciding how long each game should last.

A focus game doesn't necessarily become better just because it lasts longer.

In fact, some exercises work better as short challenges.

For example, a reaction-time game can give useful feedback in seconds.

A Stroop task can become repetitive if a session is too long.

A visual-search game needs enough rounds to feel challenging without turning into a chore.

So instead of forcing every game into the same session length, each game has its own natural rhythm.

Different games practice different things

I also didn't want the site to become a collection of games that all feel identical.

Different tasks emphasize different skills.

For example:

Stroop

You need to respond to the color while ignoring the written word.

This creates interference between two competing signals.

Schulte Table

You visually search for numbers in sequence across a grid.

The challenge is scanning efficiently without losing your place.

Go / No-Go

You respond to some signals while withholding your response to others.

N-Back

You compare the current stimulus with something shown several steps earlier.

Visual Search

You find a target among distracting items.

The mechanics are simple, but each game creates a different kind of mental challenge.

A Daily Challenge instead of a fixed routine

Another feature I wanted was a Daily Challenge.

Rather than asking users to repeat exactly the same sequence every day, DailyFocus can combine several short games into one session.

This makes the experience feel less repetitive while still keeping it simple.

You can also ignore the Daily Challenge completely and practice any individual game whenever you want.

I think that balance is important.

The site suggests a starting point, but it doesn't force users into a rigid program.

No account required

DailyFocus currently doesn't require an account.

This is intentional.

For a lightweight browser game, I think requiring registration before someone can play adds unnecessary friction.

Users don't need to provide an email address just to try a Stroop test or reaction-time game.

If the product eventually needs cross-device history or deeper progress tracking, accounts might make sense.

For now, the priority is making the games immediately playable.

Keeping the claims realistic

Another important decision was how to describe the project.

DailyFocus is not a medical treatment or diagnostic tool.

I don't want to claim that playing a browser game will treat ADHD, dramatically increase intelligence, or produce guaranteed cognitive improvements.

The site is better described as a collection of short focus and cognitive exercises.

Users can play, challenge themselves, and practice different types of attention-related tasks.

That's enough.

Building small games as web products

This project has also reminded me why I like browser-based tools.

A user can discover a page from search, open it, understand the interaction, and start using it immediately.

There is something nice about software that doesn't require commitment.

No installation.

No account.

No setup.

A game can simply exist at a URL.

What's next?

I'm continuing to add and improve games while trying to keep the overall experience simple.

The main things I'm currently thinking about are:

Making individual games more enjoyable
Improving mobile interactions
Better difficulty progression
More variety in Daily Challenges
Adding new game mechanics without making the site feel cluttered

If you want to try the project:

👉 DailyFocus Games — Free Focus Games

I'd especially be interested in feedback on which game feels the most engaging and which one you'd improve first.

I Built a Free Browser-Based Eye Test Toolkit

sgamer宇 — Mon, 07 Sep 2026 08:37:30 +0000

I recently built EyeTest Online, a free browser-based toolkit for basic vision screening.

The idea was simple: many common eye checks can be presented as lightweight interactive web tools without requiring an app, account, or installation.

What's included

EyeTest Online currently includes several types of vision screening tools:

Visual acuity tests
Color blindness tests
Astigmatism tests
Contrast sensitivity tests
Amsler grid tests
Peripheral vision checks
Near vision tests

Everything runs directly in the browser and works on both desktop and mobile devices.

Why build it as a web app?

I wanted the experience to be as simple as possible:

Open the website
Choose a test
Follow the calibration instructions
Start immediately

No account creation and no installation.

For tools like this, reducing friction matters a lot. Someone who just wants to do a quick vision check shouldn't need to download an app first.

An important limitation

These tools are designed for screening and general awareness only.

They are not medical diagnoses and should not replace an examination by an optometrist or ophthalmologist.

Try it

You can try the tests here:

👉 EyeTest Online

I'm continuing to improve the calibration, mobile experience, and accessibility of the tests.

Feedback is welcome, especially from people interested in accessibility, health tools, or browser-based utilities.

I Built a Tiny Decision Tool for People Who Overthink Small Choices

sgamer宇 — Tue, 04 Aug 2026 10:41:45 +0000

Sometimes the hardest decisions are not the important ones.

They are things like:

Should I order takeout?
Should I go for a walk?
Should I text them?
Should I start working now?
Should I buy another coffee?

None of these decisions deserves a spreadsheet, a productivity framework, or a 30-minute discussion with an AI assistant.

But somehow, we still get stuck.

So I built Tiny Fate Toolbox, a small collection of playful tools for everyday decisions.

The first tool is a simple Yes or No Wheel.

You think of a question, spin the wheel, and it lands on YES or NO.

That is basically it.

The goal was not to make decisions for people

A random wheel obviously does not know which choice is best.

It cannot predict the future, understand your relationships, or decide whether you should change jobs.

What it can do is interrupt an overthinking loop.

There is also a small psychological trick hidden inside the experience.

Imagine asking:

Should I go out tonight?

The wheel lands on YES.

Perhaps you immediately feel tired and wish it had landed on NO.

That reaction may be more useful than the result itself. The wheel did not discover the answer. It helped you notice the answer you were already hoping for.

That became the main idea behind the product:

The random answer starts the reaction. Your reaction helps reveal your preference.

Keeping the interaction deliberately simple

My first design rule was to remove unnecessary steps.

You can type a question, but you do not have to. You can keep it completely private, think about it for a moment, and press Spin.

The wheel has two YES sections and two NO sections, giving both answers an equal chance.

I also wanted the animation to feel playful without making the user wait forever. Many wheel tools turn a tiny interaction into a miniature casino experience, with long animations, loud effects, pop-ups, and confetti everywhere.

For this project, the interaction needed to feel lighter:

Ask one clear question.
Spin once.
See the result.
Notice your first reaction.

No account is required, and recent results can remain locally on the current device rather than being attached to a user profile.

Randomness is more confusing than it looks

Building a random wheel also reminded me that people have strong expectations about what “random” should look like.

For example, a user might spin the wheel five times and receive:

YES
YES
YES
NO
YES

It is easy to look at that sequence and assume something is wrong.

But fair randomness does not promise that results will alternate neatly. A 50/50 process can still produce several identical results in a row.

The browser generates a fresh random value for each spin. That value determines the selected result, and the animation then lands on the corresponding section.

Previous spins do not make the next YES or NO more likely.

I added guides explaining this process because transparency felt more useful than simply writing “100% random” in large marketing text.

A simple tool can still explain how it works.

Expanding beyond YES or NO

A binary answer works well for some decisions, but not every decision has only two options.

So Tiny Fate Toolbox is growing into a small set of focused tools:

Custom Wheel

Create a wheel with several choices, such as:

Pizza
Tacos
Pasta
Sushi

It is useful when the options matter more than YES or NO.

Random Name Picker

Choose someone from a class, team, giveaway, meeting, or group of friends.

The goal is to make the selection visible and easy to understand rather than returning a mysterious name from a black box.

Weighted Wheel

Sometimes choices should not have equal probabilities.

Perhaps tonight’s options are:

Go for a walk: 60%
Watch a movie: 30%
Take a nap: 10%

A weighted wheel lets the user represent that preference while still leaving the final result to chance.

Designing for harmless decisions

One important part of the project was deciding what the tool should not encourage.

A random wheel is fine for choosing dinner, selecting a game, breaking a friendly tie, or escaping a low-stakes overthinking loop.

It should not be used for:

Medical treatment
Financial investments
Legal decisions
Personal safety
Emergencies
Serious choices affecting another person

This might seem obvious, but product copy shapes how a tool is used.

I did not want to present randomness as wisdom or package a spinner as an artificial fortune teller. The product is intentionally framed as entertainment and a playful decision prompt.

For important decisions, the boring answer is still the correct one: gather information, think carefully, and speak to someone qualified when necessary.

Small tools can still deserve thoughtful design

Tiny web tools are easy to underestimate.

The core feature might take only a few seconds to understand, but the surrounding details still matter:

Does it work well on mobile?
Is the main interaction immediately visible?
Does the animation match the result?
Can users understand the probability?
Is the interface usable without creating an account?
Does the page explain when the tool is useful?
Does it avoid pretending to solve problems it cannot solve?

A product does not need hundreds of features to be useful.

Sometimes it only needs to do one small thing clearly, quickly, and pleasantly.

Try it

You can try the project here:

👉 Tiny Fate Toolbox — Yes or No Wheel

Ask it something harmless, spin once, and pay attention to your reaction.

And yes, repeatedly spinning until you get the answer you wanted is also an answer.

Suggested DEV Community tags: webdev, javascript, indiehackers, productivity

I Built a Free Drawing Grid Maker for Artists

sgamer宇 — Tue, 23 Jun 2026 09:52:52 +0000

Drawing from a reference photo looks simple until you actually try it.

A face can be slightly too wide.
The eyes can sit too high.
The angle of an object can feel wrong even when you cannot explain why.

For beginners, these small proportion errors can make an entire drawing feel inaccurate.

One of the oldest solutions is the grid drawing method: divide the reference image into smaller sections, then reproduce each section one at a time.

The method is simple, but preparing the grid is often more annoying than the drawing itself.

That is why I built DrawGrid.

👉 Try DrawGrid

What is DrawGrid?

DrawGrid is a free browser-based grid maker for artists.

You can upload a reference image, place a customizable grid over it, and export the result for drawing practice.

There is no account required, and the tool works directly in the browser.

The basic workflow is:

Upload a reference photo
Choose a grid style
Adjust the rows, columns, color, opacity, and line thickness
Add labels or subdivisions
Export the gridded reference image
Create a matching blank practice sheet

The goal is to make the grid drawing method fast enough that artists can start practicing immediately.

More than a basic grid overlay

While building DrawGrid, I realized that artists do not always need the same type of guide.

A portrait artist may need facial proportion lines.

A landscape artist may need composition guides.

A beginner studying light may need a simplified value reference.

So DrawGrid includes a growing library of drawing guides, including:

Square drawing grids
Numbered grids
Subdivided grids
Portrait proportion guides
Composition guides
Perspective guides
Value and shadow studies
Outline and contour references
Color study guides
Printable practice sheets

Instead of being only an image grid generator, I want DrawGrid to become a practical reference preparation tool for different drawing exercises.

Customizable grid settings

Different drawings require different grids.

A detailed portrait may need many small cells, while a simple sketch may only need a few large sections.

DrawGrid lets you adjust settings such as:

Number of rows
Number of columns
Grid line thickness
Grid line color
Grid opacity
Cell numbering
Subdivision lines
Grid rotation
Labels and guides

The preview updates directly in the editor, so you can experiment before exporting the final image.

Printable practice sheets

One feature I especially wanted was the ability to create a matching blank grid.

Many grid tools only place lines over the original photo. The artist then has to manually recreate the same grid on paper or in another application.

DrawGrid can generate both:

A gridded reference image
A corresponding blank practice grid

This makes it easier to print both pages and start drawing without additional setup.

Privacy-friendly image processing

Reference photos can sometimes be personal.

Because of that, DrawGrid processes images locally in the browser. The image does not need to be uploaded to a remote server just to add grid lines.

This also makes the editing experience faster because users can immediately preview changes.

Who is it for?

DrawGrid can be useful for:

Beginner artists learning proportions
Portrait artists working from photographs
Art students practicing observation
Teachers preparing drawing exercises
Mural artists enlarging designs
Illustrators studying composition
Craft creators transferring patterns
Anyone learning the grid drawing method

Even experienced artists sometimes use grids when accuracy or scale is especially important.

Why I built it

There are already grid overlay tools online, but many of them feel limited.

Some only provide a basic grid.

Some have difficult controls.

Others require sign-up, upload images to a server, or place the useful settings across several different pages.

I wanted to create something that feels more like a lightweight artist workspace:

Open the website
Upload an image
Select a guide
Adjust the result
Export it

No complicated workflow.

What I am working on next

DrawGrid is still evolving.

Some ideas I am exploring include:

More portrait construction guides
Better perspective overlays
Custom paper sizes
Improved mobile controls
Additional printable worksheets
Presets for common drawing exercises
More composition guide templates

Feedback from artists will help decide which features should be built first.

Try it

You can use DrawGrid for free here:

👉 https://drawgrid.org/

I would love to hear:

What type of grid do you usually use?
Which drawing guides would be most useful?
Do you prefer drawing digitally or on printed paper?

Thanks for checking it out.

I Built a Browser-Based GPU Stress Test That Runs Without Downloads

sgamer宇 — Mon, 15 Jun 2026 13:57:46 +0000

Most GPU stress-testing tools require users to download and install a desktop application.

That makes sense for detailed hardware diagnostics, but sometimes you only need a quick answer:

Is hardware acceleration working?
Does performance drop after the GPU heats up?
Is an overclock obviously unstable?
Are frame-time spikes causing visible stutter?
Is a laptop slowing down under sustained load?

So I built WebGPUStress, a browser-based GPU stress test powered by WebGL.

What it does

The tool runs a sustained shader workload directly inside the browser and records several performance signals:

Average FPS
1% Low FPS
Frame-time stability
Dropped-frame ratio
Performance decay during longer runs
An overall stability score

You can choose the duration, resolution, quality level, and target frame rate.

There are also presets for common situations:

Quick Health Check — a short test for obvious problems
Thermal Soak — a longer workload for detecting performance loss after heat builds up
FPS Drop Check — useful when games feel less smooth than the average FPS suggests

Why not show only an FPS score?

A high average FPS does not always mean the experience is stable.

For example, a GPU might average 60 FPS while regularly dropping into the 30s. It may also perform well during the first minute and slow down once the cooling system becomes saturated.

That is why the test also tracks 1% lows, frame-time consistency, and dropped frames.

The goal is not to produce one impressive benchmark number. It is to show whether performance remains consistent over time.

Useful scenarios

I designed the tool for quick checks such as:

Testing an overclock

A game might run normally for a few minutes while a longer sustained workload reveals artifacts, crashes, or unstable frame pacing.

Checking laptop throttling

Some laptops start fast but lose performance after several minutes. Comparing the beginning and end of a longer run can help reveal that pattern.

Diagnosing gaming stutter

When average FPS looks normal but gameplay still feels uneven, 1% lows and frame-time stability can provide more useful clues.

Verifying GPU acceleration

It can also provide a quick sanity check for virtual machines, remote desktop environments, and newly configured systems.

Limitations

Because this runs inside a browser, it is not a replacement for tools such as FurMark, MSI Afterburner, GPU-Z, or native hardware monitoring software.

Browsers cannot directly expose GPU temperature, voltage, power consumption, or fan speed. Results can also be affected by the browser, graphics driver, power mode, background applications, and whether the tab remains active.

I see it as a fast first-pass diagnostic tool rather than a complete hardware certification suite.

Try it

You can run the test here:

online gpu test

No download, account, plugin, or executable is required.

I would especially appreciate feedback about:

Performance on different browsers and GPUs
Whether the result explanations are clear
Additional benchmark profiles you would find useful
Metrics that should be added or improved

The project is still evolving, so real-world testing and developer feedback would be genuinely useful.

I Built a Simple Online Tone Generator That Runs Directly in the Browser

sgamer宇 — Fri, 12 Jun 2026 14:11:23 +0000

Recently I built a small browser-based audio tool called TonePanel:

👉 https://tonepanel.org

It is an online tone generator that lets you play steady tones from 20 Hz to 20 kHz directly in the browser. You can switch between common waveforms like sine, square, sawtooth, and triangle, without installing anything.

The idea was simple: I wanted a clean tool for quick audio checks — something useful for testing speakers, headphones, frequency response, or just understanding how different Hz ranges sound.

Why I made it

A lot of tone generator tools work, but many of them feel either too old, too cluttered, or too technical for casual users.

So I wanted to make something that feels more like a small control panel:

choose a frequency
press play
adjust the sound
switch waveform
stop when done

No account, no setup, no download.

What it can be used for

TonePanel can be useful for:

speaker testing
headphone checks
comparing low / mid / high frequencies
basic audio experiments
instrument reference tones
learning what different waveforms sound like

For example, a sine wave is usually the best starting point if you want to hear one clean frequency. Square, sawtooth, and triangle waves sound more “textured” because they contain additional harmonics.

Built for the browser

The tool runs locally in the browser, which makes it lightweight and easy to use. You just open the page and play a tone.

I’m also planning to expand it with more focused pages, such as:

Frequency Generator
Hz Generator
speaker test tools
sweep tone tools
simple educational guides about sound frequencies
A small safety note

Always start with low volume, especially when using headphones. High or very low frequencies can feel uncomfortable quickly.

Try it

Here is the tool:

https://tonepanel.org

Would love to hear feedback from anyone who works with audio, music, speakers, headphones, or browser-based tools.

I Built a Simple Omegaverse Quiz Website

sgamer宇 — Tue, 12 May 2026 07:57:30 +0000

I recently built a small web project called OmegaverseTypes.org.

It is a simple Omegaverse Quiz that helps users discover whether they are closer to Alpha, Beta, Omega, or Hybrid based on a short set of personality-style questions.

The site is live here:

https://omegaversetypes.org/

Why I Built It

I noticed that people search for terms like:

Omegaverse Quiz
ABO Test
Alpha Beta Omega Quiz
Omegaverse Type Test

But many existing quiz-style pages feel a bit outdated, cluttered, or unclear.

So I wanted to build something cleaner and easier to use.

The goal was simple:

Let users open the page, start the quiz immediately, answer a few questions, and get a clear result without signing up.

No login.
No complicated onboarding.
No unnecessary friction.

Just a lightweight interactive quiz.

What the Quiz Does

The quiz asks users a short series of questions related to social energy, pressure, relationships, emotional patterns, and decision-making style.

Based on the answers, the site gives one of four result types:

Alpha

Alpha is usually associated with confidence, presence, action, and protective energy.

Beta

Beta represents balance, stability, rationality, and adaptability.

Omega

Omega is connected with emotional sensitivity, intuition, relational awareness, and inner softness.

Hybrid

Hybrid is for users who do not fit neatly into one single type. It combines traits from multiple Omegaverse archetypes.

This is not meant to be a scientific personality test.
It is more of an entertainment-focused quiz for people who enjoy Omegaverse, ABO dynamics, character archetypes, and fandom-style personality tests.

Design Direction

For the design, I wanted the site to feel clean, bright, and modern.

A lot of quiz websites use heavy colors, outdated UI, or overly dramatic visuals. I wanted something lighter.

The direction was closer to:

clean landing page
simple quiz flow
readable result page
soft visual style
mobile-friendly layout
fast loading

The homepage is designed around one main action: starting the quiz.

I did not want users to scroll through a long explanation before understanding what the site does.

The first screen should answer:

“What is this?”
“What will I get?”
“How do I start?”

SEO Considerations

This project was also interesting from an SEO perspective.

The main keyword is Omegaverse Quiz, but the site also naturally relates to:

ABO Test
Alpha Beta Omega Test
Omegaverse Type
Alpha Omega Hybrid Quiz
Omegaverse personality quiz

For this kind of small tool website, I think the most important SEO elements are:

A clear H1 with the main search intent
A short explanation of what the quiz does
Immediate interaction above the fold
Result pages that explain each type clearly
FAQ content for users who are new to the topic
Fast page loading and simple HTML structure

The site is still small, but the goal is to make it useful and easy to understand from the first visit.

What I Learned

Building this project reminded me that small websites still need strong product thinking.

Even a simple quiz has many UX questions:

How many questions should the quiz have?
Should the result feel playful or serious?
How much explanation is enough?
Should the homepage focus on SEO content or immediate interaction?
How do you make the page feel fun without making it look messy?

The hardest part was not the quiz logic itself.

The harder part was making the experience feel clear, lightweight, and intentional.

Who It Is For

This quiz is mainly for people who enjoy:

Omegaverse / ABO settings
fandom personality quizzes
character archetypes
relationship dynamics
roleplay or original character creation
light entertainment quizzes

It can also be useful as a small inspiration tool for writers or creators who are building fictional characters.

Try It

You can try the quiz here:

https://omegaversetypes.org/

It only takes a few minutes.

You might get Alpha.
You might get Beta.
You might get Omega.
Or maybe you are something more mixed — Hybrid.