Подтвердить что ты не робот

WebGL и Chrome: высокое разрешение приводит к плохой производительности

У меня есть приложение, созданное с помощью LibGDX. Я могу запустить приложение на рабочем столе, и он работает со скоростью 90 кадров в секунду при 1080p.

В Firefox он работает со скоростью 40-50 fps @1080p (максимальное окно).

В Chrome он работает со скоростью 30 fps @1080p (максимальное окно).

Однако в Chrome, если я снижу разрешение, производительность удваивается (до 60 кадров в секунду). На Firefox этого не происходит. Что может быть причиной этого?

Я использую webkitRequestAnimationFrame.

Как показано, я знаю, что мой компьютер может отлично справляться с разрешением.

Изменить

Я пытаюсь применить приведенные ниже советы, хотя они, похоже, нацелены на мобильные графические процессоры в основном.

Источник: https://wiki.mozilla.org/Platform/GFX/MobileGPUs#Memory_Bandwidth

Всегда вызывайте glClear сразу после glBindFramebuffer

См. документ Adreno 200, раздел 3.2.1: "необходимо (a) использовать очистку при переключении объектов буфера кадров (FBOs), чтобы избежать попытки драйвера сохранять/восстанавливать содержимое GMEM и (b) всегда очистите буфер глубины в начале кадра."

Это имеет смысл, поэтому мы всегда должны это делать. Конкретно, это означает, что мы должны делать glClear после каждого вызова glBindFramebuffer, в идеале сразу после него, или, по крайней мере, перед любым призывом к вызову.

привязки Framebuffer дороги

Изменение привязки кадров фреймбуфера, немедленно разрешающее рендеринг текущего фреймбуфера. Поэтому важно сортировать рендеринг, чтобы свести к минимуму привязки framebuffer. Документ Adreno 200, раздел 3.2.4, содержит полезное объяснение.

Изменить

Вышеуказанное не имело заметной разницы.

Изменить

У меня такое чувство возникает из-за компилятора GLSL. У меня нет большого количества знаний по этому вопросу, но я считаю, что GLSL для OpenGL ES скомпилирован в обычный GLSL с некоторым кодом, специфичным для браузера. Может быть, Chrome компилируется менее оптимально и заставляет фрагментацию затухания замедлять работу программы при более высоких разрешениях.

Если у кого-то есть советы по тому, как убедиться в том, что эта компиляция оптимизирована, я могу попробовать это и посмотреть, исправляет ли она проблему.

Изменить

Проблема не кажется распространенной в Chrome на Windows с набором микросхем Intel HD 4000+. Версия для Chrome: 40.0.2214.111 m. Низкое разрешение: 45fps ~. Высокое разрешение: 30 кадров в секунду.

Мой оригинальный тестовый пример был с Chrome на Ubuntu с GTX 650. Версия Chrome будет добавлена ​​позже.

Изменить

Версия Chrome, которая отображает эту проблему: 40.0.2214.111 (64-разрядная версия) на Ubuntu на графической карте GTX 650.

Изменить

На том же ПК с GTX 650 под Windows 7 одно и то же приложение работает под углом 60 кадров в секунду под Chrome. Поскольку в Ubuntu приложение, скомпилированное для Java, отлично работает на скорости 90 кадров в секунду, я считаю, что это не проблема с драйвером Linux, а скорее проблема с версией Chrome в Chrome.

Изменить

Я отправил сообщение об ошибке в Chrome об этом.

4b9b3361

Ответ 1

Не включая другие вещи здесь, насколько я был в последний раз, все те requestAnimationFrame методы ограничены 60fps и могут идти только ниже.

Вы можете протестировать его с помощью этого бита: http://cssdeck.com/labs/gvxnxdrh/. Вы можете изменить fps var как можно выше, но анимация не будет быстрее 60 кадров в секунду в любом браузере, который у меня был на рабочем столе.