SVG, Iconfonts vs PNG

[radist2s]

А что доказывать ущербность того, что не ущербно? И если уж говорить об ущербности, то я вот всегда пасую перед иконками в шрифтах, так как не уверен в них никогда на 100%.
В последнем проекте ради эксперимента я использовал иконки и в svg, и в png(в svg некоторые иконки весили более 30 — 40кб). Но вместе c растром я всегда храню и вектор, чтобы в случае необходимости я мог заменить одно на другое. Если вдруг станет необходимо поддерживать устройства, которые с svg не дружат — то запускаем любой рендерер svg(imagemagick, batik, phantomjs, etc), и конвертируем как угодно.
Кстати, самый простой способ отсеять браузеры, которые svg не поддерживают точно, и наверняка не имеют ретина-дисплей — это хитрое задание бекграунда:

background: url(image.png);
background: url(image.svg) center / auto auto;
/* auto auto - это background-size, старые версии браузеров хоть и знают про background-size, но background в такой записи проигнорируют, и отображаться будет image.png */

[k3nny]

в svg некоторые иконки весили более 30 — 40кб

Это что-то за гранью добра и зла уже. You do it wrong.

Можно конечно быть не уверенным в шрифтах, например, но это не дает право рассуждать о них в категориях «ущербности». Тут скорее

я вот всегда пасую перед иконками в шрифтах, так как не уверен в них никогда на 100%.

В статье об этом и речь в общем.

[BaNru]

Кстати, больше года назад я на эту тему писал статью «Кроссбраузерный SVG логотип» (http://blog.g63.ru/?p=1738), рекомендую ознакомиться. Разумеется, прием описанный в статье, можно использоваться не только для логотипа.

[Alexufo]

Переход на svg иконки практически исключает дизайнеров в будущем рисовать полноцвет в растре, ведь обратно уже никто не будет нарезать под каждый дисплейчик ничего. То есть растр будет умирать в вебе из за невозможности поддержки кучи устройств. Будет вектор с кучей фильтров и градиентов, пытающихся заменить то что так просто рисовать в растре -тени.
Че за херня, яндекс, давай сведи все в один шейп)
img.yandex.net/i/wiz6.png
img.yandex.net/i/wiz1.png
А он и рисует уже кстати в svg давно.
Еще вопрос не понятен на счет размера спрайта с svg иконками. Gzip спасает?

Да и иконка pinterest для теста совсем не подошла, разницы я не вижу. Вижу что она есть у обоих, но кто лучше… не скажу.

[k3nny]

Ну, допустим вот эти 2 иконки все равно вероятно были векторными в процессе создания. Чем проще рисовать в растре тени — я понятия не имею. Это градиент. SVG поддерживает градиенты. Все. По части оптимальности конечно да, есть вопросы. Но ситуация сегодня такова, что даже такой вектор нормально отрисуется и FPS почти не просядет. Тем не менее тут растр будет удобнее. Зачем за уши притягивать вектор сюда? Подождем когда ребята из гугла наконец вернут назад SVG кэш. Вот тогда можно будет говорить о том, чтобы выбрасывать растр вообще.
А что с размером? Для png спрайта спасает?

Ну про иконку pinterest мне сказать нечего, если не видно разницы на 15-м и 16-м кеглях.

[k3nny]

Ха, спасибо! Тут я тупанул, да. На самом деле ничего сам не рисую. Думал что там есть какие-нибудь градиенты по контуру. Погуглил, можно как-то с Blend извращаться, но все равно костыль как надо.

[Alexufo]

Такие тени рисовать можно через gradient mesh, но этой вещи нет в SVG а что касается ее производительности могу только догадываться.

[Alexufo]

Ну вот нарисуйте первую от яндекса с облачком. Вектор вектору рознь, в илюстраторе нариcуете (там есть градиентная сетка), а в SVG — нет.
А главное, не забудьте сравнить размер выходного файла, не будет ли он весить раз в 10 больше при такой детализации.
Вектор изначально был разработан для полиграфии, а потом он все развивался и развивался и главная его пролема — что достигая детализацию растра он становиться все более медленным. Вектор изначально ущербен в плане худ. возможностей. Он значительно требователен к себе.

[csmile]

По опыту моей имплементации SVG в Sciter…

В Sciter:
1. <img src="something.svg"> продуцирует DOM элемент у которого картинка есть фактически [cached] bitmap который получается путем «проигрывания» SVG на bitmap surface. Такой bitmap живет в GPU (как текстура) Последующие paint команды это сугубо rendering той bitmap на уровне GPU — крайне эффектвно. При изменении размеров img элемента «проигрывание» SVG осуществляется по новой. Растеризация в этом случае делается CPU — может быть затратно ибо CPU он один на всех.

2. Inline SVG вида <svg>... svg DOM elements... </svg> всегда транслируется в живое DOM под-дерево host документа. DOM access методы позволяют модифицировать содержимое такого svg island стандартным образом. CSS правила описанные в host html document позволяют стилировать в том числе элементы внутри такого <svg>. Rendering inline svg не использует caching — SVG dom элементы рисуются покомпонентно в процессе исполнения paint ( WM_PAINT на Windows, NSView.drawRect на Mac ). На Windows используется Direct2D поэтому примитивы транслируются в DirectX/GPU команды (не все, но в основном).

Мое личное мнение по поводу SVG:

Я бы ввёл метрики:
source byte / bandwidth — per pixel — сколько байт исходного SVG текста требуется на один пиксель изображения. Скажем вот для этого примера:

16kb source рендерится в 48*48 RGBA bitmap (9kb) — ratio = 1.7. Чем больше [единицы] это оношение тем SVG хуже если сравнивать с PNG у которого это ratio практически всегда меньше 1. bandwidth — per pixel это кстати не только про bandwidth, но также и про CPU-per-pixel и RAM-per-pixel.

Чем проще SVG и чем больше прямоугольник куда этот SVG выводится тем выгоднее его использование. Для небольших (по размерам) икон SVG не выгоден.

Собственно поэтомуя в Sciter наравне с SVG и сделал поддержку @image-map (a.k.a. CSS sprites с человеческим лицом) и expandable images — эффективность bitmaps с возможностью рендеринга на разные DPI.

Примеры из Sciter SDK: /samples/svg/, samples/css++/backgrounds++.htm и samples/image-map/

[k3nny]

1. <img src="something.svg"> продуцирует...

Да, все так и работает в Firefox, например. Да сколько там графики будет на среднюю страницу не контентной? Ну может быть в конце получится bitmap в метров 10. В GPU памяти хранить конечно вообще win. Но даже если решили сэкономить ее, ну можно в простую этот кэш бросить.
Вот расскажите, как человек, который имплементил это. Насколько критично дела с памятью обстоят в таких случаях?

[csmile]

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

На high-dpi дисплеях (300 dpi) вектор (SVG) в принципе может быть выгоден даже на иконах. Угловые размеры икон в принципе одинаковые на любом мониторе, т.е. количество пикселей ими занимаемое становится больше в 9 раз — (300dpi/96dpi)²

[7313]

А вот интересно кто-нибудь всерьез тестировал на совместимость расширенный юникод в котором 32 чемодана символов? )
например
☯ ☭ ☣ ☀ ⚽ ⏰ ✔ ✠ ✌ ☕

[Alexufo]

И че с этими наскальными рисунками делать?)

[Alexufo]

Еще такая штука developer.mozilla.org/en-US/docs/Web/CSS/image-rendering

image-rendering:-moz-crisp-edges; 
image-rendering: -o-crisp-edges; 
image-rendering:-webkit-optimize-contrast;
-ms-interpolation-mode:nearest-neighbor;

Позволит убрать интерполяцию при увеличении на ретине, к примеру. Может быть растр простых иконок без бикубической интерполяции будет смотреться не так как «мыло»)

[k3nny]

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

[BaNru]

Для SVG есть подобное сглаживание
developer.mozilla.org/ru/docs/Web/SVG/Attribute/shape-rendering
Оно позволяет увеличить производительность или качество отрисовки в ущерб скорости.

[pepelsbey]

По части вещей вроде SVGO — я отношусь к ним довольно скептически

SVGO не только убирает лишние пробелы и строки, но и оптимизирует фигуры. Например, вот два пересекающихся квадрата, экспорт из Скетча:

Было
<rect x="0" y="48" width="110" height="110"></rect>
<rect x="48" y="0" width="110" height="110"></rect>

Стало
<path d="M0 48h110v110h-110zM48 0h110v110h-110z"/>

Если почитать содержимое d="…" в «Стало», то там, по сути, то же самое, но такой формат записи кажется оптимальнее для машины, плюс одна нода вместо двух.

[k3nny]

Ну я видел лист с фичами, да.

Еще для этих целей можно использовать SVGO. Кажется объединение в общий shape — это единственная его часть, которая действительно драматически влияет на производительность.

Он там атрибуты какие-то и мета-инфу удаляет и вообще больше про парсинг. Еще правда близкие к целым координаты округляет — хорошая штука.

[Louter]

Сжатие должно творить чудеса, но вот вопрос: шрифтовые иконки: стоит ли игра свеч?
Вектор уже есть, сконвертить в SVG обычно тривиально, а вот получить качественный шрифт в GNU может быть проблематично, мы обязательно теряем цвета, всегда встаёт вопрос браузеров (особенно в РФ, где самые дорогие сайты требуют 8-ого ослика), ресайз немного не очевиден. А каковы плюсы?

[k3nny]

Зато перед нами открывается куча возможностей начиная от банальной смены цвета и размера, заканчивая пачкой CSS манипуляций с шрифтами, вроде тенюшек и т.д.

[Sadler]

Это не преимущество шрифтовых иконок, CSS можно применять и к SVG.

[k3nny]

Ну, строго говоря — нет. Т.е. если в DOM ее положить, то да, можно использовать специфичный CSS этот. Мы ведь не о таком варианте говорим, надеюсь? Но если подключать спрайт, допустим, через background-image — ничего там не изменишь уже.

[LeonidFrolov]

Кажется, самый удобный и оптимальный вариант использовать именно в DOM внешний SVG-спрайт с помощью: d.froloff.me/B0Gv (не дают вставить код).
Можно и к шейпам такой иконки потом обращаться. Единственный минус — тень нормально не отбросить, кажется.

[k3nny]

удалено

[rrd]

Спасибо, что продолжил поднятую мной тему! Добавил ссылку в пост.