7 ms·
Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.
by jtangelder 1y ago
Wondering what the performance of a simple animated gif would be, instead of the composite layer transformations.
- nightpool 1y agoGIFs historically were pretty unoptimized from a display perspective (as anyone with a moderately-active Tumblr dashboard could tell you), so I wouldn't be surprised if it was worse.
- xp84 1y agoI disagree. The height of a DOM element is much more expensive to recompute as this article shows than a single element which gets frames swapped out with static images. The latter can be guaranteed to never impact any other part of the document. The end result of either is that the pixels in the animated area need to be recomputed, and end result which will be the same for both, but a GIF will have no further impact on anything else whereas resizing DOM elements has side effects that have to be constantly updated and checked for which scale with the number of sprites you're animating (unlike the GIF bitmap which is gonna be 'flat rate'). Likewise, for a tiny animation, having the frames of the GIF in memory and blitting them onto the screen in sequence sounds like orders of magnitude less CPU/GPU than performing all the ridiculous math-based transforms over and over again. The Tumblr example is not instructive here because those were frequently many many frames, very colorful (often photos), and/or large in dimensions, taking up a ton of memory which was probably the main problem causing our browsers to choke. This would be none of those things.
- evan_ 1y agoOr if you need to actually control it, an SVG or <canvas> based animation
- dylan604 1y agoIf the bars are not related to actual data and are purely just pre-canned animation, the gif would just come with additional file size for a one time cached type of download. If the bars do need to be animated to real-time data coming in, then the gif would not be the right fit for that need.
- threetonesun 1y agoCan't imagine anyone is deriving much information value from a visualizer with 3 bars. Apple Music has a similar animation and it will start bouncing when you click play, while the music is clearly downloading and there's no sound.
- dylan604 1y agoJust because it isn't useful to the user doesn't mean some dev hasn't spent the cycles doing it. I know I've personally had to write code that was an absolute waste, but some PM wanted and it was coded. Usually so it can be a bullet point in a demo that impresses low skilled PMs or sales drone, but techy user types just roll their eyes when it's pointed out to them.
- hbn 1y agoI think a mic visualizer is very useful to the user. You can tell if you're quiet, clipping, or your mic straight up isn't working at all.
- dylan604 1y agoYou've moved the goal posts. Nobody said an input levels indicator isn't useful. We're talking about this specific graphic not being a useful graphic for visualizing live data. You've wandered away from the pack here
- will-bradshaw 1y agoThis was true pre iOS 18. The bars respond to the music now (at least on iOS)!
- threetonesun 1y agoAh, look at that, so they do!
- xp84 1y ago
- norskeld 1y agoPersonally, I'd be annoyed by both the resource-consuming animations and the blurry GIFs/canvas. Infisical does use the latter (canvas) for icons in their UI, and I somewhat hate it. I'd rather look at crisp, but static icons.
- jasonjmcghee 1y agoCanvas should never be blurry. If it is, something is doing a bilinear upscale. I'd guess someone forgot to take the scale factor of your display into account. Or there are images being used in the canvas, which would defeat the purpose for the use case you described.