Tóm tắt về dịch vụ đo điểm chuẩn đồ hoạ của 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 phần trên mỗi khung hình. Cuối bài đăng. Bạn không thấy đúng không? Tôi sẽ giải thích thêm.
Đây là một 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 một hàm draw có tải bản vẽ tăng dần cho đến khi quá trình vẽ liên tục lâu 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 cách điểm chuẩn liên tục vẽ ngày càng nhiều hơn cho đến khi đạt đến điểm chậm lại. Đây là cách hay và đơn giản để tìm hiểu bạn có thể vẽ bao nhiêu ở tốc độ khung hình mượt mà. Bạn cũng có thể chèn 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, đúng không!
Những cảnh báo và sai lầm phổ biến khi đo điểm chuẩn đồ hoạ của trình duyệt
Vì vậy, nếu ví dụ trên là cách hay để làm điều đó, thì những cách nào không hay? Những cách dẫn đến việc bạn đo điểm chuẩn những thứ không liên quan hoặc mang lại cho bạn những chỉ số hiệu suất lạ mà dường như không liên quan gì đến tốc độ chạy ứng dụng của bạn. Rất vui vì bạn đã hỏi, sau đây là hai câu lệnh phổ biến nhất mà tôi thấy trên web.
Đo FPS tối đa: vẽ mỗi khung hình một chút và đo FPS. Tính năng này không hoạt động tốt để đo lường hiệu suất đồ hoạ trên Chrome vì quá trình 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 nhận được tối đa 60 bản cập nhật màn hình mỗi giây). Việc đo lường tốc độ hàm gọi vẽ sẽ không hữu ích lắm vì hệ thống vẽ của Chrome sẽ đặt các lệnh vẽ của bạn vào vùng đệm lệnh và lệnh này sẽ được thực thi ở 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ạ là một ý tưởng không hay. Khoảng thời gian setTimeout được giới hạn là 4 mili giây trong trình duyệt, vì vậy, bạn có thể tối đa hoá khoảng thời gian này là 250 khung hình/giây. Trước đây, các trình duyệt có cá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ẽ rất nhỏ bị hỏng, cho thấy trình duyệt A chạy ở tốc độ 250 FPS (khoảng thời gian tối thiểu 4 mili giây) và trình duyệt B chạy ở tốc độ 100 FPS (khoảng thời gian tối thiểu 10 mili giây). Rõ ràng là A nhanh hơn! Không! Cũ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ẽ nhỏ 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ộ, tất cả các giá trị dự đoán đều bị tắt. Không sử dụng setTimeout trừ khi 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 nó lên cho đến khi tốc độ khung hình bắt đầu chậm. Ví dụ: nếu bạn đang viết một trò chơi từ trên xuống với địa hình ô bản đồ, hãy thử vẽ sơ đồ ô vuông cho 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 cho mỗi khung, với khoảng trống ở giữa). Tiếp tục tăng cho đến khi FPS giảm xuống một mức ổn định mới. Bây giờ, bạn đã biết có bao nhiêu lớp bản đồ ô (tilemap) mà bạn có thể vẽ trên mỗi khung.
Các ứng dụng đồ hoạ khác nhau có những nhu cầu khác nhau, vì vậy, bạn nên lưu ý đến điều này khi viết phép đo điểm chuẩn. Đo lường các tính năng đồ hoạ mà bạn đang sử dụng trong ứng dụng. Khi bạn phát hiện tình huống tốc độ chậm, hãy cố gắng giảm xuống đoạn mã nhỏ nhất có thể tái hiện hoạt động đó (và gửi báo cáo lỗi tại new.crbug.com nếu việc này cần diễn ra nhanh hơn).
Để tìm hiểu cách viết mã đồ hoạ web hiệu suất cao, hãy tham khảo buổi trò chuyện tại Google I/O 2012 của Nat Duca và Tom Wiltzius, thành viên của nhóm GPU Chrome.