Cập nhật Ladybird tháng 4/2026: Trình xem PDF, giao diện GTK4 và tối ưu hóa hiệu năng JavaScript

Chào mừng bạn đọc đến với bản tin tháng 4 của Ladybird! Trong tháng vừa qua, chúng tôi đã hợp nhất 333 pull requests từ 35 người đóng góp, trong đó có 7 người lần đầu tiên gửi commit cho dự án. Dưới đây là những điểm nhấn đáng chú ý trong đợt cập nhật này.

Chào đón nhà tài trợ mới

Ladybird hoạt động hoàn toàn dựa trên sự hỗ trợ hào phóng từ các công ty và cá nhân tin tưởng vào một web mở. Tháng này, chúng tôi rất vui mừng chào đón những nhà tài trợ mới:

• Human Rights Foundation (thông qua chương trình "AI for Individual Rights") với khoản đóng góp 50.000 USD.
• Jakub Stęplowski với khoản đóng góp 1.000 USD.

Chúng tôi vô cùng biết ơn vì sự hỗ trợ này. Nếu bạn quan tâm đến việc tài trợ cho dự án, vui lòng liên hệ với chúng tôi.

Trình xem PDF tích hợp

PDF hiện nay có thể được hiển thị trực tiếp ngay trong trình duyệt thông qua trình xem pdf.js được tích hợp sẵn (#9132). pdf.js là một trình xem PDF đầy đủ tính năng được viết hoàn toàn bằng JavaScript, HTML và CSS, hỗ trợ điều hướng trang, chọn văn bản, phóng to và tìm kiếm trong tài liệu.

Việc hiệu năng hóa quá trình pdf.js tải Tài liệu hướng dẫn ISA của Intel cũng đã thúc đẩy các cải tiến đối với bộ nhớ đệm typed-array view và tính năng vô hiệu hóa :has().

Trình xem PDF tích hợp

Lịch sử duyệt web và thanh địa chỉ thông minh

Khi bạn nhập vào thanh địa chỉ, giờ đây bạn sẽ nhận được các gợi ý phong phú dựa trên lịch sử: các trang đã truy cập kèm theo favicon và tiêu đề, phím tắt công cụ tìm kiếm và hoàn thành URL đơn thuần (#8933).

Thanh địa chỉ với gợi ý lịch sử

Về mặt kỹ thuật, một HistoryStore được hỗ trợ bởi SQLite sẽ lưu trữ mọi thao tác điều hướng cùng với tiêu đề, favicon, số lần truy cập và thời gian truy cập cuối cùng. Tính năng "Xóa lịch sử duyệt web" cũng đã được kích hoạt trong trang Cài đặt quyền riêng tư. Cả giao diện người dùng Qt và AppKit đều hiển thị các hàng thông tin mới này.

Phân tích HTML suy luận và tăng dần

Trình phân tích HTML (HTML parser) hiện nay tiêu thụ nội dung phản hồi một cách tăng dần (#9151). Các byte dữ liệu chảy qua bộ giải mã văn bản dạng luồng vào bộ phân tích cú pháp từng khối một. Bộ phân tích sẽ tạm dừng khi hết dữ liệu đầu vào và tiếp tục khi có thêm dữ liệu mới. Điều này thay thế cho mô hình cũ nơi chúng ta phải đợi tải toàn bộ nội dung trước khi bắt đầu phân tích.

Chúng tôi cũng đã triển khai trình phân tích HTML suy luận (speculative HTML parser) (#9114). Khi trình phân tích chính bị chặn bởi một tập lệnh bên ngoài đồng bộ, một bộ phân tích riêng sẽ quét trước qua dữ liệu đầu vào chưa được phân tích và đưa ra các yêu cầu tìm nạp suy luận cho các tài nguyên mà nó tìm thấy như <img>, <link rel="stylesheet">, và <script>.

Biên dịch JavaScript ngoài luồng chính

Việc tạo mã bytecode cho mã cấp cao nhất của các tập lệnh được tìm nạp hiện chạy trên nhóm luồng nền (#9118). Các luồng worker tạo ra bytecode và dữ liệu cần thiết để xây dựng một Executable, trong khi mọi thứ liên quan đến VM hoặc đống GC vẫn giữ ở luồng chính. Điều này bao gồm các tập lệnh cổ điển, mô-đun và IIFE cấp cao nhất, giúp chuyển khoảng 200ms thời gian xử lý của luồng chính sang các luồng nền khi chỉ tải YouTube.

Raster hóa độc lập cho mỗi Navigable

Mỗi Navigable giờ đây thực hiện raster hóa độc lập trên luồng riêng của nó (#8793). Trước đây, các iframe được vẽ đồng bộ dưới dạng danh sách hiển thị lồng nhau trong danh sách hiển thị của cha mẹ, điều này có nghĩa là chỉ có luồng kết xuất của navigable cấp cao nhất mới hoạt động. Danh sách hiển thị của cha mẹ hiện tham chiếu đầu ra raster hóa của từng iframe thông qua ExternalContentSource, do đó việc vô hiệu hóa iframe không còn yêu cầu ghi lại lại phần cha mẹ.

Động cơ JavaScript

Với quá trình chuyển đổi C++/Rust đã hoàn tất, tháng 4 chúng tôi tập trung vào việc thu hoạch kết quả.

• Các cuộc gọi JS-to-JS nhanh hơn: Một chuỗi sửa đổi đa phần (#8891, #8909, #8912) đã khiến các lệnh Call, Return và End hoạt động hoàn toàn trong trình thông dịch hợp ngữ AsmInt cho trường hợp phổ biến, với tải/lưu cặp ARM64 được tinh chỉnh thủ công cho việc lưu/khôi phục thanh ghi.
• Bộ cấp phát thanh ghi bytecode O(1): Trước đây, Generator::allocate_register phải quét vùng nhớ tự do để tìm thanh ghi có số thấp nhất. Chúng tôi đã mất khoảng 800ms chỉ cho chức năng này khi tải x.com. Giờ đây, bộ cấp phát là một ngăn xếp LIFO đơn giản (#9007).
• Lặp lại for-in được lưu vào bộ nhớ đệm: Các vị trí for (key in obj) hiện lưu vào bộ nhớ đệm ảnh chụp nhanh các khóa có thể liệt kê đã được làm phẳng và tái sử dụng nó miễn là hình dạng của đối tượng nhận, bộ nhớ được lập chỉ mục và chuỗi nguyên mẫu vẫn khớp (#8856). Speedometer 2 tăng từ 67.7 lên 73.6, và Speedometer 3 từ 4.11 lên 4.22!

Ngoài ra còn có rất nhiều cải tiến nhỏ khác giúp tăng tốc độ và giảm mức sử dụng bộ nhớ.

Frontend GTK4 / libadwaita

Ladybird có một frontend Linux mới được xây dựng trên GTK4 và libadwaita, nằm cạnh frontend Qt hiện có (#8691). Nó được lấy cảm hứng từ GNOME Web (Epiphany) và tuân theo các nguyên tắc thiết kế của GNOME: không có thanh menu, menu hamburger và AdwTabView cho các tab. Ngay lập tức bạn có thể tính năng tự động hoàn thành và biểu tượng bảo mật trong thanh URL, tìm kiếm trên trang, toàn màn hình, menu ngữ cảnh, hộp thoại, clipboard, đa cửa sổ, chủ đề sáng/tối và tỷ lệ DPR.

Tính năng CSS

• image-set(): Hỗ trợ cơ bản cho dạng chuẩn và dạng có tiền tố -webkit-. Tại thời điểm vẽ, chúng tôi chọn ứng viên có độ phân giải khớp nhất với tỷ lệ pixel của thiết bị.
• position-anchor và định vị neo CSS: Hỗ trợ ban đầu cho các phần tử được định vị neo, sửa lỗi vị trí tay và súng trên cssdoom.wtf.
• Viết lại nội suy màu: Được căn chỉnh với css-color-4. Chúng tôi hiện nội suy trong float thay vì u8, xử lý chính xác các thành phần bị thiếu và không có sức mạnh, xử lý sRGB ngoài gamut và áp dụng nhân tử alpha nhất quán.

Hỗ trợ image-set()

Mạng và GPU

• DNS: getaddrinfo không còn chặn vòng lặp sự kiện. LibDNS hiện chạy các tra cứu trên nhóm luồng, kích hoạt các truy vấn A và AAAA song song.
• Linux GPU painting qua dmabuf: Trong các bản dựng Vulkan trên Linux, việc vẽ được hỗ trợ bởi GPU trước đây bị vô hiệu hóa ngầm mỗi khung hình. Giờ đây, SharedImage có thể mang theo bộ xử lý dmabuf của Linux, giúp bộ đệm phía trước và phía sau luôn nằm trên GPU trong suốt quá trình đến tiến trình UI.

Các trang web hoạt động tốt hơn

Những chiến thắng rõ ràng nhất tháng này là trên Reddit và YouTube.

• Reddit: Bộ sưu tập ảnh dạng băng chuyền (carousel) hiện hoạt động sau khi sửa hai lỗi bố cục không liên quan. Nhờ TextDecoderStream, SPA không còn nuốt các lần nhấp vào liên kết, vì vậy bạn cuối cùng có thể mở phần bình luận!
• YouTube: Tận hưởng một loạt các cải tiến không liên quan: biên dịch JS cấp cao nhất ngoài luồng, giải nén WOFF2 ngoài luồng, giảm lượng yêu cầu @font-face, sửa lỗi churn bộ nhớ RequestServer và TransferArrayBuffer zero-copy.

Điểm số WPT

Điểm số WPT của chúng tôi tăng từ 2.003.537 lên 2.067.263 trong tháng này, mức tăng chính là 63.726 bài kiểm tra con. Có một dấu sao cho con số này: WPT đã nhập test262, bộ suite phù hợp ECMAScript chính thức, thượng nguồn tháng này, thêm 53.207 bài kiểm tra con JavaScript vào tổng số. Chúng tôi vượt qua 52.045 bài (tỷ lệ đạt 97,8%).

Lời cảm ơn

Chúng tôi muốn gửi lời cảm ơn đặc biệt đến 7 người đã đóng góp mã lần đầu tiên trong tháng này: CalebC48, Darshanx256, j-stechmann, James Raspass, jarusll, slydetector và Yayoi-cs. Và tất nhiên, cảm ơn tất cả những người đã đóng góp mã trong tháng này!