Anaglyphohol: a developer’s journey from Blazor WebAssembly to JavaScript and back as in‑browser AI 2D-to-anaglyph 3D matures
Anaglyphohol converts 2D images and video to anaglyph 3D in-browser using client-side AI depth estimation; the developer explains the move from JS to Blazor.
What Anaglyphohol Does and Why the Project Matters
Anaglyphohol is a Chrome extension that converts flat 2D images and videos into anaglyph 3D — the red-cyan or green-magenta stereoscopic format you view with colored glasses — entirely inside the browser. It performs AI-powered depth estimation on the user’s GPU with no server involvement and no uploads, transforming pixels in real time so the conversion happens where the media is displayed. For users this means a local, privacy-preserving experience; for a developer, it raises sharp technical trade-offs about platform, startup behavior, runtime size, and GPU access.
The extension’s creator, Todd Tanner (known online as @LostBeard, and building at SpawnDev.com), has shipped Anaglyphohol three different ways. Each incarnation reflects a set of constraints: developer ergonomics, browser extension expectations, and the state of in-browser GPU and ML tooling. The story of those three versions — Blazor WebAssembly, a vanilla JavaScript rewrite, and a planned return to Blazor powered by a custom GPU ML stack — illustrates how runtime performance and GPU compute capabilities shape what is practical inside a browser extension.
How the First Version Used Blazor WebAssembly and Where It Fell Short
The initial Anaglyphohol was implemented with C#/.NET running in the browser via Blazor WebAssembly. The developer’s broader ecosystem — including SpawnDev.BlazorJS, GPU compute libraries, and browser API wrappers — is implemented in C#, and Blazor WASM allowed him to write the extension’s logic in a familiar strongly typed language.
Functionally, the implementation worked: Transformer.js handled the depth estimation and the extension produced anaglyph output in real time. However, Blazor WASM on .NET 8 introduced a perceptible startup delay on each page load. The runtime and WebAssembly module required several seconds to initialize — the author reports roughly 3–4 seconds — before any conversion could occur. For a web application that users navigate to deliberately, that startup penalty can be acceptable. For a Chrome extension that injects functionality into arbitrary pages and needs to be ready instantly, a multi-second delay on every page load felt like a broken experience.
Two further constraints compounded the problem. First, the depth model and runtime increased the extension’s package size: the author reports a 152 MB extension that bundles the .NET runtime and the AI model. Second, Transformer.js performed best when running directly in the page; attempts to move it into a worker controlled by the service worker worked but introduced other complications. Altogether, a technically complete C# implementation suffered from startup latency and distribution weight that made it unsuitable for the extension use case at that time.
Why the Extension Was Rewritten in Vanilla JavaScript
To eliminate the startup latency and reduce the time between page load and functionality, the developer rewrote Anaglyphohol in plain JavaScript, CSS, and HTML. Removing the .NET runtime meant there was no language runtime to initialize, no AOT or WebAssembly warm-up to wait for, and the extension shell could inject and render UI immediately. The consequence was a snappier user experience: instant injection, immediate UI, and an AI model that still needed to load but no runtime startup blocking the initial interaction.
The JavaScript version preserved the extension’s capabilities: it converts images and DRM-free video to anaglyph in real time, supports red-cyan and green-magenta glasses, and dynamically adjusts quality to maintain framerate. The author notes that the JavaScript approach “works today” and is the shipping product in the Chrome Web Store.
That pragmatic choice, however, came at a developer-experience cost. After years building in a strongly typed C# ecosystem with full IDE support, switching to plain JavaScript felt like losing the safety net of compile-time checks, typed APIs, and tooling. The result was code that the author found harder to maintain and extend relative to the original C# implementation.
What Changed to Make a Return to Blazor Viable
Two developments convinced the author that a return to a Blazor-based implementation could now be justified: improvements in .NET startup performance and the availability of a custom GPU ML stack, SpawnDev.ILGPU.ML.
First, .NET 10 includes aggressive Blazor WASM startup optimizations. The runtime loads faster, ahead-of-time (AOT) compilation has improved, and overall the gap between the page rendering and WebAssembly readiness has narrowed. Where .NET 8 added several seconds of latency on each page, .NET 10 reduces that delay to levels where it may no longer be perceptible to users. If the runtime initializes quickly enough that users don’t notice a pause, the main argument against Blazor for this extension — slow startup — becomes weaker.
Second, and more decisively for the author’s technical vision, SpawnDev.ILGPU and its machine-learning companion SpawnDev.ILGPU.ML change where and how the depth estimation runs. SpawnDev.ILGPU is a GPU compute library for .NET that transpiles C# into target-specific GPU code — WebGPU, WebGL, WASM, CUDA, OpenCL, and CPU backends — allowing one C# codebase to run across multiple hardware and driver environments. On top of that, SpawnDev.ILGPU.ML is being developed as a neural network inference engine implemented entirely in native GPU kernels: it is not dependent on external runtimes such as the ONNX Runtime and implements over 200 ONNX operators, Flash Attention, and streaming weight loading.
For Anaglyphohol, those capabilities mean the depth estimation model can be run on a custom C#‑to‑GPU compute stack that compiles kernels directly for the GPU. That approach avoids waiting for a third‑party inference engine to initialize and, because ILGPU compiles to GPU code, the kernels are available immediately when the extension loads — eliminating the runtime startup penalty that plagued the Blazor WASM v1 implementation.
Technical advantages SpawnDev.ILGPU.ML Brings to In-Browser ML
Implementing depth estimation and post-processing on an ILGPU-based stack enables several technical benefits that the author highlights:
- The model and post-processing can execute entirely on the GPU via the browser’s native WebGPU API (when available), providing real GPU compute rather than fallbacks that run on less capable backends.
- Custom GPU kernels enable temporal frame smoothing by using previous-frame data to stabilize depth estimates across video frames, potentially reducing flicker and jitter associated with single-frame depth models.
- Post-processing effects can run as part of the same GPU pipeline, permitting zero-copy workflows where depth output flows directly into anaglyph rendering without intermediate transfers back to CPU memory.
- Because ILGPU targets multiple backends, a single C# implementation can be transpiled to whatever GPU interface the user’s environment supports.
All of these points come from the author’s description of the SpawnDev.ILGPU and ILGPU.ML projects and how they relate to an in-browser neural inference pipeline.
How Anaglyphohol Works Today and What the User Experience Is
The shipping JavaScript version of Anaglyphohol operates as a browser extension that converts DRM-free images and videos on web pages into anaglyphs in real time. It supports both red‑cyan and green‑magenta color schemes and adjusts processing quality to keep framerates smooth during playback. The conversion runs client-side on the user’s GPU where possible; the extension does not upload media or perform server-side inference.
Users can install the current release from the Chrome Web Store. The developer describes the Blazor-based rebuild as “in development” and promises higher quality and performance once the ILGPU-backed, .NET 10-targeted version ships.
Developer and Publisher Trade-Offs: Tooling, Runtime Size, and Privacy
The three-version history of Anaglyphohol surfaces several trade-offs that developers face when shipping browser extensions with embedded ML:
- Tooling and language ergonomics: C# and Blazor offer strongly typed development, IDE support, and a consistent codebase across browser and native targets. JavaScript provides minimal startup friction but sacrifices compile-time safety that some developers prefer.
- Runtime and bundle size: Bundling a .NET runtime and AI models produced a sizeable extension (the author reports 152 MB). That size affects download time and storage and was one factor pushing the rewrite toward vanilla JavaScript.
- Extension startup expectations: Browser extensions inject code into existing pages and must often be ready immediately; runtime warm-up times that are acceptable for standalone web apps can degrade the user experience inside an extension.
- Platform publishing policies: Publishing a Chrome extension involves disclosing personal information on the Google listing; the developer notes that Google’s process required full legal name, home address, and phone number on the public listing, with no option to use a business address or PO box. For a solo developer working from home, this results in a personal residential address appearing on a public page.
These trade-offs influenced the choices made during development and continue to shape the roadmap for the Blazor-based return.
Industry Context: Browser ML, WebGPU, and In-Browser Inference
Anaglyphohol’s evolution reflects broader trends in web and developer tooling. As browsers expose richer GPU APIs like WebGPU and as runtimes and toolchains improve AOT and startup performance, the balance between developer comfort and runtime efficiency shifts. The author’s decision to move off of a third-party inference runtime and into a custom ML stack reflects a desire for tighter control over performance characteristics, kernel implementation, and pipeline integration — especially for features like temporal smoothing and zero-copy rendering that benefit from specialized GPU kernels.
The project also touches adjacent ecosystems: developer tools that transpile languages to GPU code, AI toolchains that expose operator implementations and attention mechanisms, and browser automation and extension APIs that must accommodate in-page ML workloads. For teams exploring similar in-browser ML experiences — whether for visualization, AR/VR, or real-time video processing — the trade-offs documented here are instructive: runtime startup, model size, and the available GPU interfaces are decisive factors in architecture and language choice.
Who Should Consider Anaglyphohol and When to Use It
Anaglyphohol targets users and scenarios where local, in‑browser 2D-to-3D conversion is desirable and DRM is not a barrier. The extension works on pages with DRM-free media and is intended for experiential or visual exploration of content in stereoscopic anaglyph. Developers interested in the project as a case study will find particular relevance if they:
- Want to understand the interaction between WebAssembly runtimes and browser extension UX constraints.
- Are exploring in-browser GPU inference and the trade-offs between third‑party inference runtimes and custom GPU kernels.
- Need examples of practical workarounds for startup latency and package size when shipping ML-enhanced browser extensions.
The current, shipping version is implemented in JavaScript and available now in the Chrome Web Store; the author is actively developing a .NET 10 + SpawnDev.ILGPU.ML version that prioritizes C# tooling and optimized GPU pipelines.
Practical Questions Addressed in the Project Narrative
What the software does: transforms 2D images and video into anaglyph 3D via client-side depth estimation and GPU-driven rendering.
How it works: the pipeline performs depth estimation on each frame using an ML model, then maps depth to stereo parallax and color channels to produce a red-cyan or green-magenta anaglyph; in the author’s planned C# stack, inference and post-processing run as GPU kernels produced by SpawnDev.ILGPU.
Why it matters: a local, client-side conversion preserves user privacy and enables real-time effects without uploading media to servers; the project also tests practical limits of in-browser ML and GPU compute for extension use cases.
Who can use it: anyone with a Chromium-based browser who installs the extension and views DRM-free media; developers can study its architecture to inform similar projects.
When the new version will be available: the author describes the Blazor + ILGPU implementation as “in development” and positions it as a coming update once .NET 10 startup and the ILGPU ML stack are ready to deliver the intended performance and feature set.
Try It Today and What to Expect
The live Anaglyphohol release is the JavaScript rewrite. It converts images and DRM-free video on web pages into anaglyphs, supports two color schemes, and dynamically adjusts quality to preserve framerate. The author recommends using anaglyph glasses for the intended stereoscopic effect. The Blazor-based rebuild, leveraging SpawnDev.ILGPU.ML, is under development and is expected to offer improved 3D quality and GPU-driven optimizations when it ships.
Implications for Developers, Businesses, and Browsers
Anaglyphohol’s development arc highlights a few broader implications:
- Performance expectations for extensions are strict: any runtime startup perceived as a delay compromises the product’s fit for the extension channel. Vendors and platform teams should be aware that extension-suitable runtimes need near-instant availability.
- In-browser ML is moving from experimental to practical: the availability of WebGPU and improved compilation pipelines enables nontrivial neural inference workloads to run locally in browsers, provided toolchains address startup, operator coverage, and kernel performance.
- Developer tooling matters for sustainability: the author’s preference for C# reflects the value of strong typing, IDE support, and a unified codebase across platforms. Toolchains that preserve developer productivity while meeting runtime constraints will be influential in adoption decisions.
- Privacy and platform policy are material considerations for independent developers: the requirement to publish personal contact information in store listings is a concrete cost for solo maintainers that influences how they publish and present their work.
These observations suggest that as browser ML capabilities mature, attention will shift from “can we do it?” to “how do we do it sustainably, privately, and with acceptable startup behavior?”
Built by Todd Tanner and maintained under the SpawnDev umbrella, Anaglyphohol is both a practical tool and a living experiment in how modern browser runtimes and GPU compute stacks can host real-time, client-side ML workloads.
The project’s next phase will deploy a Blazor WebAssembly front end paired with SpawnDev.ILGPU.ML so the entire pipeline — from pixel input to anaglyph output — is authored in C# and transpiled into GPU kernels for the user’s environment; when that version ships, the author expects improved temporal smoothing, tighter GPU post-processing, and a zero‑copy rendering path that keeps data on the GPU. As browsers, runtimes, and ML toolchains continue to evolve, Anaglyphohol’s evolution will be worth watching as a practical case study in balancing developer experience, user privacy, runtime performance, and the possibilities of in-browser GPU-accelerated neural inference.
