Repaint for large images
Repaint happens by means of the processor, the browser spends for this certain time. With animation, this time has a negative effect on performance. I rested against this problem when I had to animate a sheetfinder from high resolution pictures weighing 100-200kB. And in a number of browsers the problem looked quite disastrous.
This article does not pretend to the rigor of the presentation and the final conclusions. However, I wanted to share the find with the community. The main conclusion is: operations with images should be implemented by means of [canvas], which loads the video card, you should not use the usual tags [img], which serve as a simple presentation of graphics.
So now in order.
There is the following task: to change one picture, whose scale is less than 100%, to another - with a similar scale.
')
We say: “Nothing is easier! We change the src attribute of the img tag. ”So, if you look at how it happens with the Timeline in a Webkit-based browser, you will see that the repaint event is generated and for large images the rotation takes a decent amount of time.
Let's try to change the background image, in this case. Scale can be set by CSS3 property backgroung-size. A little bit faster.
If you use a proprietary zoom, the situation is also not much improved.
Let's try to draw pictures on the canvas - everything will change radically! Repaint takes 0ms.
As a naive illustration of what is said above, the following code may be (using jquery is not justified, but for example it is not important):
In the final page at the event of a click on all three elements, the image rotates. I have the following results on the size of the 110kB picture, shown in the diagram (I want to emphasize that this is not a statistic, just the results for one particular case).
The data differ too much, so that they can be compared only within a single browser, and it is the order that is to be compared; I doubt they show an objective lead time. For webkit browsers, the values are taken from the built-in debugger (timeline tab). Firefox 7 was rated via dynaTrace (unfortunately, IE9 could not be measured with the same tool).
dynaTrace produced quite contradictory results in general: the duration field, which defines the asynchronous execution time, was a record 424.54ms for a “net” execution time of 3.98ms.
Measuring with Speed Tracer (Google) also gave a surprise: the values presented in the form of 250, 84, 84. In general, in a sense, there are more questions than answers.
However, I checked these approximate calculations with practice: replacing the img tag with a canvas brought acceleration by an order of magnitude in Chrome and better performance in Opera (which generally fell out of the repaint speed study). Firefox has become more stable. I explained all this by transferring computations from the processor to the video card.
I hope I managed to convince not to use [img] for other purposes. On the other hand, there were many questions and misunderstandings about measuring the speed of redrawing in browsers. I hope for comments, I specifically brought screenshots with measurements. Criticism of the methodology is welcome!
This article does not pretend to the rigor of the presentation and the final conclusions. However, I wanted to share the find with the community. The main conclusion is: operations with images should be implemented by means of [canvas], which loads the video card, you should not use the usual tags [img], which serve as a simple presentation of graphics.
So now in order.
There is the following task: to change one picture, whose scale is less than 100%, to another - with a similar scale.
')
We say: “Nothing is easier! We change the src attribute of the img tag. ”So, if you look at how it happens with the Timeline in a Webkit-based browser, you will see that the repaint event is generated and for large images the rotation takes a decent amount of time.
Let's try to change the background image, in this case. Scale can be set by CSS3 property backgroung-size. A little bit faster.
If you use a proprietary zoom, the situation is also not much improved.
Let's try to draw pictures on the canvas - everything will change radically! Repaint takes 0ms.
As a naive illustration of what is said above, the following code may be (using jquery is not justified, but for example it is not important):
<html> <head> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script> </head> <body> <div style="display:none"> <img id="im1" src="img2.jpg"/> <img id="im2" src="img3.jpg"> </div> <div><span>IMG SRC</span> <div><img class="rotor" src="img2.jpg" style="border:1px solid #000;" alt="" width="400" height="200"/></div> </div> <div><span>BACKGROUND</span> <div class="rotor" style="border:1px solid #000; width: 400px; height: 200px; background: url(img2.jpg) no-repeat; background-size: 400px 200px;"> </div> </div> <div><span>CANVAS</span> <div> <canvas id="canvas" class="rotor" width="400" height="200" style="border:1px solid #000;"></canvas> </div> </div> <script> var ctx = document.getElementById('canvas').getContext('2d') var img = document.getElementById('im1') img.onload = function(){ ctx.drawImage(img,0,0,400,200) } $('.rotor').click( function(){ if( $(this).is('img') ) { $(this).attr('src', 'img3.jpg') } if( $(this).is('div') ) { $(this).css('backgroundImage','url(img3.jpg)') } if( $(this).is('canvas') ) { var img = document.getElementById('im2') ctx.drawImage(img,0,0,400,200) } $(this).css('borderColor','red') }) </script> </body> </html> In the final page at the event of a click on all three elements, the image rotates. I have the following results on the size of the 110kB picture, shown in the diagram (I want to emphasize that this is not a statistic, just the results for one particular case).
The data differ too much, so that they can be compared only within a single browser, and it is the order that is to be compared; I doubt they show an objective lead time. For webkit browsers, the values are taken from the built-in debugger (timeline tab). Firefox 7 was rated via dynaTrace (unfortunately, IE9 could not be measured with the same tool).
dynaTrace produced quite contradictory results in general: the duration field, which defines the asynchronous execution time, was a record 424.54ms for a “net” execution time of 3.98ms.
Measuring with Speed Tracer (Google) also gave a surprise: the values presented in the form of 250, 84, 84. In general, in a sense, there are more questions than answers.
However, I checked these approximate calculations with practice: replacing the img tag with a canvas brought acceleration by an order of magnitude in Chrome and better performance in Opera (which generally fell out of the repaint speed study). Firefox has become more stable. I explained all this by transferring computations from the processor to the video card.
I hope I managed to convince not to use [img] for other purposes. On the other hand, there were many questions and misunderstandings about measuring the speed of redrawing in browsers. I hope for comments, I specifically brought screenshots with measurements. Criticism of the methodology is welcome!
Source: https://habr.com/ru/post/134653/
All Articles