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

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

Статья как-то и обо всём, и при этом очень поверхностно.

Лучше бы рассказали про "насущные вещи" - про адаптивность и масштабирование, и как на это влияют атрибуты width, height и viewBox.

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

Пару лет назад делал svg анимацию на этом сайте, интересный опыт mienoty.ru В те времена, в хроме до 88 версии, не было GPU ускорения для SVG анимации, приходилось многое упрощать и оптимизировать, но и сейчас не все так гладко как хотелось бы.

Я недавно начал изучать svg и поэтому хотелось бы уточнить. Есть ли какие-то библиотеки, позволяющие рисовать svg линии от руки?

Не уверен, насколько я понял вопрос, но в сети достаточно примеров с рисованием линий. Они сами по себе не очень большие, их библиотеками называть язык не поворачивается. Как пример:

Есть и полноценные SVG-редакторы, если нужно. Тут стоит вопрос уточнить, какие линии и как вы хотите рисовать.

Спасибо за статью.

Кстати, на тему оптимизации SVG. Когда нет под боком редактора, часто выручает SVGOMG, который можно попробовать в виде веб-версии jakearchibald.github.io/svgomg/. Неплохо так чистит. Но и как и в других оптимизаторах, могут "упрощаться" кривые, что в свою очередь может сказаться на анимации.

Что касается самой SVG анимации, то с ней, откровенно говоря, встречал много проблем и то же аппаратное ускорение может не работать (например потому что GPU или драйвер в blacklist) или может работать с багами, особенно если еще и присутствуют тяжелые SVG фильтры.

Что касается сложной анимации, то на слабых системах (в т.ч. старые, но активно используемые Android устройства), с браузерами на основе Chromium при работе с Canvas (и WebGL в частности) вычисления можно выполнять в WebWorkers с отрисовкой в OffscreenCanvas. Это помогает разгрузить основной поток, что благотворно влияет на общую производительность. Это хорошее решение, если очень надо отображать постоянную, сложную, контролируемую анимацию, даже на слабых системах. Хотя конечно и у WebGL тоже багов хватает.

Поэтому для простых анимаций пока отдаю предпочтение CSS и JS через WebAnimation API, ибо это куда стабильнее и более контролируемо.

поправьте "неного шире"

И еще трансформации на SVG-элементах складываются в стек. Можно несколько раз применить к элементу одни и те же трансформации. Подвинуть, повернуть, еще подвинуть, еще повернуть, и.т.д. А потом они применяются в обратном порядке. А CSS так не умеет. Там можно применить только по одной трансформации каждого базового типа к элементу.

Что вам мешает применить к любому DOM элементу, например, вот такую CSS трансформацию:

transform: translate(1px, 10px) translateX(-10px) translateY(-5px) scale(1.5) scaleX(-0.7) scaleY(1.1) rotate(-10deg) skew(5deg, 5deg) skewX(-5deg) skewY(-2deg);

Уточните чего именно не умеет CSS? Применять трансформации в обратном порядке?

Наверное стоило про это более подробно написать. Вы правы в том, что применить трансформацию можно. В теории. А на практике, когда мы ее применим к элементу внутри SVG и начнем его анимировать, все будет не так однозначно. Там будет появляться неопределенное поведение, когда на одном элементе это работает — а на другом нет, в одном браузере все работает — в другом отдельные анимации не работают, и.т.д. В первый раз у меня ушло очень много времени на то, чтобы методом тыка угадать, что после разнесения трансформаций по разным элементам все заработает. Я тогда так и не нашел упоминания в стандартах на тему того, какие там есть исключения. А потом это повторилось. И опять сидел, и не понимал, что с кодом не так. Опыт показывает, что у такого сложения трансформаций на одном элементе нет 100% надежности в анимациях. Там есть какой-то элемент случайности, когда оно может работает, а может — нет. Это в чем-то напоминает другую ситуацию из мира CSS-трансформаций с обычными HTML-элементами, когда трансформированный элемент именно во время анимации обрезается границами родительского элемента. Возможно вы сталкивались. Визуально кажется, что там появляется overflow: hidden у родителя, хотя его там нет, и не должно быть. Это не всегда случается. Но иногда бывает. Такие проблемы сложно воспроизвести на другой странице, это что-то очень ситуативное. И сложно предсказать, когда это случится, по стандартам ничего такого быть не должно. С этими трансформациями тоже речь идет о какой-то такой штуке, которая вроде как должна работать, а не деле — что-то может пойти не так, в зависимости от чего-то, что мы не знаем, и это не настолько очевидно, чтобы сразу сообразить, что сделать, чтобы все починилось.

после разнесения трансформаций по разным элементам все заработает.

пробовали объединять элементы в группу и трансформацию применять ней:

<g transform="...">
  <path ../>
  <rect ../>
  ...
</g>

Так автор говорит про трансформации CSS, а не трансформации SVG

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории