Paint in Browser Rendering

Painting converts the browser's laid-out visual representation into drawing instructions for visible content such as backgrounds, borders, text, and images. It follows layout and generally produces paint records that can later be rasterized into pixels for display.

Paint is a rendering stage that comes after style calculation and layout. The browser determines what visual content must be drawn and records operations for items such as backgrounds, borders, text, images, shadows, and other visual effects.

Painting is different from layout: layout determines geometry, while paint determines how that geometry should appear visually. For example, layout can establish an element's size and position, while paint describes drawing its background and text at that location.

Modern browser engines may represent paint work as display lists or similar intermediate drawing instructions rather than immediately producing final pixels. Those instructions can then be rasterized by the rendering pipeline, potentially on raster threads or other processes depending on the browser architecture.

Not every visual update requires a full repaint. Browsers can invalidate only affected regions or use compositing to update certain elements without repainting everything. Properties such as `transform` and `opacity` can often be handled efficiently when an element is placed on an appropriate composited layer, although the exact behavior depends on the browser and circumstances.

Paint can be expensive when large areas or complex visual effects must be redrawn. Excessive shadows, filters, large repaints, and frequent changes to paint-affecting properties can therefore contribute to rendering performance problems.

Key points

Interview questions

What is the difference between paint and rasterization?

Paint determines the drawing operations required for the visual representation. Rasterization takes those operations and produces actual pixel data for a surface or tile. Keeping the concepts separate is useful because a page can have substantial paint work without treating paint itself as the final pixel-generation step.

Why can large or complex paint operations hurt frontend performance?

Painting consumes CPU or other rendering resources, and expensive visual effects can increase the amount of work required per frame. Large invalidated regions can also force substantial areas to be repainted. If this work cannot complete within the frame budget, visual updates may become less smooth.

What happens during the paint stage of browser rendering?

The browser takes the geometry established by layout and determines the visual operations needed to render it. These operations can include drawing backgrounds, borders, text, images, and effects. The resulting paint information can then be consumed by later rasterization and compositing stages.

Does changing CSS always cause a repaint?

No. The required rendering work depends on which property changed and how the browser can update the affected content. A change that affects geometry can require layout and subsequent paint, while some changes can be handled through compositing. Browsers also use invalidation to limit repainting to affected areas when possible.

How would you investigate a page that appears to have excessive paint work?

I would profile the page with browser performance tooling and identify frames with significant paint or rendering time. I would inspect which regions are being invalidated and which CSS properties or DOM changes trigger the work. Then I would determine whether the issue is large repaint regions, expensive visual effects, unnecessary updates, or inappropriate layerization, and validate any optimization with another trace.