Код Хромиума весьма обширен, там каждому найдётся что-то по вкусу. А я вот решил рассказать о своём любимом файле в нём (а у вас есть такой?). Этот файл отражает всё: боль, разочарование, надежду, упорство, силу воли, ответственность за чужие провалы и самопожертвование. Я иногда читаю его и плачу и проникаюсь пониманием, какая же огромная часть айсберга скрыта под водой. Это, в общем, даже не файл с кодом. Это файл с конфигом, описывающим баги видеокарт, которые Хромиуму приходится обходить для нормального отображения своих страниц на разных платформах. Вот он: https://cs.chromium.org/chromium/src/gpu/config/gpu_driver_bug_list.json
О чём вообще идёт речь? Давайте вспомним, как работает браузер: вы набираете какой-то адрес в адресной строке, браузер загружает контент и отображает его. Чуть детальнее об этом рассказывает хорошая статья «What happens when you type google.com into your browser and press enter?» (и сразу несколько её переводов на Хабре). В ней одним из последних пунктов упоминается, мол, «а теперь, когда всё готово, отрисовываем картинку на экране». Ага, вот так берём и отрисовываем, конечно.
Начнём с того, что в языках программирования почему-то нет из коробки функции «взять и нарисовать вот это на экране». Языкам и их стандартным библиотекам такие мелочи не интересны. Соответственно, универсальный кроссплатформенный код для рисования написать не так-то легко. Всякие крутые ААА-игры обходят это ограничение достаточно прямолинейно: «У вас должна быть вот такая приставка или вот такая ОС с видеокартой баксов за 800, тогда кое-как будет работать. Наверное». Спасибо за совет! Но браузер — это не игра. Браузер должен работать всегда и везде. Пользователь даже самого убитого ПК, купленного 10 лет назад (и уже тогда — на распродаже) не рассчитывает поиграть в последнего Ведьмака, но будет искренне возмущен, если не сможет открыть в браузере свою почту или погуглить что-нибудь. С другой стороны, и игроман, отдавший почку за видеокарту, захочет посмотреть в браузере 8к-видео, покрутить 3д-модели, ну и может быть даже плавненько поскролить фейсбук-ленту.
Всё это заставляет разработчиков Хромиума буквально разрываться: с одной стороны, они до сих пор поддерживают рисование древними технологиями вроде GDI и DirectX9, чтобы работать на устаревшем оборудовании, но с другой стороны они пилят поддержку последних версий OpenGL, DirectX11 (или уже 12?) и Vulkan — что даёт возможность развернуться по полной современным устройствам (в том числе и мобильным).
Но и это всё было бы ещё полбеды, если бы весь этот зоопарк работал так, как он должен работать согласно спецификации. Чего совершенно не происходит. Реальное железо и его драйвера нарушают всё: маркетинговые обещания покупателям, технические спецификации, общепринятые стандарты, сертификационные тесты, совместимость с ОС, планы по выпуску обновлений и т.д. Но, кроме реального железа и его драйверов у нас ничего другого нет. Поэтому приходится работать на том, что есть. Вот об этом и повествует вышеупомянутый файл gpu_driver_bug_list.json.
Кстати, заслуживает уважение то, насколько браузер пытается «выжить любой ценой». Так, при некритичных проблемах, например, с DirectX11, будут произведены попытки отключать определённые части его функционала, жертвуя производительностью, но сохраняя работоспособность. При более серьёзных багах — DirectX11 будет отключен и браузер перейдёт на DirectX9, где также (при необходимости) будут «отрезаться и выбрасываться» проблемные компоненты. Ну и при полном отказе системы DirectX произойдёт переключение на GDI — что ударит по процессору и потреблению ОЗУ, но всё же удержит производительность для обычных страниц (без тяжелого видео или 3D) на уровне, при котором пользователь, скорее всего, даже не поймёт, что что-то идёт не так. Там, где другие программы уже попросят обновить драйвера или сменить видеокарту — Хромиум просто продолжит работать. Дух захватывает.
Давайте уже посмотрим на содержание упомянутого мною файла. Количество отдельных записей в нём: 215 штук. 215 раз, когда разработчик железа соврал, поленился, был глуп или пожадничал. 215 раз приходилось искать правильную конфигурацию железа и софта для воспроизведения проблемы и находить её решение. Трудно сказать, сколько раз было решено не фиксить проблему — но, поскольку вокруг нас полно людей со старым железом и как-то совсем мало тех, у кого «в Хроме гугл не открывается», можно предположить, что таких случаев было совсем немного.
Следующее интересное наблюдение — распределение по ОС: 89 — android, 44 — macosx, 34 — linux, 26 — win, 8 — chromeos. Выводы отсюда можно делать разные. С одной стороны, очевидно, что андроид — ключевая платформа для Гугла и в исправление багов на нём были угроханы колоссальные средства. С другой стороны, не понятно почему они были угроханы в фиксы в кодовой базе Хромиума, а не драйверов или ОС (ведь у Гугла там достаточно высокий уровень контроля всего на всех этапах). Исправления там принесли бы пользу всему софту на андроиде, а здесь — только Хромиуму. Скорее всего дело во взаимодействии департаментов, когда программисту Хромиума проще исправить проблему у себя в коде здесь и сейчас, чем эскалировать её на 3-4 уровня вверх, потом в сторону, а потом на 3-4 уровня вниз. Людей, которым такое интересно, в любой компании меньше, чем нужно было бы.
Меня сильно удивило, что багов отрисовки в Mac Os было обнаружено почти два раза больше, чем в Windows. Мне казалось, что там всё очень ограничено по железу и вылизано по драйверам. Но вот оказалось, что зоопарк Windows в два раза более живуч и стабилен. Прямо «Собор и базар» в иллюстрациях. Или просто сами разработчики Гугла тестируют код на одних маках?
Интересно и разделение по вендорам: Nvidia — 22, AMD/ATI — 17, Intel — 30. Не думаю, что софт или железо Интела вот прямо хуже — скорее, сказывается массовость продуктов. Каждый, кто не покупает специально «игровой комп», скорее всего покупает что-то с интегрированной интеловской видеокартой. Баг, случающийся у 0.001% юзеров, будет годами жить в видеокарте от NVidia или ATI, но приведёт на форумы и в соцсети кучу разгневанных пользователей в случае с Интелом. «Большая сила влечёт за собой большую ответственность».
Забавно выглядит разделение по багам OpenGL и DirectX: OpenGL — 16, DirectX — 0. Но это не потому, что OpenGL такой плохой, а DirectX такой хороший. Тут дело в том, что все баги категории «win» (вот те 26 штук) это на самом деле баги DirectX (ну ок, не все, но почти все).
Но ладно, хватит тут обвинять всех подряд обобщённо. Давайте уже перейдём на личности, а там и до мордобоя, глядишь, недалеко!
Вот, например, запись 211, ссылающаяся на баг 672380. У людей перестал работать в коде унарный минус и функция арктангенса на некотором железе от Intel и NVidia. Унарный минус, блин, и базовая тригонометрия! Казалось бы, во что дальше верить? А нет, исправили и работает.
Или вот записи о «неправильно отображаемых цветах» вроде №185, 219, 220 и некоторых других. Программист всё сделал верно, все функции отработали и вернули «успех», но вот на экране в результате отображается пиксель не того цвета. Ах да — только вот на этих видеокартах и этих версиях драйверов. Кстати, вопрос поклонникам теории о том, что тестами можно покрыть всё: как бы вы покрыли тестами вот это?
Вот ещё классная штука, №224: «VPx decoding isn't supported well before Windows 10 creators update». Ну то есть вышла операционка, всем раструбила, что у неё есть акселерирование декодирования такого-то видео. Но на практике оказалось, что оно-то есть, но такое, что лучше бы его вообще не было. И лучше его отключить. В результате — разработчик ОС продаёт очередной миллиард платной ОС, а разработчик бесплатного браузера собирает жалобы на то, что видео играет как-то не так плавно, как хотелось бы, хотя, казалось бы, и железо, и ОС должны бы позволять! «Где мои 60 fps и почему ваш браузер съел 4 ГБ ОЗУ» — знакомый разговор, правда?
И сразу её догоняет запись №225: «VPx decoding is too slow on Intel Broadwell, Skylake, and CherryView». Разрабатывали мы, значит, разрабатывали новые поколения процессоров одно за другим, рекламировали, продавали. Но проблемы конечного юзера — это проблемы конечного юзера, кого там они волнуют. Пусть прикладники как-то там костылём подопрут, а мы потом поправим.
Отдельная песня — так называемая «Switchable graphics», которую очень активно втюхивают продавцы в магазинах. Вот, мол, какой хороший ноутбук с двумя видеокартами — в играх будет всё быстро, а в офисных программах (типа браузера) — будет очень энергоэкономно, ННадцать часов от батарейки проработает! А теперь смотрим на горькую правду жизни: на Windows это приведёт к полному отказу от DirectX11 (запись №100), а на маках будет крешится так часто, что мы не-дискретную карту лучше вообще отключим навсегда (запись №228).
Или вот №242: «Code produced by local variable initialization often triggers crashes in Marshmallow Adreno driver». Решение тоже прекрасно: «dont_initialize_uninitialized_locals». Ну вот какие нормальные люди согласились бы что-то писать под платформу, где локальные переменные нельзя инициализировать при объявлении, потому, что от этого драйвер падает? А вот в коде столь массового продукта как Хромиум — приходится жить и с этим.
№26: «Disable use of Direct3D 11 on Windows Vista». DirectX11 был одной из основных фич Vista, я до сих пор помню коробки видеокарт тех времён с гордыми надписями «Windows Vista and DirectX11 compatible». А для многих это была вообще единственная причина перехода с привычной и стабильной XP на новую и страшненькую Vista. Прошли годы — и вот поддержка DirectX11 (продукт Microsoft) в ОС Windows Vista (продукт Microsoft) оценена на уровне «не поддерживается». Прямо признание заслуг!
Ладно, мне надоело выбирать частности, читайте остальное сами — там хорошо описаны и причины багов, и реализованные костыли, плюс ссылки на багтрекер есть (поле «cr_bugs»).
Мораль
Во-первых, все врут. Во-вторых, даже в условиях, когда все врут, всё ещё возможно написать качественное ПО. И в-третьих, в следующий раз, когда кто-то будет вам рассказывать, как современный веб пришел к успеху благодаря «мощи HTML, CSS и прекрасного языка Javascript» — покажите ему эту статью и спросите, как бы оно всё работало и кому бы было нужно без вот этого героического труда невидимых людей в стремлении «взлететь со всей этой фигней».
Автор: tangro
