How the display tools work

What the test observes

The test records timestamps from requestAnimationFrame, the browser’s animation callback mechanism. Intervals between successive callbacks form the timing sample. The HTML animation-frame standard defines this browser mechanism.

Observed browser FPS counts animation callback intervals during this page’s sample. For physical refresh rate, use the active display mode and model documentation; for game FPS, use the game’s counter. Pixel response and input-to-light delay require their own measurement methods. See the measurement comparison.

Warm-up, duration and interruptions

Each run begins with a one-second warm-up. Warm-up intervals are excluded. The selected measurement period is 10 or 20 seconds; compare runs using the same duration and load setting.

If the tab becomes hidden during a run, that run is invalidated and its sample is cleared. Return to the visible tab and start again. Every new run starts with a fresh warm-up and sample.

The calculations

Let n be the number of recorded intervals, and let Σ intervals be their sum in milliseconds.

For the 95th percentile, nearest rank means the item at one-based position ceil(0.95 × n). The p95 value is selected from the recorded sample rather than interpolated. The median uses the central-value rule described above. The raw interval chart is not smoothed. Display rounding can make two slightly different values look the same.

“Spike” labels an unusually long callback interval relative to the current sample. Compare its timing and frequency across repeat runs using the same settings.

What animation load changes

The optional load increases the animation work requested by this page. It is useful for comparing a clean run with a heavier version of this same scene. The comparison describes the combined behavior of the browser and system while drawing this scene. Keep a clean result before adding load, and note the setting in each comparison.

How the motion comparison runs

Every row uses the same elapsed-time-based travel speed. Position updates are quantized to the row’s requested rate, such as 30 FPS, within the callbacks the browser actually provides. Requested rates above that available cadence cannot create additional physical updates. Rates that do not divide evenly into the callback cadence may also show uneven update spacing.

Repeatable measurements and references

Keep the same browser, duration, load, display mode and power condition when comparing runs. Repeat an unexpected result. Remote desktops, multiple displays, system workload and power behavior can affect the browser’s timing; a single sample cannot determine their individual contribution.

Technical references for animation timing and display settings were checked on 25 October 2026. Browser behavior and platform menus can change with software updates.

Additional references: MDN animation callbacks, TestUFO browser prerequisites and Microsoft display refresh settings. Implementation choices and reporting thresholds are Test My Display’s own.

Run a browser sample · Read about local results and preview access.

The horizontal axis uses actual elapsed seconds. Dense time columns preserve their first, last, shortest and longest recorded intervals. Download the JSON or CSV to read every original interval.

Inspecting static patterns

Screen inspection presents RGB colors, gray fields, gradients, near-black and near-white steps, and a sharpness/checkerboard reference for human observation. Pattern values specify the RGB image sent to the display. Luminance is measured with an instrument. Native resolution, zoom, system scaling and browser color management affect the displayed result.

Motion lanes use elapsed-time positions at the requested rate. A scheduling tolerance of at most 0.5 ms (and at most 10% of the requested interval) prevents tiny timestamp rounding differences from creating repeated positions at a frame boundary. This tolerance does not change the raw intervals or statistics in the separate FPS test. Observed lane updates still cannot exceed the callbacks received.

Density and screen information

The PPI calculator divides the pixel diagonal, √(width² + height²), by the physical diagonal in inches. Dimensions assume a rectangular active area and square pixels. Comparison reports the relative difference in calculated pixel density. Conversion uses 1 in = 2.54 cm and retains the physical value without rounding it on every unit switch.

Screen information comes from local browser APIs. CSS pixels, DPR and visual viewport scale are distinct values. Screen × DPR is labelled as a conditional arithmetic estimate; native panel resolution comes from the display specification. Unavailable values are not replaced with zero.

RGB values and fine-detail patterns

The near-black chart uses equal red, green and blue channel values of 0, 2, 4, 8, 12, 16, 20, 24, 32. The near-white chart uses 223, 227, 231, 235, 239, 243, 247, 251, 255. These are full-range RGB image values on the 0–255 scale. The sharpness reference combines a one-CSS-pixel checkerboard, alternating lines and text. A CSS pixel does not necessarily map to one physical pixel.

Inspection outcomes and visual adjustment

Choosing a task suggests patterns to inspect; free selection remains available. A visit records that a pattern was opened. A checked outcome or a skipped field is recorded separately. The report reflects those actions and the observations you supplied, including optional approximate locations and notes. Patterns become checked when you save an observation; unvisited and undecided patterns keep their own status.

Dark and light steps support a by-eye comparison before and after a reversible setting change. Fine detail helps compare the current scaling and sharpness conditions. Measuring contrast, color error and display profiles requires suitable equipment. The ICC calibration guide describes instrument-based calibration and profiling.

Optional selected-rate guidance

The FPS tool can compare a completed sample with the refresh rate you say is selected in the operating system. Unknown remains a valid choice. The entered rate changes the explanatory guidance only. Recorded intervals, average FPS, long gaps and the original timing exports keep the same calculations.

Touch coverage and hands-off checks

The touchscreen test receives browser pointer events. Real-touch contacts populate the coverage grid; mouse input is kept as a preview. Coverage is the share of grid cells reached during the run, rather than the percentage of physical sensors verified. A second pass lets you recheck gaps. The simultaneous-contact maximum is the greatest number of touch contacts active together in this page.

The hands-off check observes touch contacts for 20 seconds while you leave the surface untouched. Zero contacts means the behavior was not reproduced in that period. Deliberate contact also produces input. No-input, preview, incomplete and completed results stay distinct, including when focus or geometry changes interrupt a check. The reported count is the maximum observed in this page. Use a dedicated method for touch latency and the device specification for its supported contact limit.

Inspection and touch reports are generated locally. See the working-session and language-handoff rules. New inspection and manufacturer references checked 5 November 2026; the dates on earlier timing references above remain their original check dates.

Coverage counts cells containing touch positions actually received from the browser, including available coalesced samples. The line between points is a visual trail; it does not fill unobserved cells. The hands-off timer begins after a separate two-second finger-lift preparation. Cancelled input is reported separately and can require another check.