نحوه اندازه گیری عملکرد گرافیکی مرورگر

محک زدن گرافیک مرورگر به طور خلاصه: تا جایی که می توانید بکشید و در عین حال نرخ فریم صافی را حفظ کنید. هنگامی که نرخ فریم شما کاهش می یابد، می دانید که چقدر می توانید در هر فریم بکشید. پایان پست. نه؟ باشه بیشتر توضیح میدم

زمان مثال! در اینجا یک قطعه کد کوچک با عملکرد tick محک است. تابع tick یک تابع draw را با بار قرعه کشی فزاینده فراخوانی می کند تا زمانی که قرعه کشی به طور مداوم بیش از 33 میلی ثانیه طول بکشد.

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);

مثال زنده را در jsFiddle ببینید

می‌توانید ببینید که چگونه بنچمارک بیشتر و بیشتر ترسیم می‌کند تا زمانی که به نقطه‌ای برسد که سرعتش کاهش پیدا کند. این یک راه خوب و ساده است برای اینکه بفهمید چقدر می توانید با نرخ فریم صاف بکشید. شما همچنین می توانید تابع رسم خود را به مثال وصل کنید و برخی از معیارهای سفارشی را انجام دهید، بله!

اخطارها و مشکلات رایج هنگام محک زدن گرافیک مرورگر

بنابراین، اگر مثال بالا روش خوبی برای انجام آن است، راه‌های نه چندان خوب کدامند؟ راه هایی که منجر به محک زدن چیزهای نامرتبط می شود یا معیارهای عملکرد عجیبی را به شما ارائه می دهد که به نظر می رسد ارتباطی با سرعت اجرای برنامه شما ندارد. خوشحالم که پرسیدید، در اینجا دو مورد از متداول ترین مواردی که در سرتاسر وب دیده ام وجود دارد.

اندازه گیری حداکثر FPS: هر فریم را کمی ترسیم کنید و FPS را اندازه بگیرید. برای اندازه‌گیری عملکرد گرافیکی در Chrome خوب کار نمی‌کند، زیرا پیاده‌سازی گرافیکی زیربنایی با نرخ تازه‌سازی صفحه همگام‌سازی می‌شود (بنابراین حداکثر 60 به‌روزرسانی صفحه نمایش در هر ثانیه دریافت می‌کنید). اندازه گیری سرعت تماس قرعه کشی نیز چندان مفید نخواهد بود زیرا سیستم ترسیم کروم دستورات ترسیم شما را در یک بافر فرمان قرار می دهد که در تازه سازی صفحه بعدی اجرا می شود.

استفاده از setTimeout برای اندازه گیری عملکرد گرافیکی ایده بد دیگری است. فاصله setTimeout در مرورگرها به 4 میلی‌ثانیه محدود می‌شود، بنابراین حداکثر بهره‌برداری از آن 250 فریم بر ثانیه است. از لحاظ تاریخی، مرورگرها حداقل فواصل زمانی متفاوتی داشتند، بنابراین ممکن است شما یک معیار ترسیم بسیار ناچیز داشته باشید که مرورگر A را با سرعت 250 FPS (فاصله 4 میلی‌ثانیه) و مرورگر B را با سرعت 100 فریم در ثانیه (فاصله 10 میلی‌ثانیه) نشان می‌دهد. واضح است که A سریعتر است! نه! ممکن است B کد قرعه کشی را سریعتر از A اجرا کند، مثلاً A 3 میلی ثانیه و B 1 میلی ثانیه طول کشیده است. بر FPS تأثیر نمی گذارد، زیرا زمان قرعه کشی کمتر از حداقل فاصله setTimeout است. و اگر مرورگر به صورت ناهمزمان رندر شود، همه شرط ها خاموش هستند. از setTimeout استفاده نکنید مگر اینکه بدانید در حال انجام چه کاری هستید.

چگونه آن را انجام دهید

یک راه بهتر برای معیار این است که از یک بار ترسیمی واقعی استفاده کنید و آن را تا زمانی که نرخ فریم شروع به کاهش کند ضرب کنید. به عنوان مثال، اگر در حال نوشتن یک بازی از بالا به پایین با یک زمین نقشه هستید، سعی کنید نقشه کاشی را در هر فریم بکشید و ببینید که آیا با سرعت 60 فریم در ثانیه اجرا می شود یا خیر. اگر بله، بار را افزایش دهید (نقشه کاشی را دو بار در هر فریم بکشید، با یک واضح در بین). تا زمانی که FPS به یک سطح پایدار جدید کاهش یابد، به افزایش ادامه دهید. اکنون می دانید که در هر فریم چند لایه نقشه کاشی می توانید ترسیم کنید.

برنامه های گرافیکی مختلف نیازهای متفاوتی دارند، بنابراین باید معیارهای خود را با در نظر گرفتن آن بنویسید. ویژگی های گرافیکی که در برنامه خود استفاده می کنید را اندازه گیری کنید. وقتی سناریوی کندی پیدا کردید، سعی کنید آن را به کوچک‌ترین کدی که آن را بازتولید می‌کند کاهش دهید (و اگر سریع‌تر باشد، گزارش اشکال را در new.crbug.com ارسال کنید.)

برای مشاهده نحوه نوشتن کدهای گرافیکی وب با کارایی بالا، بحث Google I/O 2012 توسط Nat Duca و Tom Wiltzius از تیم کروم GPU را بررسی کنید.