Влияние перекомпоновки/перерисовки SVG/SMIL на производительность?

В прошлом я довольно много работал с javascript, включая некоторые манипуляции с DOM. Оттуда я узнал, что перекомпоновка/перерисовка в некоторых случаях могут быть серьезной проблемой производительности и, как правило, должны быть сведены к минимуму. Например, при добавлении группы div вы должны добавить все сразу (прикрепить их к div за пределами DOM, а затем прикрепить его), а не присоединять их по одному. То же самое касается перерисовки, которую можно вызвать, изменив свойства CSS элемента. Хотя я должен признать, что никогда особо не занимался перекрашиванием, так что я могу ошибаться насчет последней части.

Относится ли это также к SVG (видя, что он использует своего рода DOM, это кажется правдоподобным)? И есть ли разница для разных элементов SVG? Например, было бы разумно, чтобы элемент анимации не создавал перекомпоновку, поскольку это не новый элемент SVG, а скорее свойство.

Что-то, в чем я не уверен, так это перерисовки для SVG, существуют ли они вообще так же, как для CSS/HTML? В конце концов, анимация SMIL уже создает кадры, поэтому такая вещь, как «перерисовка», может не иметь никакого значения, поскольку новый кадр все равно будет отображаться.

Кто-нибудь с более глубоким пониманием внутренней работы SMIL, кто мог бы прояснить эти вещи для меня?


person Wingblade    schedule 08.07.2014    source источник


Ответы (1)


Ваша информация устарела. В наши дни UA объединяют перекомпоновки, поэтому вам больше не нужно присоединять div за пределами DOM.

SVG на самом деле не имеет перекомпоновки, так как в основном все абсолютно позиционировано, поэтому изменение положения одного элемента влияет только на этот элемент и любых его потомков. Изменения SVG DOM просто вызывают перерисовку. Иногда даже перерисовка не требуется, если соответствующие данные находятся в графической памяти, поскольку в наши дни преобразования instand translate часто почти полностью обрабатываются графическим аппаратным рендерером без перерисовки. Анимация SMIL также подключена к этому механизму.

Если содержимое SVG имеет атрибут перевода, оно сохраняется в отдельном слое. Во многих случаях слои можно обновлять без повторного рендеринга, например. перевод, поскольку графическая система может просто рисовать слои там, где им нужно.

Больше документации о том, как это работает в Firefox, можно найти здесь, но другие пользовательские агенты работают аналогичным образом.

person Robert Longson    schedule 08.07.2014
comment
Иногда даже перерисовка не требуется, если соответствующие данные находятся в графической памяти, может ли это по линиям перерисовки не иметь никакого значения, поскольку новый кадр все равно будет отображаться? И означает ли часть о переводах, что буквально нет разницы (перерисовка/производительность) между изменением перевода, контролируемым JS, и, скажем, изменением, сделанным тегом SVG ‹animate›? - person Wingblade; 08.07.2014
comment
Также: есть ли какое-либо правило, по которому данные SVG попадают в графическую память? - person Wingblade; 08.07.2014
comment
SMIL можно дополнительно оптимизировать, поскольку UA знает, что произойдет. Иногда это может сделать его быстрее, но это слишком широко, чтобы подробно ответить здесь. Данные SVG всегда попадают в графическую память, важно, можете ли вы при их изменении собрать новый макет, например. для перевода вам нужно иметь фон и переводимую вещь в отдельных буферах. - person Robert Longson; 08.07.2014
comment
SMIL можно дополнительно оптимизировать, поскольку UA знает, что произойдет. Именно то, что я думал. В общем, SMIL кажется более естественным для UA, чем, скажем, тайм-аут или requestAnimationFrame, который изменяет свойства элемента. Спасибо за ваши ответы, они были очень полезны. - person Wingblade; 08.07.2014
comment
Всем, кто читает это: Эта статья также может оказаться полезной. - person Wingblade; 09.07.2014