Kết xuất văn bản sắc nét trên GPU

• Đề xuất một kỹ thuật kết xuất vector thời gian thực mới để giải quyết các vấn đề về chất lượng của kết xuất văn bản, đặc biệt là giới hạn của các phương pháp dựa trên SDF (trường khoảng cách)
• Bằng cách truyền trực tiếp các glyph (ký tự) ở dạng đường cong vector lên GPU để rasterize theo thời gian thực, phương pháp này đạt được độ phân giải không giới hạn và mức sử dụng bộ nhớ thấp
• Tận dụng kỹ thuật texture atlas và tích lũy theo thời gian (temporal accumulation) để hiện thực hóa chất lượng khử răng cưa cao và cơ chế cache hiệu quả
• Có thể tùy biến theo nhiều cấu trúc subpixel khác nhau (ví dụ: OLED, LCD, v.v.), nhờ đó mang lại kết quả mượt và sắc nét mà không gặp hiện tượng fringing (lem màu)
• Đưa ra một cách tiếp cận đơn giản nhưng có khả năng mở rộng cao cho kết xuất phông chữ chất lượng cao trong văn bản thời gian thực, UI, game, v.v.

---

Giới thiệu: bài toán của kết xuất văn bản

• Trong kết xuất văn bản thời gian thực, có nhiều vấn đề như aliasing (răng cưa), texture lớn, thời gian build, phóng to/thu nhỏ, chuyển động mượt
• Phương pháp Multi-Channel Signed Distance Fields (SDFs) được dùng phổ biến trước đây có những giới hạn về chất lượng và tính linh hoạt
• Gần đây, do cấu trúc subpixel phi tiêu chuẩn của màn hình OLED và vấn đề fringing, tác giả đã phát triển một cách tiếp cận mới có tính đến cả khử răng cưa subpixel

Giới hạn của phương pháp SDF hiện có

Chất lượng

• Với SDF, ở các phông chữ có nhiều chi tiết tinh hoặc nét mảnh, sẽ phát sinh vấn đề suy giảm chất lượng và mất mát thông tin
• Nếu không tăng độ phân giải, một số glyph cụ thể sẽ vẫn để lại artifact

Kích thước atlas

• SDF được tạo offline từ đầu rồi lưu vào atlas, nhưng với nhiều glyph hoặc phông chữ CJK (Trung, Nhật, Hàn) thì kích thước có thể lớn đến mức gần như không khả thi trong thực tế
• Khi dùng đồng thời nhiều phông chữ, mức tiêu thụ bộ nhớ và gánh nặng băng thông streaming tăng mạnh

Tính linh hoạt và sự đơn giản

• Vì phải đi qua bước trung gian là SDF, toàn bộ luồng từ dữ liệu nguồn đến kết quả cuối trở nên phức tạp
• Việc sử dụng trực tiếp hoặc chỉnh sửa ảnh vector theo thời gian thực hay động cũng bị hạn chế đáng kể

Cách làm mới: rasterize đường cong vector theo thời gian thực

• Thay vì tạo texture sẵn, dữ liệu đường cong vector của glyph thực sự xuất hiện trên màn hình (như đường cong Bézier) được truyền trực tiếp lên GPU và rasterize ngay tại chỗ
• Chỉ đưa các glyph cần thiết vào atlas texture, đồng thời giữ lại hoặc giải phóng tùy theo tần suất sử dụng
• Trong lúc glyph còn xuất hiện trên màn hình, hệ thống dùng tích lũy mẫu (temporal accumulation) để tạo ra kết quả mượt hơn với chất lượng khử răng cưa rất cao
• Do luôn xử lý theo kiểu dựa trên vector, phương pháp này cho kết quả sắc nét mà không bị giới hạn bởi độ phân giải

Xử lý dữ liệu đường cong phông chữ

• Dùng các thư viện mã nguồn mở như FreeType để đọc nhiều định dạng phông chữ khác nhau và trích xuất thông tin đường cong của glyph
• Glyph được phân tích thành đường thẳng, đường cong Bézier bậc hai/bậc ba, rồi mọi đường cong được chuyển thành Bézier bậc hai để đơn giản hóa xử lý trong shader GPU
  • Đường thẳng được chuyển thành đường cong bậc hai bằng cách thêm điểm điều khiển ở giữa
  • Đường cong bậc ba được tách thành 2 đường cong bậc hai

Tính coverage (mức lấp đầy bên trong pixel)

• Với mỗi pixel, hệ thống tính giao điểm giữa tia theo phương ngang và đường cong, rồi dùng winding number (số giao cắt tích lũy) để xác định bên trong/bên ngoài
• Hàng trăm mẫu (n lần tích lũy mẫu) được cộng dồn, và một số sai số vi mô hầu như không ảnh hưởng đến kết quả cuối
• Dùng kỹ thuật bố trí điểm mẫu (quasirandom sequence) để tích lũy kết quả từ nhiều vị trí khác nhau qua từng frame

Tối ưu truy cập đường cong

• Glyph được chia theo các dải ngang (band), và mỗi dải chỉ kiểm tra các đường cong có liên quan để giảm khối lượng tính toán
• Phân bố thread và lặp theo từng band giúp tối đa hiệu quả xử lý hàng loạt trên GPU

Đóng gói và quản lý atlas

• Cấp phát và quản lý ảnh của từng glyph trong atlas (texture dùng chung)
  • Với glyph chưa có, hệ thống cấp phát không gian mới để rasterize; với glyph đã có thì tái sử dụng
  • Lưu ý rằng ngay cả cùng một glyph, vẫn có thể cần các phiên bản khác nhau tùy theo vị trí subpixel và kích thước
• Hiện thực cơ chế đóng gói hiệu quả giữa bitmap 1 chiều và không gian 2D bằng Z-Order Packing (Morton code, v.v.)
  • Có thể ứng dụng linh hoạt theo cấu trúc ngôn ngữ, chẳng hạn hệ Latin ưu tiên theo chiều dọc, hệ Ả Rập ưu tiên theo chiều ngang
• Khi glyph không còn cần thiết nữa, không gian trong atlas sẽ được cấp phát lại để sử dụng tiếp

Tích lũy theo thời gian (Temporal Accumulation)

• Thông qua cơ chế cache glyph và tích lũy mẫu, hệ thống nhanh chóng đạt chất lượng mẫu cao ngay sau khi hiển thị, rồi tiếp tục tinh chỉnh qua các frame sau
  • Frame đầu dùng 8 mẫu/pixel, sau đó giảm dần số mẫu, tối đa tích lũy 512 lần
• Đảm bảo đồng thời hiển thị glyph mượt mà và tối ưu tài nguyên

Khử răng cưa subpixel và ngăn fringing

• Phân bổ vùng kết xuất ở cấp độ subpixel (coi từng phần tử như RGB là một mẫu) để tạo hiệu ứng tăng độ phân giải theo chiều ngang
  • Hỗ trợ nhiều cách sắp xếp khác nhau như cấu trúc chuẩn của LCD, OLED/WOLED, v.v.
  • Cho phép tạo hiệu ứng mượt mà mà không bị fringing (lem màu)
• Khi sắp xếp để các mẫu subpixel chồng lấp (Overlapping), phương pháp này còn phản ánh được cả hiệu ứng hòa trộn ánh sáng của màn hình thực tế
• Có thể tạo đầu ra tự nhiên và sắc nét ngay cả khi không cần biên pixel hay hinting

Tầm quan trọng của cách tiếp cận theo cấu trúc subpixel của từng màn hình

• Nếu có thể xác định bằng lập trình thông tin sắp xếp subpixel của màn hình, việc kết xuất sẽ còn tinh vi hơn nhiều
• Nhấn mạnh rằng đây không phải giới hạn của phần cứng mà là vấn đề ở cách xử lý phần mềm

Kết luận và triển vọng ứng dụng

• Kết xuất văn bản tốt ảnh hưởng lớn đến tính khả dụng tổng thể và chất lượng dịch vụ
• Đặc biệt trong UI/game, biểu diễn phông chữ chất lượng cao có thể tạo ra khác biệt lớn trong trải nghiệm sản phẩm
• Đây là một cấu trúc triển khai hiện thực được các nguyên tắc đơn giản, khả năng mở rộng, chất lượng cao, linh hoạt
• Rất phù hợp cho ứng dụng thực tế trong công nghiệp/production nhờ triển khai mã nguồn mở và khả năng hỗ trợ nhiều cấu trúc subpixel khác nhau

---

[GN⁺]

Ý kiến trên Hacker News

• Tôi là tác giả bài viết, và tôi không ngờ bài này lại được chú ý đến vậy. Cảm ơn tất cả mọi người đã tham gia vào cuộc thảo luận thú vị
• Câu hỏi về lý do dấu chấm của chữ nghiêng "j" biến mất trong video đầu tiên
• Ý kiến cho rằng render phông chữ subpixel rất quan trọng với khả năng đọc. Tuy nhiên, như tác giả chỉ ra, thật đáng tiếc khi các tiêu chuẩn màn hình hiện nay không cho phép lấy được đặc tả bố cục pixel một cách chính xác
• Có ý kiến cho rằng điều này chỉ cần thiết trên các màn hình độ phân giải tiêu chuẩn. Thực ra không hẳn là bắt buộc, mà chỉ là có thì tốt. Giờ đây màn hình cấp độ retina đã trở nên phổ biến, nên môi trường hiện nay không còn quá cần subpixel rendering nữa. Thậm chí, đây chỉ là một đổi mới mang tính tạm thời xuất hiện trong thời LCD và giờ đã có phần lỗi thời. Nó cũng có khá nhiều tác dụng phụ như ảnh chụp màn hình phụ thuộc vào bố cục subpixel, không thể phóng to bitmap, v.v. Vì vậy có thể hiểu vì sao Apple đã loại bỏ hẳn cách này khỏi macOS
• Chỉ ra rằng các tiêu chuẩn như DisplayID vốn được thiết kế để cung cấp loại thông tin bố cục này. Vấn đề chỉ là nhà sản xuất triển khai chưa tốt hoặc không được lưu trong DB; với các mẫu màn hình phổ biến thì hoàn toàn có thể ghi nhận vào cơ sở dữ liệu phần cứng để tận dụng. Xem wiki DisplayID
• Bày tỏ tiếc nuối rằng chúng ta đã biết suốt hàng chục năm về sự đa dạng của cấu trúc subpixel, và đánh giá cao việc bài gốc đã tổng hợp rất tốt. Đồng thời chia sẻ trang ví dụ được gọi là “vườn thú subpixel” subpixel zoo
• Cho rằng gọi đây là “bi kịch” thì hơi quá. Chỉ cần mỗi OS bổ sung khả năng tinh chỉnh theo từng màn hình, giống như ClearType tuner trên các bản Windows trước đây, là đủ. Cũng cần có cơ chế nhớ thiết lập người dùng phòng trường hợp màn hình báo sai thông tin
• Quan điểm cho rằng subpixel rendering không thật sự cần thiết với đa số ngôn ngữ. Chỉ với bitmap font không anti-aliasing hoặc vector font có hinting cũng đã khá dễ đọc. Tuy nhiên, với các ngôn ngữ dùng ký tự phức tạp như chữ Hán hay tiếng Nhật thì nó quan trọng hơn phần nào
• Nội dung cho rằng việc GTK4 chuyển sang render lấy GPU làm trung tâm và từ bỏ RGB subpixel rendering có liên quan đến công nghệ GPU. Nhưng vì bài gốc đã chứng minh là GPU vẫn làm được, nên có suy đoán rằng có thể còn lý do khác, nhược điểm khác, hoặc khó khăn trong việc hợp nhất stack
• Nhắc đến khả năng Cosmic Text (Cosmic DE) hỗ trợ subpixel rendering trên GPU thông qua Swash
• Nếu quan tâm đến cách triển khai SDF và MSDF trên WebGL/WebGPU thì có thể tham khảo tutorial do chính tôi viết liên kết tutorial
• Có người nói họ quan tâm đến WebGPU (WGPU) được triển khai bằng Rust. Họ cảm thấy tutorial này khá thiên về nâng cao, và thấy hiệu quả khi học bằng cách chuyển các ví dụ JS sang Rust
• Nói rằng họ rất thích định dạng của trang web này và cũng muốn làm tutorial liên quan đến GPU theo kiểu như vậy. Họ tò mò không biết đây có phải một template cụ thể hay là một phần của khóa học nào đó không
• Chia sẻ thông tin rằng thư viện Slug là middleware thương mại triển khai GPU glyph rasterizer Slug Library
• Thấy thú vị vì website của Slug công bố thuật toán khá chi tiết. Tò mò không biết có bằng sáng chế nào không. Cũng có ý nghĩ rằng sẽ rất vui nếu làm một phiên bản wgpu mã nguồn mở dùng cosmic-text để parse/layout font, nhưng lo rằng sau này có thể bị Slug kiện
• Tóm tắt lịch sử và hiện trạng của render văn bản SDF cho những người chưa quen với lĩnh vực này. Valve đã giới thiệu kiến trúc dựa trên SDF vào năm 2007, sau đó Glyphy (Behdad Esfahbod) đưa ra triển khai SDF trên GPU vào năm 2012, tạo ra một bước chuyển, nhưng các OS phổ biến và trình duyệt web vẫn chủ yếu dừng ở cách làm kiểu Truetype từ thập niên 1990. Cách này nhỏ gọn và nhẹ, nhưng không hỗ trợ căn chỉnh subpixel/bố cục tùy ý, đồng thời có nhiều hạn chế khi phóng to văn bản hay biến đổi 3D. Có lẽ sự tiến hóa công nghệ chậm như vậy là vì lợi ích không đủ lớn so với rủi ro, và vì không chỉ render mà cả các xử lý layout phức tạp như xuống dòng cũng khiến việc phối hợp GPU/CPU trở nên khó khăn
• Chỉ ra rằng các tác vụ layout văn bản như xuống dòng trên thực tế gần như tách biệt với render
• Giới thiệu Pathfinder của Servo như một ví dụ đã triển khai render văn bản GPU với hiệu năng tốt hơn nhiều bằng compute shader GPU
• Liên kết bài viết về cách WebKit render văn bản bằng GPU. Chỉ ra rằng ngay ở giai đoạn hiện tại, một phần quy trình từ chuỗi ký tự đến bitmap đã có thể được xử lý trên GPU, nhưng “subpixel anti-aliasing” như mọi người kỳ vọng lại thường vắng mặt trong các màn trình diễn quảng bá GPU
• Nhắc tới thực tế rằng không chỉ Windows mà cả Chrome/Firefox cũng đã có tăng tốc GPU cho cả subpixel anti-aliasing từ nhiều năm trước. Nhấn mạnh rằng cho rằng công nghệ mới chưa được dùng là một sự hiểu lầm
• Bình luận cảm ơn vì đã tóm tắt tổng quan một cách ngắn gọn, rõ ràng
• Tiền đề là nếu muốn subpixel rendering thì phải xác định chính xác lưới subpixel của màn hình. Có ý kiến cho rằng UX hợp lý duy nhất là yêu cầu thiết lập riêng theo từng màn hình. OS cũng phải xử lý cả các tình huống như xoay màn hình
• Đồng tình với tác giả rằng lý tưởng nhất là màn hình tự trực tiếp thông báo cho hệ thống biết cấu trúc subpixel của nó
• Đánh giá kết quả rất ấn tượng, đồng thời cho rằng subpixel anti-aliasing từng có lợi thế rõ rệt trong thời LCD đầu những năm 2000, nhưng trong thời đại màn hình retina độ phân giải cao thì gần như không còn nhiều ý nghĩa. Các nhược điểm được nêu gồm chỉ áp dụng được với nền không trong suốt, không thể hậu xử lý (resize, mirroring, blur, v.v.), và ảnh chụp màn hình có thể trông kỳ lạ trên thiết bị khác
• Có người đưa ra dữ liệu cho thấy vẫn còn nhiều người dùng desktop sử dụng màn hình độ phân giải thấp 96dpi, 1366x768, từ khảo sát phần cứng của Firefox dữ liệu
• Cũng có thêm ý kiến rằng với tư cách là người dùng màn hình độ phân giải cao, việc không quan tâm đến nhóm người dùng màn hình độ phân giải thấp là thiếu trách nhiệm
• Lo ngại rằng ngay cả khi đưa vào giao thức bố cục subpixel, một số nhà sản xuất vẫn có thể triển khai sai, dẫn đến các vấn đề render mà người dùng phổ thông khó hiểu
• Cảm nghĩ đầu tiên khi nhìn kiểu chữ viết tay (chữ thảo) là: “Rốt cuộc ai lại nghĩ kiểu chữ thảo chết tiệt này là ý tưởng hay vậy?”
• Giải thích rằng những người từng viết tay, đặc biệt trong thời dùng bút chấm mực hay bút máy, có lẽ đã thích nó
• Giải thích thêm rằng những người thường xuyên viết thư đã dùng chữ thảo, và việc sử dụng chữ thảo giảm dần khi Internet và gọi đường dài miễn phí xuất hiện
• Câu hỏi rằng không tìm thấy liên kết tới mã nguồn