Why Create Pixel Art in the Browser

Inside the Canvas API — How Pixel Manipulation Works

The Canvas 2D context's getImageData() returns pixel data as an ImageData object. This is a Uint8ClampedArray (typed array) holding RGBA values for every pixel. For a 32x32 canvas, that's 32 × 32 × 4 = 4,096 bytes.

This mechanism lets you directly manipulate image buffers in memory, much like working with raw pixel data in C. Writing back with putImageData() completes bulk changes to thousands of pixels in milliseconds. Filters, color transformations, and layer compositing are all achievable through this byte array manipulation.

Typed Arrays, unlike regular JavaScript arrays, allocate contiguous memory blocks. This dramatically improves CPU cache efficiency, delivering near-native speed even when processing massive amounts of pixel data. The ability to perform this level of low-level manipulation inside a browser is one of HTML5's greatest achievements.

How Layer Compositing Works

Pixnote's multi-layer feature manages each layer's pixel data as in-memory arrays and composites them onto a single Canvas for display. In Editor Lite, for each pixel position, it scans palette index arrays from the topmost layer downward, writing the first non-transparent pixel found into the ImageData.

This approach writes pixel values directly into the byte array obtained via getImageData() and applies them in a single putImageData() call. While looping through every pixel may seem inefficient, the memory contiguity of typed arrays combined with JIT compiler optimizations delivers sufficient speed for pixel art canvases of several thousand pixels.

How JIT Compilers Work — Why Browser JS Got Fast

Early JavaScript engines were pure interpreters, reading and executing code line by line. The V8 engine analyzes running code and compiles frequently-executed "hot paths" directly into native machine code.

Modern V8 uses a multi-tier pipeline. First, Ignition (interpreter) quickly executes bytecode while collecting profiling data. Once enough data is gathered, TurboFan (optimizing compiler) generates highly optimized machine code.

Thanks to this mechanism, repeatedly executed code — like a pixel art editor's rendering loop — effectively runs at speeds equivalent to natively compiled programs. "JavaScript is slow" is a relic of the 2000s.

All three major engines use multi-tier JIT compilation and engage in fierce performance competition (the technical side of the "browser wars"). This competition is the driving force that improves web app performance year after year.

The Benefits of the "Browser Wars"

Since 2008, the three major engines — Chrome (V8), Firefox (SpiderMonkey), and Safari (JavaScriptCore) — have engaged in fierce performance competition. When one engine introduces a new optimization technique, others follow. This competition has greatly benefited web developers and users.

Hidden Classes (shape-based optimization), Inline Caching (faster property access), Escape Analysis (eliminating unnecessary allocations) — each engine deploys cutting-edge compiler techniques. These are academic research-level technologies, and the fact that the world's best engineers continuously optimize them for free browsers is remarkable in the history of software engineering.

Behind PNG Export

Downloading pixel art as PNG is entirely handled within the browser. The canvas.toBlob() method encodes Canvas pixel data into PNG format, and URL.createObjectURL() generates a downloadable URL. No server-side processing is involved at all.

PNG export involves zero server communication. Unless you use the cloud save feature, your artwork data never travels over the network. Both drawing and exporting happen locally, eliminating the risk of unintended data transmission.

Why Image Data Is Heavy

The entire HTML text of this article is only a few dozen KB even before compression. Meanwhile, a mere 32×32 pixel image in RGBA format requires 32 × 32 × 4 bytes = 4,096 bytes (4KB). With 4 layers, that's 16KB. Maintain 50 undo steps, and this small canvas alone consumes hundreds of KB to several MB of memory. 64×64 quadruples that; 128×128 makes it 16x. Without optimization, it would quickly exhaust browser memory.

Pixnote tackles this problem through optimizations across memory, compression, communication, and rendering.

Palette Index System — A World of 1 Byte Per Pixel

Normal Canvas image data consumes 4 bytes per pixel for RGBA. But pixel art uses a limited number of colors — Pixnote's design philosophy maximizes this characteristic.

Each layer in Pixnote has a unique data structure called an indexMap (Uint8Array). It records which palette color number each pixel uses in just 1 byte. Compared to 4 bytes for RGBA, memory consumption is 1/4. For a 256×256 canvas, the indexMap is only 64KB vs 256KB in RGBA. This data also enables batch palette color changes, instantly rewriting all matching pixels across the canvas.

Progressive Undo History Compression

Undo is the lifeline of any editor, but it's also the heaviest memory consumer. Pixnote employs a unique progressive compression strategy here.

First, it calculates the data size per step from canvas size and layer count, then dynamically determines how many steps fit within a 300MB memory budget. Small canvases get up to 50 steps; large canvases still maintain at least 5. Furthermore, older history entries far from the current position are converted from raw ImageData to compressed PNG Blobs in memory. Only the most recent few steps stay in instantly-restorable form, while the rest wait in compressed state — striking the optimal balance between CPU and memory.

Thorough Compression of Saved Data

Data size during cloud saves and exports directly impacts communication costs and storage. Pixnote combines multiple compression strategies to minimize transfer volume.

Differential PNG — For pixels drawn with palette colors, the color information is already recorded in the indexMap. During save, corresponding pixels in the PNG are made transparent, compressing pure palette layers to essentially empty PNGs (~100 bytes). On load, colors are restored from the indexMap with zero data loss.

Gzip compression of indexMap — Pixel art tends to have the same color spanning large continuous areas. This characteristic pairs extremely well with Gzip compression, achieving approximately 83% compression using the CompressionStream API.

Conditional WebP conversion — WebP conversion is attempted only when PNG size exceeds 100KB, and adopted only if the WebP result is actually smaller. Rather than blindly switching formats, it makes a measured decision based on actual size reduction.

Minimizing Communication — Send Only What Changed

Network transfer of image data is incomparably more expensive than text. Pixnote adheres to the principle of sending the absolute minimum.

SHA-256 hash deduplication — Before uploading, the hash of each data chunk is checked with the server. Data that already exists is not sent. No matter how many times you save the same image, only the first upload actually transfers data.

Sync only changed layers — Even in a 10-layer artwork, only modified layers are uploaded. The other 9 layers don't need retransmission.

Intelligent batching — Multiple data chunks are grouped into batches under 500KB, drastically reducing the number of HTTP requests. Considering the overhead per request (TLS, headers, etc.), this aggregation has a significant impact.

Steady Rendering Performance Optimizations

The perceived "lightness" is supported by optimizations that are individually modest but collectively make a significant difference.

The willReadFrequently flag on Canvas 2D context tells the browser to keep pixel data in CPU memory rather than GPU memory, optimizing for frequent getImageData/putImageData calls. During drag operations, full UI updates are suppressed, with only coordinate displays updated lightly. Selection rotation previews are cached and only recalculated when angle or size changes. Marching ants animations sync to the display refresh rate via requestAnimationFrame, preventing unnecessary draws.

Aside: Energy Efficiency in an Age of Abundance

Hardware performance improves every year. Memory gets cheaper, CPUs get faster, bandwidth keeps expanding. So does optimization even matter anymore? Actually, it does.

In computer science, there's a concept called "computational complexity (Big O)." If you write an O(n²) algorithm where O(n) would suffice, even doubling CPU clock speed can't help when data doubles — it becomes four times slower. Moore's Law doesn't rescue algorithmic inefficiency. Processes like cryptographic hashing inherently require irreducible computational work. No matter how fast the machine, the computation itself can't be reduced. So "just use a faster machine" doesn't always cut it in software.

Another thing we tend to forget: electricity. Wasted computation means wasted power. In a world with hundreds of millions of active devices, even a small efficiency improvement in software has a massive impact. Memory-efficient, CPU-efficient software is, by extension, energy-efficient software.

Precisely because resources are abundant, let's be frugal with them. Users get a smoother experience, batteries last longer, and the planet gets a tiny break. Saving resources all around — not a bad deal.