Tóm tắt về việc đo điểm chuẩn đồ hoạ trình duyệt: vẽ nhiều nhất có thể trong khi vẫn duy trì tốc độ khung hình mượt mà. Khi tốc độ khung hình giảm, bạn sẽ biết mình có thể vẽ bao nhiêu trên mỗi khung hình. Kết thúc bài đăng. Bạn không thấy đúng không? Được rồi, tôi sẽ giải thích thêm một chút.
Giờ là lúc xem ví dụ! Dưới đây là một đoạn mã nhỏ có hàm tick đo điểm chuẩn. Hàm tick gọi hàm draw với tải bản vẽ tăng dần cho đến khi bản vẽ mất nhiều thời gian hơn 33 mili giây.
var t, previousTime;
var drawLoad = 1;
var slowCount = 0;
var maxSlow = 10;
// Note, you might need to polyfill performance.now and requestAnimationFrame
t = previousTime = performance.now();
var tick = function() {
var maximumFrameTime = 1000/30; // 30 FPS
t = performance.now();
var elapsed = t - previousTime;
previousTime = t;
if (elapsed < maximumFrameTime || slowCount < maxSlow) {
if (elapsed < maximumFrameTime) {
drawLoad+=10;
} else {
slowCount++;
}
draw(drawLoad);
requestAnimationFrame(tick);
} else {
// found maximum sustainable load at 30 FPS
document.getElementById('res').innerHTML = ("could draw "+(drawLoad)+" in " +
maximumFrameTime + " ms");
}
};
requestAnimationFrame(tick);
Xem ví dụ trực tiếp tại jsFiddle
Bạn có thể thấy điểm chuẩn liên tục vẽ nhiều hơn cho đến khi đạt đến điểm chậm lại. Đây là một cách đơn giản và hiệu quả để xác định số lượng khung hình bạn có thể vẽ ở tốc độ khung hình mượt mà. Bạn cũng có thể cắm hàm vẽ của riêng mình vào ví dụ và thực hiện một số phép đo điểm chuẩn tuỳ chỉnh.
Các lưu ý và cạm bẫy thường gặp khi đo điểm chuẩn đồ hoạ trình duyệt
Nếu ví dụ trên là cách hay để thực hiện, thì những cách không hay là gì? Những cách khiến bạn đo điểm chuẩn cho những thứ không liên quan hoặc cung cấp cho bạn các chỉ số hiệu suất kỳ lạ dường như không liên quan gì đến tốc độ chạy của ứng dụng. Tôi rất vui khi bạn hỏi. Sau đây là hai lỗi phổ biến nhất mà tôi từng thấy trên web.
Đo lường FPS tối đa: vẽ một chút trên mỗi khung hình và đo lường FPS. Chỉ số này không hoạt động hiệu quả để đo lường hiệu suất đồ hoạ trên Chrome vì việc triển khai đồ hoạ cơ bản được đồng bộ hoá với tốc độ làm mới màn hình (vì vậy, bạn sẽ nhận được tối đa 60 lần cập nhật màn hình mỗi giây). Việc đo tốc độ lệnh gọi vẽ cũng sẽ không hữu ích lắm vì hệ thống vẽ của Chrome sẽ đưa các lệnh vẽ của bạn vào vùng đệm lệnh được thực thi trong lần làm mới màn hình tiếp theo.
Việc sử dụng setTimeout để đo lường hiệu suất đồ hoạ cũng là một ý tưởng không hay. Khoảng thời gian setTimeout bị giới hạn ở mức 4 mili giây trong trình duyệt, vì vậy, tốc độ khung hình tối đa mà bạn có thể đạt được là 250 khung hình/giây. Trước đây, các trình duyệt có khoảng thời gian tối thiểu khác nhau, vì vậy, bạn có thể đã có một điểm chuẩn vẽ nhỏ rất bị hỏng cho thấy trình duyệt A chạy ở tốc độ 250 khung hình/giây (khoảng thời gian tối thiểu 4 mili giây) và trình duyệt B chạy ở tốc độ 100 khung hình/giây (khoảng thời gian tối thiểu 10 mili giây). Rõ ràng là A nhanh hơn! Không! Có thể B chạy mã vẽ nhanh hơn A, giả sử A mất 3 mili giây và B mất 1 mili giây. Không ảnh hưởng đến FPS, vì thời gian vẽ ít hơn khoảng thời gian setTimeout tối thiểu. Và nếu trình duyệt hiển thị không đồng bộ, thì mọi thứ sẽ không diễn ra như dự kiến. Đừng sử dụng setTimeout trừ phi bạn biết mình đang làm gì.
Cách thực hiện
Một cách tốt hơn để đo điểm chuẩn là sử dụng tải bản vẽ thực tế và nhân tải đó cho đến khi tốc độ khung hình bắt đầu bị giật. Ví dụ: nếu bạn đang viết một trò chơi từ trên xuống có địa hình bản đồ ô, hãy thử vẽ bản đồ ô mỗi khung hình và xem liệu trò chơi có chạy ở tốc độ 60 khung hình/giây hay không. Nếu có, hãy tăng tải (vẽ bản đồ ô hai lần mỗi khung hình, với một bản rõ ở giữa). Tiếp tục tăng cho đến khi FPS giảm xuống một mức ổn định mới. Giờ đây, bạn đã biết số lớp của bản đồ ô mà bạn có thể vẽ trên mỗi khung hình.
Các ứng dụng đồ hoạ khác nhau có nhu cầu khác nhau, vì vậy, bạn nên viết điểm chuẩn của mình theo đó. Đo lường các tính năng đồ hoạ mà bạn đang sử dụng trong ứng dụng. Khi bạn thấy một trường hợp chậm, hãy cố gắng giảm trường hợp đó xuống đoạn mã nhỏ nhất có thể tái tạo trường hợp đó (và gửi báo cáo lỗi tại new.crbug.com nếu trường hợp đó cần nhanh hơn).
Để xem cách viết mã đồ hoạ web hiệu suất cao, hãy xem bài nói chuyện của Nat Duca và Tom Wiltzius thuộc nhóm GPU của Chrome tại Google I/O 2012.