Some issues of optimizing RIA HTML applications for Chrome

Question

Google Chrome

I want to share my observations on the one hand and see the root on the other:

1) Chrome 2x. Animation (css3 transforms and animations, scaling + offset + transparency) of a large number (~ 10-20) large (~ 700x500) images in chrome works completely differently (speed) in the case when
a) Pictures = div + background- image
b) Good old [img]

Images([img]) work smoothly and well. Divas are dumb and lag for a pretty decent amount of time. After several (4-5) iterations of playing the animation, the divs also start to work more or less smoothly. Question: what is the essence of this phenomenon? According to the timeline, chrome shows that most of the time, in the first case, Image rescale is involved.

2) Chrome 2x. There is a system of divs called scientists using css3 flex. The content of one of these divs is animated (child divs are animated). The animation produces very low fps. If you lay it out manually (position: absolute) or using float, then the fps is significantly (by an order of magnitude) higher. It can be seen from the timeline that in the first case paint works on the entire area of ​​the window, and in the second it is somehow cunningly optimized, only where something changes.
Question: is the current implementation of flex in chrome so clumsy or is there a global prerequisite for not using flex containers for animated content.

If someone -
could read up to this point
- understood what the questions are about - knows the
answers
WELCOME !!!

Answer 1

I do not pretend to answer, I will express my modest theoretical thoughts about it.
1) Well, it is quite expected that the native img will be faster than redrawing the background of the block. In the case а, the picture itself is a block, in the case, бthe block is a div, to which, during animation, in each iteration, new CSS with positions, etc. is applied, which causes the element to be re-rendered and, apparently, the background, as well, the background is a CSS property... It looks like chrome is underoptimized at this point, but I think the developers have a reason for this.
2) A very theoretical opinion:
Apparently, the drawing area is somehow determined by all the ancestors of the flow, in the caseposition:absolutewe take the parent out of the context of the document, which gives the browser the opportunity not to worry about the ancestors. But by positioning the element absolutely, we immediately lose the whole point of the flex layout.

Answer 2

1) Probably, although I don’t see a fundamental difference in what to apply css to a picture or to a diva. All the same operations are available. I can only assume that in the case of a div, the original image is put into the “far” box, while in the case of an image, it is not. Accordingly, every time you change the ramzer of the div / image, the browser should rescale not what is on the screen, but the original image, and here the dog could rummage around.
In addition, in the issue of divas vs image, I once relied on Yandex, in Yandex maps all tiles were made by divas. Now, unfortunately, I can’t give a proof link anymore (now they finally have canvas there). But it was not so long ago - less than six months ago.