How Browsers Work · Part 13 — GPU & the Compositor: Raster, Tiles & Layers

Đi sâu vào nửa sau pipeline render của Chromium: property trees/layers, tiling, software/GPU raster, compositor thread, Viz và fast path của transform/opacity.

OCT 29, 2026 5 MIN READ

Phần 5 dừng ở “composite layer”. Mười phần chuyên sâu này mở từng hộp đen còn lại — bắt đầu bằng nửa sau của pipeline render, nơi lệnh paint biến thành pixel trên màn hình. Đây là lãnh địa của compositor thread, raster workers và Viz/GPU process trong Chromium; hiểu nó giải thích vì sao hai animation nhìn giống nhau có thể đi qua hai đường render khác hẳn.

Sự thật cốt lõi từ Phần 1 quay lại ở đây: luồng chính ghi lệnh paint, nhưng việc biến chúng thành bitmap và ghép lên màn hình diễn ra ngoài luồng chính. Đó là lý do tồn tại của cả phần này.

1. Layer — vì sao trang được chia tầng

Trình duyệt không vẽ cả trang thành một ảnh phẳng sau mỗi thay đổi. Chromium duy trì paint chunks, property trees và một danh sách layer để compositor có thể xử lý độc lập những phần phù hợp. Hình dung compositing layer như các tấm kính trong suốt xếp chồng — hữu ích về mặt mental model, dù cấu trúc nội bộ không ánh xạ 1–1 với DOM.

Engine tự quyết định layerization theo nội dung, thiết bị và chi phí. Những tín hiệu thường khiến nội dung được composited riêng gồm:

animation transform hoặc opacity đủ điều kiện
will-change: transform/opacity
video/WebGL hoặc nội dung đã có surface tăng tốc riêng
position: fixed/sticky trong vài trường hợp

Lợi ích: sau lần paint/raster ban đầu, nếu thay đổi chỉ tác động tới transform hay opacity của nội dung đã composited, compositor có thể ghép lại các tài nguyên cũ — không cần chạy lại style/layout/paint cho từng frame. Đây là khả năng tối ưu, không phải bảo đảm của CSS.

Trang  ──► layerize ──►  Layer 0 (nội dung tĩnh)
                         Layer 1 (modal đang fade — opacity)
                         Layer 2 (sidebar đang trượt — transform)
                              │
                  compositor ghép lại → 1 ảnh cuối

2. Tiling — chia layer thành ô

Một layer có thể rất lớn (trang cuộn dài hàng chục nghìn px). Vẽ toàn bộ là phí. Compositor chia phần lớn nội dung thành tiles với kích thước do implementation chọn, ưu tiên raster tile trong hoặc sắp đi vào viewport theo ngân sách bộ nhớ.

Layer (cao 20000px)        Chỉ raster tile quanh viewport
┌──────────┐               ┌──────────┐
│ tile     │               │░░░░░░░░░░│ ← chưa raster
│ tile     │   tiling →     │██████████│ ← viewport (raster)
│ tile     │               │██████████│ ← + vùng đệm
│ ...      │               │░░░░░░░░░░│
└──────────┘               └──────────┘

Đây là lý do cuộn nhanh tới vùng chưa raster đôi khi thấy checkerboard (ô trắng) chớp một nhịp trước khi nội dung xuất hiện — tile chưa kịp raster.

3. Raster — biến lệnh paint thành bitmap

Raster là quá trình thực thi danh sách lệnh paint (vẽ chữ nhật này, text kia, ảnh nọ) để tạo tài nguyên pixel cho mỗi tile. Chromium có cả software raster trên worker threads lẫn GPU raster; chế độ thực tế phụ thuộc nền tảng, driver, nội dung và khả năng của GPU process.

Paint records (lệnh)         Raster              Bitmap (pixel)
"fillRect #fff"      ──►   raster thread   ──►   [pixel...]
"drawText 'Hi'"            (software hoặc GPU)   mỗi tile một tài nguyên

Điểm quan trọng: raster ≠ paint. “Paint” (Phần 5) chủ yếu là ghi display items/paint records; “raster” là thực thi chúng thành pixel, thường trên worker threads hoặc qua GPU process. Tách hai bước cho phép xếp lịch và chạy song song nhiều phần việc.

4. Compositor thread — người điều phối

Compositor thread là ngôi sao của phần này. Nó:

Nhận state đã commit từ luồng chính: paint records, layer list và property trees.
Ưu tiên tile cần raster theo viewport/ngân sách, rồi lập task cho raster workers hoặc Viz.
Tạo compositor frame gồm render passes/draw quads và gửi tới display compositor.
Có thể tự xử lý nhiều thao tác scroll và animation compositor-eligible mà không chờ Blink/main thread.

Bước 4 là lợi thế kiến trúc: nếu scroll/animation đi đúng fast path và tile đã sẵn sàng, compositor có thể cập nhật khung hình dù luồng chính đang bận. Raster trễ, input cần main thread hoặc áp lực GPU vẫn có thể làm rớt frame.

Main thread          Compositor thread        GPU process (Viz)
style→layout→paint ─commit─► layer tree
(record lệnh)               ├─ chọn tile → raster threads → bitmap
                            └─ draw quads ──────────────► composite → màn hình

5. GPU process & Viz — tổng hợp khung hình

Renderer gửi compositor frame tới Viz. Surface Aggregator trong display compositor kết hợp surface từ renderer, iframe và UI trình duyệt; đường GPU hoặc software compositor sau đó đưa khung hình tới hệ thống hiển thị theo nhịp refresh/VSync.

Tách GPU service khỏi renderer giúp cô lập driver/API đồ hoạ — một bề mặt tấn công và nguồn crash phức tạp. Chromium còn có thể rơi về software raster/compositing khi tăng tốc GPU không khả dụng; “GPU” vì thế không phải điều kiện bắt buộc để trang được vẽ.

6. Vì sao transform/opacity “rẻ” ở tầng phần cứng

Giờ ta thấy lý do thật sự, không chỉ “compositor lo”:

Thay đổi	Cần làm lại
Đổi `width`/`top`/`left`	Thường cần layout (Phần 5), rồi có thể paint/raster/composite
Đổi `color`/`background`	Thường cần paint/raster, rồi composite
Đổi `transform`/`opacity` đủ điều kiện	Có thể chỉ composite sau lần raster ban đầu

Ở fast path, transform/opacity chỉ đổi cách ghép tài nguyên đã raster. Nhưng clipping, filter, thay đổi nội dung, thiếu layer phù hợp hoặc giới hạn thiết bị có thể khiến engine chọn đường khác. Hãy xác nhận bằng Performance/Rendering tools thay vì suy từ tên property.

Cạm bẫy: will-change tràn lan có thể tạo thêm layer/tile, tăng bộ nhớ, raster, overdraw và thời gian composite. Layer không nhất thiết là một bitmap nguyên khối trong VRAM, nhưng “layer explosion” vẫn có thể làm chậm — chỉ khai báo cho phần tử sắp thay đổi và bỏ khi không còn cần.

7. Tóm tắt

Chromium dùng paint chunks/property trees/layer list để compositor xử lý độc lập phần nội dung phù hợp; mental model “tấm kính” không ánh xạ 1–1 với DOM.
Nội dung lớn được chia tile và ưu tiên theo viewport/ngân sách; tile chưa sẵn sàng có thể gây checkerboard.
Raster thực thi paint records bằng software worker hoặc GPU raster — khác với bước ghi lệnh paint.
Compositor thread điều phối tile và compositor frame; scroll/animation đủ điều kiện có thể tiếp tục mà không chờ main thread.
Viz/display compositor tổng hợp surface từ nhiều renderer/UI; hệ thống có cả đường GPU lẫn software fallback.
transform/opacity có thể chỉ cần composite, nhưng promotion không phải hợp đồng; tránh will-change tràn lan và luôn đo trace.

Phần tiếp theo: Scrolling internals — compositor fast path hoạt động khi nào, điều gì buộc input chờ luồng chính, và cơ chế của passive listeners, scroll anchoring cùng scroll-driven effects.