[GrantMoyer]

People get caught up on display technology, but how pixels are displayed on a screen is irrelevant. From a typical viewing distance and with imperfect human lenses, a point impulse and a little square are barely distingishable. The important part is that thinking about pixels as little squares instead of points makes all the math you do with them harder for no benefit.

Consider the Direct3D rasterization rules[1], which offset each sample point by 0.5 on each axis to sample "at the pixel center". Why are the "pixel centers" even at half-integer coordinates in the first place? Because if thinking of pixels as little squares, it's tempting to align the "corners" with integer coordinates like graph paper. If instead the specifiers had thought of pixels as lattice of sample points, it would have been natural to align the sample points with integer coordinates. "Little square" pixels resulted in an unneeded complication to sampling, an extra translation by a fractional distance, so now every use of the API for pixel perfect rendering must apply the inverse transform.

[1]: https://learn.microsoft.com/en-us/windows/win32/direct3d11/d...

[IAmBroom]

> People get caught up on display technology, but how pixels are displayed on a screen is irrelevant.

To a user, usually.

To a home entertainment customer, never (even if they wouldn't really notice!).

To an optical engineer like myself, never true.

[leguminous]

The half pixel offset makes sense, though. If you have two textures, you want the edges to align, not the centers of the pixels.

See, for example: https://bartwronski.com/2021/02/15/bilinear-down-upsampling-...

Implementations of resizing based on aligning pixel centers resulted in slight shifts, which caused a lot of trouble.