I don't uinderstand why you got downvotes. It's a fair, albeit somewhat misguided, comment.
Basically, a lot more power will be consumed by downloading an animation and decompressing it, assuming it is shown at comparably high quality (no noticeable compression artefacts).
On current hardware (a.k.a. the last 10 years or something), showing a flat picture or a rotating 3D object consisting of a small amount of vertices has no significant power usage difference.
In fact, there's a fair chance that what you're looking at right now is in fact a 3D-rendered rectangle positioned in front of the camera precisely such that it looks flat and fills the screen (it's a bit different than that, because there's not really a camera but that's just nitpicking), mapped with a texture containing whatever pixels the OS wants you to see.
> On current hardware (a.k.a. the last 10 years or something), showing a flat picture or a rotating 3D object consisting of a small amount of vertices has no significant power usage difference.
In properly optimized software, yes. In current browsers? We're not there yet. In firefox I get maybe 10fps on these animations, and in all browsers it causes a minor temperature spike that h264 video does not.
>creating a server side animation and serving it in compressed format
What compressed format would that be? WebGL code+textures is a pretty compressed way of transmitting and the dedicated 3D hardward that WebGL interfaces to is probably the most efficient available on the target to put the bits on the screen. The fact that WebGL punches through directly to hardware certainly makes it seem less inefficient than your typical web stack.
Instead of creating a server side animation and serving it in compressed format you force every single web-browser to render it.
Also nice work, because it looks good. I wonder if we will see the development of OpenGL caching techniques.