Как стать автором
Обновить

Комментарии 48

А почему в Яндекс картах не используется SVG?
Браузер сам отлично справляется с прорисовкой/парсингом/обработкой контуров (возможно даже рисуется с аппаратным ускорением).
SVG лучше подходит для печати с высоким DPI, чем растровые картинки сейчас.
Не знаю за Яндекс, отвечу за свой опыт. SVG только в теории красиво, на практике же оборачивается адовой потерей производительности браузеров по итогу жуткими тормозами.
Вот это как раз было наиболее интересно — сравнение производительности.
Раньше SVG никак не использовал GPU, поэтому WebGL был в явном выигрыше, но возможно сейчас ситуация изменилась в лучшую сторону.
Кроме того — у Яндекса есть свой браузер, на котором можно «оптимизировать» SVG для своих-же карт :)
возможно сейчас ситуация изменилась в лучшую сторону
У FF ситуация изменилась так, что вообще всё рендерится на GPU в Webrender, ЕМНИП.
> у Яндекса есть свой браузер, на котором можно «оптимизировать» SVG
Для этого им придется делать полноценный форк хромиума и уже в нём переписывать отрисовку SVG, что, наверное, очень непростое решение, так как потом этот форк нужно будет самим поддерживать и развивать, а не просто обновять хромиум. Да и если ни у кого среди браузерных движков не получается реализовать быструю поддержку SVG, то может это в принципе невозможно, используя спецификацию SVG.
форк хромиума

Хромиум это же интерфейс, и форк как раз хромиума у них есть. А с SVG — есть подозрение что потребовался бы форк уже Blink'а, а это уже заметно сложнее, учитывая что даже МС с их ресурсами отказалась от собственных движков.
Хромиум это не только интерфейс. Он включает в себя интерфейс, движок Blink, и JS-движок V8.
В любом случае — протолкнуть что-то, особенно такое крупное как изменения работы с SVG в движок браузера на порядок сложнее, чем небольшие багфиксы или улучшения не идущие вразрез с гугловским видением будущего проекта Chromium.
За графику в хромиуме отвечает библиотека Skia. И в FF кстати кажется тоже она. Библиотека сложная и небезглючная. Подозреваю, что форкать её — смерти подобно.
Я как-то репортил в хромиум баг, как раз-таки связанный с SVG — мне ответили, что в настоящий момент исправить его не представляется возможным, потому что это Skia, и там слишком всё сложно и слишком на многое завязано.

У них и так форк.
И они и так наделали уже много таких решений, которые не принимают (и врядли вообще когда-нибудь примут). Об этом говорилось тут на конференции яндекса: https://youtu.be/iWPu3Crpys0?t=1836

Кому лень смотреть видео: толстые фичи (гибернейт, тайлы) гугл не принимает, багфиксы принимают на ура, фичу с выделением ссылок через Alt таки удалось протолкнуть.

Ааа, оно существует! Выделение ссылок! Спасибо, добрый человек, а то я мучаюсь!

Если у них форк, зачем им нужно подтверждение гугла, чтобы принять какую-то фичу?

По-моему, очевидно, что яндекс не хочет все новые фичи и стандарты css/html/js внедрять сам, когда это может сделать гугл. При этом, чем больше яндекс сделает вещей, которые гугл не примет, тем сложнее яндексу будет принять себе новый код, который написал гугл.
Об этом тоже говорилось в докладе: они мержат себе изменения из хромиума без остановки — как только закончился один цикл, сразу начинается следующий

Об этом я как раз и говорил в моем первом сообщении:
> Для этого им придется делать полноценный форк хромиума и уже в нём переписывать отрисовку SVG, что, наверное, очень непростое решение, так как потом этот форк нужно будет самим поддерживать и развивать

А сейчас у них форк или он не "полноценный"? Или они не поддерживают и не развивают свой форк? Они как минимум для хибенейта сделали столько изменений в ядре, что их никогда не примут и им придётся с этим жить уже всегда.
SVG — просто ещё одно такое изменение, которое не понятно, окупится ли.

Если они постоянно мержат оригинальный Хромиум назад к себе, то не «полноценный», я в этом смысле имел в виду. А чтобы переписать SVG, им нужно будет переписать очень много всего в оригинальном и вряд ли уже потом полноценный мерж будет возможен.
> SVG — просто ещё одно такое изменение, которое не понятно, окупится ли.
Согласен.
Полноценный форк — это, например, когда появился WebKit на основе KHTML, или Blink как форк WebKit. Т.е. когда они в результате пошли своим путем.

Звучит как "настоящий мужчина — это"
Не надо придумывать свою терминологию. Яндекс браузер — это форк хромиума. То, что он (пока?) может обновляться вместе с изменениями в хромиуме, не делает его "не форком" или менее "полноценным".

Я не придумывал свою терминологию, а выразил мысль. То, что вам это не понравилось, это, похоже, только ваше дело.
Ответвлённый проект или форк может поддерживать и обмениваться частью содержимого с основным проектом, а может и приобрести абсолютно другие свойства, перестав иметь с базовым проектом что-то общее.

Дальнейшее развитие может происходить разными путями: сосуществование и активный обмен общим (разделяемым) кодом, независимое существование, независимое существование с полной потерей общих свойств, «миграция» разработчиков из исходной ветки в другую, адаптация проекта к новым технологиям или слияние ответвлений в единый проект.

Из вики. Так что то, что яндекс забирает обновления и при этом пытается свои изменения протолкнуть в основной проект — не делают его не форком. Так же кстати и другие крупные разработчики браузеров поступают — Opera, Vivaldi, Microsoft.
Поэтому я и попытался как-то отделить исходное значение слова «форк», которое описывает сразу несколько сценариев, от того, которое я имел в виду, и написал «полноценный форк», предполагая эту часть определения из вики:
а может и приобрести абсолютно другие свойства, перестав иметь с базовым проектом что-то общее

В моем представлении, написать собственную обработку SVG — это настолько сложная задача, затрагивающая столько различных частей основного проекта, которая потом не позволит принимать большую часть обновлений с основного проекта.

svg на самом деле очень упоротый формат, в который кажется думали по началу весь флеш затолкать, но потом не осилили. В итоге он очень сложный и не дружит с оптимизаторами.

Полная спецификация довольно сложна для оптимизации, но для некоторого подмножества SVG, например без кривых она возможна, статья тут яркий пример кстати.
Было бы очень круто, будь SVG таким быстрым. В картах динамические (и не очень) объекты на картах сделаны через SVG: маршруты, линейка, полигоны (когда ищете Москву, например). Так вот, браузер довольно плохо справляется с прорисовкой/парсингом/обработкой контуров и на объемах данных подложки будет выдавать 1-2 фпс в лучшем случае.

Попробуйте найти хотя бы один карточный движок, который использует SVG для подложки. Их нет. Все рисуют или дом-тайлами, или в canvas 2d, или в webgl.
И это проблема, поскольку сами производители браузеров не горят желанием оптимизировать SVG, переписав его на какой-нибудь Vulkan ввиду того, что производительность в SVG не критична — карточные движки же его не используют :)

Было бы очень круто, если бы Яндекс-картам не приходилось писать свой векторный движок на JavaScript/WebAssembly + WebGL, а браузер нормально работал с вектором из коробки. Но «обход» этой проблемы никак не приближает её решение.
SVG парсится в DOM, со всем вытекающим из этого оверхедом. С одной стороны, у SVG-элементов имеется доступ к CSS и DOM API, что, безусловно, удобно. К тому-же отрисовка SVG, во многих случаях, обходится браузеру гораздо дешевле, чем отрисовка обычных DOM-элементов: каждый элемент рисуется независимо, без сложных комбинаторных вычислений. С другой стороны, Canvas — гораздо быстрее, потому что не создает вообще никакой сложной объектной модели.
Но объектная модель, необходимая для карт от этого никуда не пропадает, просто ей занимаются в JavaScript, отвязавшись от DOM, по сути дублируя часть функций.
DOM избыточен и сам по себе медленный. В JS нужно наоборот минимизировать взаимодействие с ним.

И все таки, почему именно плюсы, а не раст, у которого более развитая экосистема для wasm?

Внутри Яндекса плюсы сильно более распространены, чем Rust, поэтому так. Проще было найти коллег, которые могли поревьюить код

Вполне коррелирует с нашим опытом — приходилось писать компилятор в wasm из некоего typescript-подобного языка, в итоге выигрыша в производительности получить не удалось — на маленьких проектах многое съедает интероп, на больших управление памятью в javascript оказывается на порядок лучше того, что "на коленке" можно сделать в wasm. Есть пропоузалы для решения этой проблемы, но вроде пока никто не реализовал. И плюс сама wasm-машина очень слабо оптимизирована, как кажется.

не смотрели на assemblyscript?
НЛО прилетело и опубликовало эту надпись здесь
Да, верно, можно было, мы даже немного посмотрели, но проблема в том, что TS (произносится как JS) — это другая среда, там есть свои примочки (например асинхронщина или генераторы), которые не сразу понятно как будут выражены в wasm, а с ним мы экспериментировали в первую очередь из-за производительности, там нужен полный контроль. Да и в момент когда мы начинали первые эксперименты (года 1.5 назад) он показался сыроватым.
Что касается размера, то мы, конечно, постарались в этом месте пооптимизировать, поотключать ненужное, но, опять же, среда там другая, понятия стандартной библиотеки или подобного там нет. И елси, например, мы используем где-то функцию sort(), то это значит что ее код попадет в модуль. В теории можно было бы, наверное, «сходить в js», но непонятно чего это будет стоить в рантайме из-за передачи данных и смены контекста.
Забавно. Заголовок по сути говорит «wasm нам не понравился», а в статье его нахваливают.

В наших картах сейчас работает обычный JavaScript. Это связано с тем, что выигрыш в парсинге не так велик на общем фоне, и с тем, что в Wasm’е реализован парсинг только некоторых типов примитивов.

То есть, получается, что причины скорее внутренние — «когда мы реализуем в „Wasm“ больше из того что нам нужно, то вернёмся к этому вопросу».
Ещё ожидал увидеть то что вы пробовали отключить ключами Emscripten часть неиспользуемых вещей — например, RTTI или виртуальную файловую систему — это помогло бы уменьшить размер wasm-файла.
Похоже, что WebAssembly — очередной хайповый оверхед, который так любят байтофилы. Затраты на скорость разработки и штат разработчиков на WebAssembly не покроют ничтожный выигрыш в производительности.

Судя по статье, выигрыш в разы. Разве что не в десять раз, а всего-то в два. А то, что они переписали только небольшую часть, поэтому на общем фоне эти два раза не очень заметны, разве в этом есть вина wasm?


А скорость разработки на rust не настолько ниже, чем на JavaScript, а иногда может быть и выше. В выборе с++ в данном случае wasm тоже как бы не виноват.

По-моему, вышла слишком большая разница. Скорее всего, код на JS был изначально написан неоптимально. Или это за счёт использования AVX?
НЛО прилетело и опубликовало эту надпись здесь
почему нет, начать можно отсюда yandex.ru/jobs
НЛО прилетело и опубликовало эту надпись здесь
Интересно, не рассматривали ли Rust как альтернативу C++? У него там вроде все очень хорошо с WASM, любопытно было бы узнать мотивацию.
К сожалению, отлаживать Wasm-код построчно в браузере нельзя

image
Ну вот не очень удобно получается, переменные например странные, инструментарий все же не совсем готов (по крайней мере в сравнении с другими развитыми технологиями, где сборка и вся разработка в два клика настраивается)
Как в статье написано, делали так: плюсовый код запускался через тесты в нативной среде, где и дебаггеры крутые и по скорости приемлемо, а уже на финальном этапе тестировался в браузере. Сюрпризов не случалось, если что-то разному работало, то в итоге находилась и сама разница и (часто, чего уж греха таить) человеческий косяк.
Я правильно понял, что:
1. Не внедрили, поскольку переписали на нём мало кода и прирост производительности вышел не большой.
2. Больше кода не переписывали, поскольку не внедрили.

?
Не совсем так
У нас получилось подтянуть средствами js производительность до нужного нам качества (параллельно копали во всех направлениях, кто-то делал эксперименты с WASM, кто-то оптимизировал то что есть).
Сейчас основные проблемы сервиса в другом и в моменте нам кажется разумным переключиться на продуктовые задачи
Если когда-то мы снова упремся в производительность, то с большой вероятностью воспользуемся изученным способом получать выигрыш в перфомансе
Сейчас это просто не очень болит, а цена решения высокая

Грубо говоря — проверили все грабли, васм норм, если понадобится добыть еще 20% к производительности — вот готовый способ
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.