Comments 49
Браузер сам отлично справляется с прорисовкой/парсингом/обработкой контуров (возможно даже рисуется с аппаратным ускорением).
SVG лучше подходит для печати с высоким DPI, чем растровые картинки сейчас.
Раньше SVG никак не использовал GPU, поэтому WebGL был в явном выигрыше, но возможно сейчас ситуация изменилась в лучшую сторону.
Кроме того — у Яндекса есть свой браузер, на котором можно «оптимизировать» SVG для своих-же карт :)
возможно сейчас ситуация изменилась в лучшую сторонуУ FF ситуация изменилась так, что вообще всё рендерится на GPU в Webrender, ЕМНИП.
Для этого им придется делать полноценный форк хромиума и уже в нём переписывать отрисовку SVG, что, наверное, очень непростое решение, так как потом этот форк нужно будет самим поддерживать и развивать, а не просто обновять хромиум. Да и если ни у кого среди браузерных движков не получается реализовать быструю поддержку SVG, то может это в принципе невозможно, используя спецификацию SVG.
форк хромиума
Хромиум это же интерфейс, и форк как раз хромиума у них есть. А с SVG — есть подозрение что потребовался бы форк уже Blink'а, а это уже заметно сложнее, учитывая что даже МС с их ресурсами отказалась от собственных движков.
Я как-то репортил в хромиум баг, как раз-таки связанный с SVG — мне ответили, что в настоящий момент исправить его не представляется возможным, потому что это Skia, и там слишком всё сложно и слишком на многое завязано.
У них и так форк.
И они и так наделали уже много таких решений, которые не принимают (и врядли вообще когда-нибудь примут). Об этом говорилось тут на конференции яндекса: https://youtu.be/iWPu3Crpys0?t=1836
Кому лень смотреть видео: толстые фичи (гибернейт, тайлы) гугл не принимает, багфиксы принимают на ура, фичу с выделением ссылок через Alt таки удалось протолкнуть.
По-моему, очевидно, что яндекс не хочет все новые фичи и стандарты css/html/js внедрять сам, когда это может сделать гугл. При этом, чем больше яндекс сделает вещей, которые гугл не примет, тем сложнее яндексу будет принять себе новый код, который написал гугл.
Об этом тоже говорилось в докладе: они мержат себе изменения из хромиума без остановки — как только закончился один цикл, сразу начинается следующий
> Для этого им придется делать полноценный форк хромиума и уже в нём переписывать отрисовку SVG, что, наверное, очень непростое решение, так как потом этот форк нужно будет самим поддерживать и развивать
А сейчас у них форк или он не "полноценный"? Или они не поддерживают и не развивают свой форк? Они как минимум для хибенейта сделали столько изменений в ядре, что их никогда не примут и им придётся с этим жить уже всегда.
SVG — просто ещё одно такое изменение, которое не понятно, окупится ли.
> SVG — просто ещё одно такое изменение, которое не понятно, окупится ли.
Согласен.
Звучит как "настоящий мужчина — это"
Не надо придумывать свою терминологию. Яндекс браузер — это форк хромиума. То, что он (пока?) может обновляться вместе с изменениями в хромиуме, не делает его "не форком" или менее "полноценным".
Ответвлённый проект или форк может поддерживать и обмениваться частью содержимого с основным проектом, а может и приобрести абсолютно другие свойства, перестав иметь с базовым проектом что-то общее.
Дальнейшее развитие может происходить разными путями: сосуществование и активный обмен общим (разделяемым) кодом, независимое существование, независимое существование с полной потерей общих свойств, «миграция» разработчиков из исходной ветки в другую, адаптация проекта к новым технологиям или слияние ответвлений в единый проект.
Из вики. Так что то, что яндекс забирает обновления и при этом пытается свои изменения протолкнуть в основной проект — не делают его не форком. Так же кстати и другие крупные разработчики браузеров поступают — Opera, Vivaldi, Microsoft.
а может и приобрести абсолютно другие свойства, перестав иметь с базовым проектом что-то общее
В моем представлении, написать собственную обработку SVG — это настолько сложная задача, затрагивающая столько различных частей основного проекта, которая потом не позволит принимать большую часть обновлений с основного проекта.
svg на самом деле очень упоротый формат, в который кажется думали по началу весь флеш затолкать, но потом не осилили. В итоге он очень сложный и не дружит с оптимизаторами.
Попробуйте найти хотя бы один карточный движок, который использует SVG для подложки. Их нет. Все рисуют или дом-тайлами, или в canvas 2d, или в webgl.
Было бы очень круто, если бы Яндекс-картам не приходилось писать свой векторный движок на JavaScript/WebAssembly + WebGL, а браузер нормально работал с вектором из коробки. Но «обход» этой проблемы никак не приближает её решение.
И все таки, почему именно плюсы, а не раст, у которого более развитая экосистема для wasm?
Вполне коррелирует с нашим опытом — приходилось писать компилятор в wasm из некоего typescript-подобного языка, в итоге выигрыша в производительности получить не удалось — на маленьких проектах многое съедает интероп, на больших управление памятью в javascript оказывается на порядок лучше того, что "на коленке" можно сделать в wasm. Есть пропоузалы для решения этой проблемы, но вроде пока никто не реализовал. И плюс сама wasm-машина очень слабо оптимизирована, как кажется.
Что касается размера, то мы, конечно, постарались в этом месте пооптимизировать, поотключать ненужное, но, опять же, среда там другая, понятия стандартной библиотеки или подобного там нет. И елси, например, мы используем где-то функцию sort(), то это значит что ее код попадет в модуль. В теории можно было бы, наверное, «сходить в js», но непонятно чего это будет стоить в рантайме из-за передачи данных и смены контекста.
В наших картах сейчас работает обычный JavaScript. Это связано с тем, что выигрыш в парсинге не так велик на общем фоне, и с тем, что в Wasm’е реализован парсинг только некоторых типов примитивов.
То есть, получается, что причины скорее внутренние — «когда мы реализуем в „Wasm“ больше из того что нам нужно, то вернёмся к этому вопросу».
Ещё ожидал увидеть то что вы пробовали отключить ключами Emscripten часть неиспользуемых вещей — например, RTTI или виртуальную файловую систему — это помогло бы уменьшить размер wasm-файла.
Судя по статье, выигрыш в разы. Разве что не в десять раз, а всего-то в два. А то, что они переписали только небольшую часть, поэтому на общем фоне эти два раза не очень заметны, разве в этом есть вина wasm?
А скорость разработки на rust не настолько ниже, чем на JavaScript, а иногда может быть и выше. В выборе с++ в данном случае wasm тоже как бы не виноват.
К сожалению, отлаживать Wasm-код построчно в браузере нельзя
Как в статье написано, делали так: плюсовый код запускался через тесты в нативной среде, где и дебаггеры крутые и по скорости приемлемо, а уже на финальном этапе тестировался в браузере. Сюрпризов не случалось, если что-то разному работало, то в итоге находилась и сама разница и (часто, чего уж греха таить) человеческий косяк.
1. Не внедрили, поскольку переписали на нём мало кода и прирост производительности вышел не большой.
2. Больше кода не переписывали, поскольку не внедрили.
?
У нас получилось подтянуть средствами js производительность до нужного нам качества (параллельно копали во всех направлениях, кто-то делал эксперименты с WASM, кто-то оптимизировал то что есть).
Сейчас основные проблемы сервиса в другом и в моменте нам кажется разумным переключиться на продуктовые задачи
Если когда-то мы снова упремся в производительность, то с большой вероятностью воспользуемся изученным способом получать выигрыш в перфомансе
Сейчас это просто не очень болит, а цена решения высокая
Грубо говоря — проверили все грабли, васм норм, если понадобится добыть еще 20% к производительности — вот готовый способ
Не могли бы вы уточнить, какую конкретно задачу вы хотели ускорить с помощью WebAssembly? Из статьи я понял, что у вас две проблемы: декодер протобуф и вычисления. С вычислениями всё понятно — векторная алгебра на плюсах работает значительно быстрее, но вот с декодером протобуф есть сомнения. В итоге, результат в статье соответствует "средней температуре по больнице" — и хороший инструмент был выкинут.
По поводу большого размера. А вам действительно нужно всё то, что тянет за собой emscripten? Может в вашем случае достаточно сборки непосредственно с помощью CLang? Например так clang++ test.cpp -ObjC++ --compile --target=wasm32-unknown-unknown-wasm --optimize=3 --output test.wasm
Как мы внедряли WebAssembly в Яндекс.Картах и почему оставили JavaScript