LINUX.ORG.RU

firefox-esr с mozilla.org и из debian - разный fps

 , ,


0

2

Собственно сравнил 102.15.1 esr - одно из пакета из официальной дебиан репы, второе скачанное с сайта мозиллы. В первом регулярно обнаруживается слайдшоу, во втором таких проблем нет.

Проблема, кажется, старая, потому что ещё во времена примерно фф 30 я помню скачал фф с мозиллы чтоб получить версию новее (в дебиане было что-то сильно устаревшее) и тоже заметил разительную разницу в фпс - тогда я это связал с тем что с старом фф просто джаваскрипты хуже работали, но видимо дело было не в этом а в чём-то другом.

Собственно фпс сравнивал в игре https://orteil.dashnet.org/cookieclicker/ - в мозилловском пакете там всё плавно и хорошо, в дебановском дёрганая картинка уже на стадии загрузки (когда крутятся шарики посередине экрана, эту стадию можно искуcственно удлинить если залагать себе инет - зафайрволить что-нить нужное ему в DROP).

А вы что-нить такое замечали? С чем это связано?

Оба фф запускал в новом чистом профиле (одном и том же).

Из заметной разницы (кроме фпс) - в мозилловском пакете нет звука т.к. он только пульсу ищет которой нет.

------------------

Профайлер deb: https://ibb.co/jHqYXxB

Профайлер moz: https://ibb.co/5c4mt5X

Видно что рендер запускается где-то раз в 300мс и грузит проц больше чем рендер в mozilla-пакете. А само 300мс берется из того что сама вкладка этим 300мс перед эти тоже грузит проц, а в moz-пакете гораздо меньше.

Зелёное в Render это в основном RenderThread::UpdateAndRender (во вкладке Marker Table эти пики называются «Composite #1»)

Синее в работе вкладки это «CanvasRenderingContext2D.drawImage»

По этому названию нашёл обсуждение но не знаю насколько оно связано - там про дебиан ничего не говорят.

upd: кажется не связано, ввёл в консоли CanvasRenderingContext2D.prototype.clip = function() { }; и ничего не поменялось в плане скорости

Ввёл CanvasRenderingContext2D.prototype.drawImage = function() {};, после этого затраты на эту функцию в проце вкладки исчезли (как и соответствующие картинки на странице), а вот процесс render всё так же продолжает лагать и тратит по 100мс на одну итерацию (даже увеличилось - до этого тратила около 95мс). В мозилловском пакете же 10-20мс.

------------------

Компактный пример для воспроизведения проблемы: firefox-esr с mozilla.org и из debian - разный fps (комментарий)

Как оказалось, js ни при чём, в примере его вообще нет. Но проблема как-то побочно задевает js тоже (а конкретно функцию CanvasRenderingContext2D.prototype.drawImage - она начинает в этих условиях работать в разы медленнее). В приведённом же примере js нет и лаги видны только в RenderThread::UpdateAndRender (это внутренняя функция в исходниках фф как я понял).

--------------------

Сравнение about:buildconfig firefox-esr с mozilla.org и из debian - разный fps (комментарий)

--------------------

Обновление: firefox-esr с mozilla.org и из debian - разный fps (комментарий)

★★★★★

Последнее исправление: firkax (всего исправлений: 19)

Ответ на: комментарий от unC0Rr

Не лучше ли тогда иметь арену на 4 гига, пользоваться 32 битными смещениями и иметь все плюшки 64-битного режима в виде инструкций и регистров?

В теории - наверное да. Но на практике - переписывать MLOC codebase так себе идея (Вы действительно хотите sizeof(void*) == 4). Существует x32 ABI, но я не слышал чтобы он поддерживался крупными игроками, в частности в лице RH. А до тех пор - для условного enterprise идея скорее мертва.

bugfixer ★★★★
()

Пробовал в рамках дальнейших тестов скомпилить 115 - не компилируется

 0:14.83 toolkit/library/rust/force-cargo-library-build
 0:27.63    Compiling dns-parser v0.8.0
 0:33.72    Compiling style v0.0.1 (/home/testuser/ff-moz5/firefox-115.7.0/servo/components/style)
17:39.25 fatal runtime error: Rust cannot catch foreign exceptions
17:39.57 error: could not compile `style`
17:39.57 Caused by:
17:39.58   process didn't exit successfully: `/usr/bin/rustc (...)`
17:40.09 gmake[4]: *** [/home/testuser/ff-moz5/firefox-115.7.0/config/makefiles/rust.mk:441: force-cargo-library-build] Error 101
17:40.09 gmake[3]: *** [/home/testuser/ff-moz5/firefox-115.7.0/config/recurse.mk:72: toolkit/library/rust/target] Error 2
17:40.09 gmake[2]: *** [/home/testuser/ff-moz5/firefox-115.7.0/config/recurse.mk:34: compile] Error 2
17:40.09 gmake[1]: *** [/home/testuser/ff-moz5/firefox-115.7.0/config/rules.mk:361: default] Error 2
17:40.09 gmake: *** [client.mk:60: build] Error 2
17:40.10 121 compiler warnings present.

Судя по тому что написано в инете это может быть из-за нехватки памяти (в данном случае - 32битного процесса). Но прямых указаний на out of memory не видно.

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

в данном случае - 32битного процесса

Имеется в виду, что в x86_64 системе компиляция отработала бы?

Так-то я не знаю про нюансы, сам компилирую только из AUR. ) Но глянул тему при компиляции не хватает памяти., там особенность, что в x86 не хватает памяти, а в x86_64 - ok.

krasnh ★★★
()
Ответ на: комментарий от krasnh

То, что компиляция фф на 32 битах не влезает в память - это официальная позиция мозиллы (они её компилируют кросскомпилятором 64->32 кажется или что-то похожее). Но в дебиане немного пропатчили сборку (убрали отладочные символы и ещё что-то может) чтоб влезала. На фф 102 я то же самое сделал и помогло (правда там вроде явно писалось что out of memory а не этот непонятный краш). А на фф115 не знаю - вот ошибка про которую в инете пишут что она может быть из-за памяти. Дебиановский пакет для 115 собирается норм, опять походу расследовать в чём разница. Весьма утомляет после правки ждать от получаса до суток чтоб узнать помогло ли.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 2)