Compute a Pixel's Framebuffer Index

The Framebuffer Is a 1D Array

Screens are 2D, but memory is 1D. A framebuffer stores pixels row after row in row-major order. The pixel at coordinates (x, y) on a surface of width W lives at linear index y * W + x. With 4 bytes per pixel in RGBA8 format, the first byte of that pixel sits at byte offset (y * W + x) * 4.

For example, on an 800x600 display, the pixel at (3, 2) has index 2 * 800 + 3 = 1603 and byte offset 6412.

Why Row-Major Order Matters

Every rasterizer plot, every texture sample, every CUDA image kernel, and every Linux framebuffer console driver computes this same expression. GPU memory coalescing, covered later in this subtrack, is entirely about warps of threads reading consecutive values produced by this formula. Column-major layouts exist in linear algebra libraries, but framebuffers almost always use row-major indexing because scanlines are natural horizontal strips.

• Row-major index: index = y * width + x
• RGBA8 byte offset: byte = index * 4
• Bounds check: valid when 0 <= x < width and 0 <= y < height

For This Exercise

This task asks you to read x, y, and width from stdin and print the linear index and RGBA8 byte offset. You will use this arithmetic in every rasterizer task that follows, from Bresenham line drawing through z-buffering. Getting the multiply order wrong is one of the most common off-by-one bugs when porting rendering code between APIs.