A URL, or Uniform Resource Locator, is a structured identifier interpreted according to a URL scheme and parsing rules. On the web it can identify the resource a browser navigates to or requests. The URL parser produces a record with components such as scheme, host, port, path, query and fragment; which components are present depends on the particular URL.^[ref]

For example, https://example.org:8443/a/b?x=1#part has scheme https, host example.org, port 8443, path /a/b, query string x=1 and fragment identifier part. This hierarchical HTTPS example is useful without implying that every URL must contain a network host or an explicit port.

A Relative URL reference needs a base. Resolving ../img/p.png against https://example.org/a/b/page.html gives https://example.org/a/img/p.png. The base's directory and parent-directory step explain the result. Parsing and serialization can also normalize a spelling: https://EXAMPLE.org:443/a serializes as https://example.org/a, lowercasing the host and omitting the default HTTPS port.^[ref]

Percent-encoding represents bytes in a URL spelling, and encoded data must be distinguished from structural delimiters. A query string is not universally a dictionary of name/value pairs, even though many applications use that convention. Nor does successful parsing prove that a resource is reachable or that its content never changes. Distinguishing syntax, identifier interpretation and an actual retrieval prevents an address from being confused with the information returned on one occasion.

The Hypertext Transfer Protocol is an application-level communication protocol for exchanging requests and responses about resources. In the client-server model, an HTTP request supplies an HTTP request method and target; an HTTP response supplies an HTTP status code and associated information. HTTP header fields convey metadata, and messages can carry content. These semantics are distinct from the particular wire format used by a protocol version.^[ref]

For a concrete exchange, a client can send method GET for https://example.org/manual. A successful response can carry status 200 and an HTML representation of the resource. A response with status 404 instead says that the server did not find a current representation, or is unwilling to disclose one; successful communication does not require successful retrieval.^[ref]

The request's URL identifies the target, while the response describes the outcome of this exchange. A later exchange can return different content or a different status. The protocol's stateless request semantics also do not prevent an application from maintaining state: the distinction concerns what a request must mean, not whether a user can have an ongoing session.^[ref]

A media type identifies a data format and its intended interpretation using a type/subtype name, optionally followed by parameters. It lets a recipient choose an appropriate interpretation rather than inferring everything from a file name. Media types are used in the Hypertext Transfer Protocol and other Internet protocols.^[ref]

For example, text/plain; charset=utf-8 has type text, subtype plain and a charset parameter naming UTF-8. In an HTTP header field such as Content-Type: text/plain; charset=utf-8, this describes the accompanying representation data; it is not itself that data.^[ref]

A format and a character encoding answer different questions. A media type can describe plain text or an image format, while a character encoding explains how text characters correspond to bytes. For example, the PNG format has media type image/png; it is not interpreted by treating all its bytes as a sequence of displayed text characters.

A file suffix is another convention. Two files with the same suffix need not actually contain the same format, and a response's type metadata need not be derived from the last characters of its URL. Correct interpretation requires consistent metadata and data, not merely a suggestive name.

Type/subtype tokens and parameter names have their specified case-insensitive matching rules, but parameter values follow the rules of their own definitions. Lowercasing arbitrary values is therefore not a general parsing strategy.^[ref] A useful inspection separates the name, each parameter and the actual bytes being interpreted.

Memory alignment restricts the memory addresses at which an object may begin. An alignment of $A$ bytes means that its starting byte address $a$ satisfies $a\mathrm{mod}A=0$. For example, address $4096$ satisfies eight-byte memory alignment, whereas address $4100$ does not. Alignment is a constraint on location, rather than another name for an object's size.

In the C programming language, object types have alignment requirements; _Alignof queries a type's requirement and _Alignas can request a supported stronger requirement. The actual values depend on the implementation. The C11 draft distinguishes fundamental from implementation-supported extended alignments and requires valid alignment values to be powers of two.^[ref]

An application binary interface makes such choices concrete. Under the ordinary AAPCS64 layout, a C structure containing a char tag followed by a double value has the character at offset $0$, seven unused padding bytes, and the double at offset $8$. Its total size is $16$ bytes and its alignment is $8$ bytes. The application binary interface aligns an aggregate as strictly as its most strictly aligned member and rounds the aggregate size up to a multiple of that alignment; this also keeps each element properly aligned in an array of these structures.^[ref]

This example is an explicit platform convention, rather than a universal promise that every C double needs eight-byte memory alignment. Likewise, a processor's ability to execute an unaligned load does not by itself relax the C programming language's object-access requirements. Keeping the language rule, the application binary interface layout, and the machine instruction separate explains why a byte buffer cannot automatically be treated as a properly located object of any chosen type.

A framebuffer is computer memory holding an image's pixel values in a representation usable by graphics hardware or software. A pixel format specifies how stored bits encode those values. The image's dimensions alone do not determine its complete memory layout: rows can include padding, and different layouts can organize components differently.^[ref]

For a concrete packed-row model, let the image be three pixels wide and two rows high, using four bytes per pixel. A row's actual pixel data occupies $3\times 4=12$ bytes. If each row starts 16 bytes after the previous one, the framebuffer stride is 16 bytes and four padding bytes separate consecutive pixel rows. Reserving two complete row slots takes $2\times 16=32$ bytes, although the pixel values themselves occupy only 24 bytes.

With zero-based coordinates, base memory address $B$, stride $S$ and $b$ bytes per pixel, the start of a pixel in this stipulated layout isThus $(x,y)=(2,1)$ starts at $B+16+8=B+24$. Replacing $S$ by the packed width12 would instead address the wrong location. This formula assumes packed, byte-addressable rows; it is not a formula for every possible pixel format.

The Linux interface makes the distinction explicit: line_length reports row length in bytes, separately from resolution and bits_per_pixel. A program should use the layout supplied by the interface when interpreting a framebuffer, rather than infer it from the visible dimensions alone.^[ref]

A bit field assigns a selected group of bits within a stored value to a particular component or meaning. For a contiguous field, specify its width $n$, starting position $s$ counted from the least significant bit, and interpretation. In a pixel format, separate bit fields can hold red, green and blue component codes. The Linux frame-buffer interface describes such fields with explicit offset and length members.^[ref]

For a nonnegative integer word $W$, the unsigned value of the field isIn a language with the usual unsigned bitwise operations, this corresponds to shifting right by $s$ and applying bitwise AND with $2^n-1$.

For an original eight-bit example, let $W=181$, written 0xB5 or binary 10110101. Select three bits beginning at position 4, so the field consists of bits 6–4. Extraction givesThe field's bits are 011. To replace them by value 6, clear the field with mask 0x70, then insert 6 << 4. Restricted to eight-bit words, the calculation isThe other five bits are unchanged. The range $0\le v<2^n$ specifies what fits in an unsigned field.

A language-level bit-field declaration is a related abstraction, but its physical placement follows that language and implementation. In the C programming language, unsigned int code : 3; declares a three-bit field; C11 leaves allocation order within a storage unit implementation-defined and the storage unit's alignment unspecified.^[ref] Such a declaration alone therefore does not specify a portable external byte sequence. An explicit layout must also state the relevant endianness and storage rules.

Memory allocation reserves computer memory for a program’s data and makes that storage accessible through memory addresses. Allocation determines where data can live and how long the storage remains available; initialization determines the data’s initial value. A language can arrange storage automatically for local variables, retain storage for the duration of a program, or request storage dynamically while the program runs.

In the C programming language, malloc(n) requests a block of $n$ bytes and returns a pointer to it, or a null pointer if allocation fails. Successful allocation does not initialize those bytes. The free operation releases a previously allocated block for subsequent allocation; accessing it through an old pointer is no longer valid.^[ref][ref] Allocation and deallocation are therefore separate from reading and writing an object. Deallocation need not erase its former contents or immediately return its storage to the operating system.

For a process using virtual memory, a contiguous interval of memory addresses does not require a contiguous interval of physical memory. The memory management unit can map successive virtual pages to different physical page frames. Conversely, a successful small allocation may be satisfied from an existing free block without asking the operating system for another page.

Two small bookkeeping examples explain why free capacity alone does not determine whether an allocation succeeds. If an allocator rounds a 17-byte request up to a 32-byte allocation unit, 15 bytes are unused inside that unit: internal fragmentation, before counting any allocator metadata. If two free 32-byte blocks are separated by an occupied block, a request for one contiguous 48-byte block cannot fit in either hole, even though 64 bytes are free. That is external memory fragmentation, under the assumption that the occupied block cannot be moved and no further storage is available. Adjacent free blocks can sometimes be combined; separated ones require a different placement or movement strategy.

Rasterization converts geometric primitives into candidate contributions at discrete pixel sample positions. For a projected triangle, an implementation tests which samples lie inside its three oriented edges and interpolates attributes from the vertices. With barycentric coordinates ${\lambda }_i$, a screen-space linear attribute is ${\sum }_i{\lambda }_i{a}_i$. Attributes defined before perspective projection generally need perspective-correct interpolation:Here $w_i$ are the clip-coordinate denominators. Ordinary interpolation would distort a texture seen at an angle.

A generated fragment is not necessarily a final visible pixel: a fragment shader determines its values, a depth buffer can reject hidden contributions, and blending combines surviving contributions. Multiple samples per pixel improve coverage estimates near boundaries but do not recreate arbitrarily fine detail. OpenGL specifies these stages separately, so geometric coverage and final image storage must not be conflated.^[ref]

Virtual reality presents an interactive simulated environment whose sensory output responds to a user's actions and viewpoint. A head-mounted display commonly renders a separate view for each eye and tracks head pose. For a rigid world point $p$, the current view transform maps $p$ into eye coordinates before perspective projection; updating that transform as the head moves makes stationary simulated objects appear fixed in the surrounding space.

The latency between movement and the corresponding displayed view matters: stale head pose makes the scene appear to lag behind the observer. Tracking, rendering, display timing and input handling therefore form one feedback loop. A simple experiment is to turn the head while viewing a virtual grid: incorrect orientation updates make the grid move with the head instead of remaining anchored. WebXR exposes per-frame viewer poses and eye views through explicit reference spaces, illustrating how a graphics application connects simulated geometry to tracked physical motion.^[ref]

A fragment shader is a programmable stage of the rasterization pipeline that computes values for a fragment, such as its output color and optionally its depth. It receives interpolated data from rasterized primitives and can use texture mapping to sample an image. A fragment is a candidate contribution; later tests and blending determine what reaches the final digital image.^[ref]

For example, a shader can multiply a surface's interpolated color by a sampled image to decorate a triangle. A fragment hidden behind a nearer opaque surface may fail the depth buffer test. With multiple samples per pixel, fragments, shader invocations and final pixels need not correspond one to one.

A depth buffer stores a depth value for each covered framebuffer sample so that rasterization can resolve visibility. With the common “less” comparison, a new fragment contributes only when its depth is smaller than the stored value; an accepted fragment can then update that value. Thus the nearest opaque surface can win even when primitives arrive in a different order.^[ref]

For example, starting from depth 1, an opaque fragment at 0.7 passes, then one at 0.2 replaces it; a later fragment at 0.8 fails. Reversing the first two arrivals gives the same visible surface. Finite precision can make nearly coincident surfaces compare inconsistently. Transparent surfaces also require additional treatment: selecting one nearest depth alone cannot combine light from several layers.

Texture mapping associates surface locations with values sampled from an image or other texture data. In a common two-dimensional case, each vertex carries coordinates $(u,v)$ identifying a location in the texture. Rasterization interpolates the coordinates, and a fragment shader uses them to obtain a color or another surface parameter.^[ref]

For example, a square wall can use $(0,0)$, $(1,0)$, $(1,1)$ and $(0,1)$ at its corners so a rectangular image covers it once. Repeating coordinates from zero to four can tile the same image when the wrapping mode allows repetition. The mapping is separate from sampling: nearest-sample selection and interpolation can give visibly different results from identical coordinates.

When a tilted surface is viewed through perspective projection, equal distances on the surface need not occupy equal distances on screen. Correct interpolation must account for that projection. A texture also supplies data rather than an automatic physical material model: a stored color and the light reflected toward the camera are different quantities.

OpenGL is a graphics programming interface that specifies commands, data objects and rendering behavior independently of a particular graphics processor. An application supplies geometric primitives and programs for programmable stages; the implementation transforms, rasterizes and combines their contributions into a framebuffer. Khronos Group publishes the specification, including the distinction between core and compatibility profiles.^[ref]

For example, drawing an opaque triangle requires vertex data, appropriate shader programs and a draw command. The triangle can generate fragments during rasterization; a fragment shader determines their candidate outputs, and a depth buffer test can reject hidden contributions. The interface specifies the results these operations must produce, while implementations can use different internal hardware and scheduling. A rendering command's submission is also distinct from completion of the corresponding device work.^[ref]

Pixel density measures how many pixels occupy a specified physical length or area. For a flat display with square, uniformly spaced pixels, its linear pixel density is often expressed as pixels per inch. Its reciprocal is the pixel pitch, the physical separation between corresponding points of neighbouring pixels.

If the display has horizontal and vertical counts $N_x,N_y$ and diagonal $D$ measured in inches, the Pythagorean theorem gives the linear pixel densityA hypothetical $1920\times 1080$ display with a $24\mathrm{in}$ diagonal has $2202.91/24\approx 91.8$ pixels per inch. Its pixel pitch is $25.4/91.8\approx 0.277\mathrm{mm}$. At the same pixel counts, halving the diagonal doubles the linear pixel density and quadruples the number of pixels per unit area. These calculations assume the quoted diagonal is the active image area.

A stored image's pixel counts do not determine its physical size without a display or printing scale. Likewise, a CSS px is a layout unit rather than a promise of one physical display pixel. CSS fixes 96px = 1in within its unit system, but the mapping onto physical display pixels depends on the chosen anchor and device. That ratio cannot be used to infer a screen's measured pixel density.^[ref]

A pixel format specifies how stored bits represent a pixel value: its components or table index, the allocation of bits to those components, and the applicable representation conventions. A complete image layout also needs dimensions and row organization, including framebuffer stride. The Linux frame-buffer API separates storage type from color interpretation and describes component offsets and lengths explicitly.^[ref]

For an original packed pixel format, place red, green and blue codes in a 16-bit unsigned word $P$, with widths 5, 6 and 5 bits respectively. Declare the red component to occupy bits15–11, green10–5 and blue4–0:These non-overlapping bit fields specify a particular encoding. Setting $(R,G,B)=(31,0,0)$ gives $P=63488$, or 0xF800 in hexadecimal. Knowing only “16 bits per pixel” would not identify those component positions.

Endianness then controls how the word occupies byte-addressed computer memory. Little-endian storage of 0xF800 gives successive bytes 00 F8; big-endian storage gives F8 00. Reading the little-endian bytes as a big-endian word instead produces 0x00F8. Under the same declared component fields, that decodes to $(R,G,B)=(0,7,24)$ rather than $(31,0,0)$. Bit significance in the word and byte order in memory are separate specifications.

Bit allocation also limits representable component codes: the red and blue fields have 32 levels each, while green has 64. If normalized codes are defined as $R/31$, $G/63$ and $B/31$, their respective increments are $1/31$, $1/63$ and $1/31$. These are code increments, not a claim that emitted light varies linearly with the stored number. The RGB color model and an appropriate color space supply further interpretation.

Other formats can store an image lookup table index or include an alpha channel for transparency. The frame-buffer documentation likewise distinguishes pseudocolor indices from direct component fields.^[ref] Report the actual format alongside dimensions and stride when exchanging pixel buffers.

Alpha compositing combines image contributions using their colour values and alpha channels. The source-over compositing rule places a source layer over a destination while retaining the destination's contribution where the source is partly transparent. Other compositing rules select different contributions; the alpha values alone do not identify the chosen rule.^[ref]

Write $C_s,C_b$ for source and background colour triples, with alpha values ${\alpha }_s,{\alpha }_b$. In premultiplied alpha form, $c_s={\alpha }_s{C}_s$ and $c_b={\alpha }_b{C}_b$. Then source-over compositing givesWhen ${\alpha }_o>0$, the corresponding straight alpha colour is $C_o=c_o/{\alpha }_o$. The output can remain partly transparent, ready to be combined with another background.

For an original Linear-light RGB example, place red $C_s=(1,0,0)$ with ${\alpha }_s=1/2$ over blue $C_b=(0,0,1)$ with ${\alpha }_b=1/4$. The result isReversing the layers instead gives $c_o=(3/8,0,1/4)$ and $C_o=(3/5,0,2/5)$, with the same output alpha. Layer order changes the colour even when it leaves the output alpha unchanged.

If the background is opaque, ${\alpha }_b=1$ and ${\alpha }_o=1$, so the rule reduces to $C_o={\alpha }_s{C}_s+(1-{\alpha }_s)C_b$. For a physical light-mixture interpretation, carry out that arithmetic in Linear-light RGB; encoded sRGB values first need their appropriate conversion.^[ref] Separately specify whether stored colour samples already contain their alpha multiplier, so that the source contribution is not multiplied twice.

The V4L2 multi-planar API is the Video4Linux interface for describing video buffers whose data may occupy several image memory planes. A buffer acts as a container, while per-plane descriptors identify the relevant storage. This supports formats such as NV12M and NV21M without assuming that one plane immediately follows another.^[ref]

A multi-planar interface and a multi-planar format are different choices. The interface can also carry supported single-planar formats when described through its structures; the reverse interface cannot describe a multi-planar format. Buffer-type names ending in _MPLANE identify the multi-planar interface, rather than specifying a colour model or sampling ratio.^[ref]

A practical interpretation depends on the structure being read. In v4l2_buffer, length means a number of plane-array elements under the multi-planar API. Inside a V4L2 plane descriptor, length instead means that plane's allocation size in bytes.^[ref]

For an original descriptor example, a frame with two planes has a container plane count of two and stipulated plane capacities4096 and2048 bytes. Treating the outer count as a two-byte storage capacity, or treating4096 as the number of plane descriptors, confuses quantities with different meanings. The sum6144 describes those declared capacities, not the number of active image bytes.

The negotiated pixel format still determines the component arrangement. Descriptors for two planes could represent a luma plane plus interleaved colour differences; they do not automatically mean one red plane and one green plane. Framebuffer stride, sample encoding and chroma sample location remain part of interpreting the image.

A microarchitecture is a particular hardware organization implementing an instruction set architecture. It specifies mechanisms such as instruction decoding, execution units, pipelines, caches and branch prediction. Two processors can expose the same instruction-set contract while making different choices about those mechanisms.

For example, both processors may correctly execute a load followed by an integer addition. One can overlap independent instructions and obtain the load from a nearby cache, while the other waits for a longer memory access. The architectural result agrees, but cycle counts differ. Speculative work must be discarded or committed in a way that preserves the required visible behavior. This distinction explains why compatibility with one instruction set does not imply equal performance, power consumption or physical implementation.^[ref]

Cycles per instruction is the average number of processor clock cycles spent per counted instruction for a specified execution interval and counting convention. If $N$ instructions complete in $C$ cycles, $\mathrm{CPI}=C/N$. At constant clock frequency $f$, execution time satisfiesFor example, $10^9$ completed instructions at CPI 1.5 and $3\times 10^9$ hertz take 0.5 seconds.

The value depends on instruction mix, dependencies, cache misses, branch behavior and the chosen microarchitecture. It can be less than one when several instructions complete per cycle. A long-latency instruction need not prevent other independent work from overlapping, so individual instruction latencies cannot simply be added to predict elapsed time. Comparing processors by frequency alone ignores both CPI and the number of instructions needed for the same task.

Memory bandwidth is the rate at which data crosses a specified computer memory interface, commonly measured in bytes per second. If $Q$ bytes are transferred in time $T$, the measured average is $B=Q/T$. The interface and counting convention matter: an application-level count can differ from physical traffic caused by memory caches.

A streaming array operation reading two eight-byte values and writing one per element transfers at least 24 useful bytes per element. At a sustained $24\times 10^9$ bytes per second, that traffic alone limits throughput to $10^9$ elements per second. Memory access latency instead measures how long one access takes. Overlapping many accesses can achieve high memory bandwidth despite substantial memory access latency. STREAM measures sustained memory bandwidth with simple array kernels and working sets larger than the available memory cache.^[ref]