Некоторые вопросы оптимизации RIA HTML приложений для Chrome

Question

[Burantino]

Хочу поделиться наблюдениями с одной стороны и узрить корень с другой:

1) Chrome 2x. Анимация(css3 transforms and animations, масштабирование+смещение+прозрачность) большого кол-ва (~10-20) крупных(~700x500) картинок в chrome работает совершенно по-разному(скорость) в случае когда
а) Картинки=div+background-image
б) Старый добрый [img]

Картинки([img]) работают плавно и хорошо. Дивы тупят и лагают довольно приличное время. После нескольких (4-5) итнераций проигрывания анимации, дивы тоже начинают работать более менее плавно. Вопрос: в чём суть сего явления? По таймлайну хром показывает что большую часть времени, в первом случае, занимается Image rescale.

2) Chrome 2x. Есть система дивов залэйаученых с помощью css3 flex. Анимируется содержимое одного из таких дивов (анимируются дочерние дивы). Анимация выдаёт очень низкий fps. Если залэйаутить руками(position: absolute) или c помощью float, то fps существенно (на порйдок) выше. По таймлайну видно, что в первом случае paint работает на всю область окна, а во втором как-то хитро оптимизированно, только там где что-то меняется.
Вопрос: это текущая имплементация flex'а в хроме такая корявая или есть глобальные предпосылки для неиспользования флексованных контейнеров для анимированного содержимого.

Если кто-то
-смог дочитать до этого места
-понял о чём вопросы
-знает ответы
WELCOME!!!

Answer 1

[Валерий Селицкий]

На ответы не претендую, выскажу свои скромные теоретические мысли по поводу.

1) Ну это вполне ожидаемо, что нативный img будет быстрее перерисовки фона у блока. В случае а сама картинка и является блоком, в случае б блоком является див, которому при анимации в каждой итерации применяется новый CSS с позициями и т.п., что вызывает перерендеривание элемента и, видимо, фона в том числе, т.к. фон является CSS свойством… На лицо недооптимизированность хрома в этом моменте, но я думаю у девелоперов есть причины на это.

2) Совсем теоретическое мнение:
Судя по всему область отрисовки каким то образом определяется всеми предками по flow, в случае position:absolute мы родителя вырываем из контекста документа, что дает браузеру возможность не париться о предках. Но позиционируя элемент абсолютно мы тут же теряем весь смысл flex лэйаута.

Answer 2

[Burantino]

1) Наверное, хотя приницпиальной разницы не вижу к чему применять цсс к картинке или к диву. Доступны все теже операции. Могу предположить только, что в случае дива исходная картинка откладывается в «дальний» ящик, тогда как в случае имаджа — нет. Соотвественно каждый раз при изменении рамзера дива\имаджа браузер должен рескейлить не то, что на экране, а исходную картинку и тут вот как раз могла собака порыться.
Кроме того в вопросе дивы vs имадж я когда-то положился на Яндекс, в Яндекс-картах все тайлы были сделаны дивами. Сейчас, к сожалению пруф линк дать уже не могу(сейчас у них там ваще канвас). Но было такое и не так давно — менее полугода назад.