About

BitBlt (Bit Block Transfer) is the foundational raster operation behind every graphics system from GDI to modern compositors. It copies a rectangular block of pixels from a source bitmap to a destination bitmap, combining them through one of 16 Boolean raster operation codes (ROPs) derived from the two-input truth table of source pixel S and destination pixel D. Getting the wrong ROP code in driver-level graphics code produces corrupted display output, invisible sprites, or inverted UI elements that are notoriously difficult to debug. This tool performs actual pixel-level BitBlt on real image data using Uint32Array buffer manipulation. It does not simulate the operation. It applies the selected Boolean function to every pixel in the transfer region. Note: operations treat each color channel independently as an 8-bit value. Alpha is preserved from the destination unless SRCCOPY is used.

Formulas

BitBlt operates on a rectangular region defined by position (x, y) and dimensions (w, h). For each pixel at coordinate (i, j) within the region, the output pixel value R is computed per-channel from the source pixel S and destination pixel D using the selected Boolean function f.

R_c = f(S_c, D_c) for c ∈ {R, G, B}

The 16 possible Boolean functions arise from the 2-input truth table. Each ROP code k (0 - 15) encodes which of the 4 input combinations produces a 1 bit.

f_k(S, D) =

{

bit 0 of k when S=0, D=0bit 1 of k when S=0, D=1bit 2 of k when S=1, D=0bit 3 of k when S=1, D=1

Per-channel application uses bitwise operators on 8-bit unsigned integer values. For example, SRCINVERT (ROP 6, XOR):

R_c = S_c ⊕ D_c

Where R_c is the result channel value, S_c is the source channel value, D_c is the destination channel value, c is the color channel index (Red, Green, Blue), k is the ROP code (0 - 15), and f is the Boolean combination function selected by k.

Reference Data

ROP Code	Name	Boolean Formula	Hex Code	Effect Description
0	BLACKNESS	0	0x000042	Fills destination with black
1	DPSon (NOR)	¬(S ∨ D)	0x000289	NOR of source and destination
2	DPSna	D ∧ ¬S	0x000C89	Destination AND NOT source
3	NOTSRCCOPY	¬S	0x330008	Inverted copy of source
4	SRCERASE	S ∧ ¬D	0x440328	Source AND NOT destination
5	DSTINVERT	¬D	0x550009	Inverts destination pixels
6	SRCINVERT (XOR)	S ⊕ D	0x660046	XOR blend - classic sprite trick
7	DSPna (NAND)	¬(S ∧ D)	0x7700E6	NAND of source and destination
8	SRCAND	S ∧ D	0x8800C6	AND blend - darkening mask
9	DSPnx (XNOR)	¬(S ⊕ D)	0x990066	XNOR - pixels match = white
10	D (NOP)	D	0xAA0029	No operation - destination unchanged
11	MERGEPAINT	¬S ∨ D	0xBB0226	NOT source OR destination
12	SRCCOPY	S	0xCC0020	Direct copy - most common BitBlt
13	SDPno	S ∨ ¬D	0xDD0228	Source OR NOT destination
14	SRCPAINT (OR)	S ∨ D	0xEE0086	OR blend - lightening merge
15	WHITENESS	1	0xFF0062	Fills destination with white

Frequently Asked Questions

XOR operates on each bit independently across all 8 bits of each color channel. On photographic (continuous-tone) images, source and destination pixel values are essentially uncorrelated high-entropy data. XOR of two uncorrelated byte streams produces uniformly distributed output, which appears as noise. XOR produces clean, predictable results only when applied to flat-color or binary (1-bit) images, which is why classic sprite engines used it with monochrome masks on solid backgrounds.

ImageData.data is a Uint8ClampedArray where each pixel occupies 4 consecutive bytes (R, G, B, A). Accessing individual channels requires 4 array lookups per pixel. By creating a Uint32Array view over the same ArrayBuffer, each pixel becomes a single 32-bit integer read/write. This reduces loop iterations by 4x and allows bitwise ROP operations on all channels simultaneously (with care for alpha and byte order). On a 1920×1080 image (~2M pixels), this reduces from ~8M array accesses to ~2M.

Most modern systems are little-endian, meaning a pixel stored as RGBA bytes in the Uint8ClampedArray appears as 0xAABBGGRR when read as a Uint32. The tool detects endianness at initialization and adjusts channel extraction masks accordingly. On big-endian systems (rare but possible in some embedded browsers), the same bytes read as 0xRRGGBBAA. Incorrect endian handling silently swaps red and blue channels.

Yes. The 16 ROPs here are binary (2-input: Source and Destination). Windows GDI defines 256 ternary ROPs that include a Pattern brush as a third input. Any ROP3 can be decomposed into at most 3 sequential binary BitBlt operations. For example, ROP3 code 0xB8074A (PSDPxax) requires: first XOR destination with pattern, then AND with source, then XOR with pattern again. This tool supports chaining by applying operations sequentially to the destination canvas.

SRCCOPY performs a direct pixel replacement - the destination receives the exact source pixel including its alpha channel. All other Boolean operations (AND, OR, XOR, etc.) are applied only to the R, G, B channels while the destination alpha is preserved at its original value. This prevents accidentally creating transparent holes in the destination when the intent is color blending. If you need alpha-channel operations, apply the tool to each channel independently by loading grayscale channel extractions.

Overlapping regions cause read-after-write hazards: pixels already modified by the operation get re-read as source data for later pixels. This tool avoids the problem by copying the source region into a temporary ImageData buffer before applying the operation. Historical BitBlt implementations in hardware sometimes lacked this safeguard, requiring the programmer to choose copy direction (top-down vs bottom-up) based on overlap geometry.