It actually suites the look we chose very well. I would be aboslutely okay with a low framerate. Still I may be missing something here.Ī3) Do you think there is a performance difference in moving PNG or GIF?Īs long as the result is visually pleasing, I'm can deal with fan's starting to go nuts over a "simple website animation".īut on some devices I sometimes get noticeable frame-drops (very few actual lags/stutters) I couldn't track a mentionable difference in performance, so far. So I naturally lean towards gif, although the sizes are in such low ranges, that it doesn't really matter. Our *.gif's are by default more than 4 times smaller. The browser wouldn't need to scale that much,Ī2) but wouldn't it be much harder for the browser to move ultra large images? You would make the sprites and the background image larger, say stretch the look on a 1920 width image? When I understand Carls suggestion correctly: Plus, because perceived image of the fire-sprite practially doesn't move at all, the blurryness is a pain in the butt here aswell. The pixelated look feels like "tried hard, failed harder". I see what Carl means with the blurryness it may not be an visual issue while the elements are moving, wiggling etc.īut as soon as they come to a stop, which the background and dude do, the images are blurry and look ugly as hell. When I leave force3D on auto (strictly speaking: just don't set any myself) the performance is way way better, but the everything gets really blurry.Ī1) Why is it getting blurry, although auto chooses false under the hood, anyway? (I figured once the base64 is encoded by the browser it behaves exactly the same as an referenced image-source) In my early tests looking for the performance issue nothing changed when I went with referenced images. The images are very tiny in size so on poor internet the loading-bottleneck won't be the filesize, but the number of http-requests. See the Pen oWVyom by katerlouis ( on CodePen Or, to stay in 2D mode whenever possible, set force3D:false. If you'd prefer to keep it in 3D mode, you can set force3D:true. In "auto" mode, GSAP will automatically switch back to 2D when the tween is done (if 3D isn't necessary) to free up more GPU memory. This typically results in the browser putting that element onto its own compositor layer, making animation updates more efficient. So force3D is not the problem, since it is doing what you asked, to be false.Īs of 1.15.0, force3D defaults to "auto" mode which means transforms are automatically optimized for speed by using matrix3d() instead of matrix(), or translate3d() instead of translate(). And your element does indeed use no 3D transforms and is using matrix(), not matrix3d(). You should try and replace your jetpack dude with an actual image gif, png, or jpeg. Base64 images are good for mobile for static one time use images, but not for animating. That type of image has very poor performance when animating, especially on mobile when the load event is fired on the image. I believe the issue is that you are using a base64 data:image uri. Plus: Santa's CPU usage doesn't care about force3Dġ) Why does force3D: false infects the CPU usage so drastically? (no GPU acceleration I assume?)Ģ) What can I do to keep the pixelated look with Santas performance? In my case removing force3D: false (it's default is true, right?) brought the CPU down (but not as low as the comparison).īut I need to preserve the pixelated look and therefore keep. I forked the pen and and changed it to also using force3D: false, xPercent and an -solution. – src="data-uri." (Nope, tried classic image reference, same issue)Ĭomparing with other sprite-animations using GSAP I realized the probably familiar Santa Clause doesn't have this issue. – sprite as instead of a background-solution – stepped ease of a scaled up image with image-rendering: pixelated – My (probably highly improvable) Sprite-object When I now add a yPercent-tween of a very tall scenery image to simulate jetpack-dude flying up, it starts lagging significantly and my fan prepares to take of to the moon. CPU ca. 50% in Safari (9.1.3) and latest Chrome (58) on Mac OS X 10.11.6 El Capitan (fully blown up MacBook Pro Retina 15'' late 2013)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |