Animation

[nigeltao]

The original (2016) specification provides static (non-animated) vector graphics.

It might be nice to extend the file format (in a backwards compatible way) to support animated vector graphics. I don't have a specific design proposal at this stage, but this issue is the place to discuss what that might look like, for the file format and for the API.

[precious-omovoiye]

Hi @nigeltao, I will like to contribute to this

[nigeltao]

OK. What can you do?

[precious-omovoiye]

From your description, I can deduce that there is a need to animate already existing vector graphics, I can help with that.

[nigeltao]

OK, but this is about designing a backwards-compatible extension to a file format, at the bits and bytes level of programming. This is not about taking e.g. a suite of existing static icons and animating them in After Effects.

I'll repeat my question. What can you do? What skills do you have?

[precious-omovoiye]

Oh, okay, I see
For your question, I'm a motion designer and I can actually take existing static icons into after effects and animate them, and it seems that's not what the issue is about. Thank you for your time.

[Hixie]

There's two basic approaches to animation that I can see: rerun the entire program each frame, or a pretty radical change to the format that allows for some data to be precomputed on load, and for each frame to be computed without redundantly recomputing common elements. This latter approach would be much faster at runtime but seems very far from where IconVG is today.

Based on the goals of compactness and simplicity (per #4 (comment)), I would probably suggest the first approach of just rerunning the program. One way to do this would be adding a "time" variable that can be used to compute the coordinates different in some way. However, that would require significant new features for math. Another variant would be to use keyframes and have the renderer lerp between values based on the time (you would probably also need opcodes for "skip this section when time mod N is outside of range Q..R" or some such).

Having said all that, I question the target audience here. I suspect most places that care about animation care about performance above compactness and simplicity.

[nigeltao]

There's two basic approaches to animation that I can see: rerun the entire program each frame, or a pretty radical change to the format that allows for some data to be precomputed on load, and for each frame to be computed without redundantly recomputing common elements. This latter approach would be much faster at runtime but seems very far from where IconVG is today.

Is it very far? The Compound Graphics section of the #4 comment means that, e.g. for an animated dog graphic, the head, body and tail can be separate IconVG fragments that are uploaded to the GPU once, not once per frame. Each frame has to re-calculate a transformation matrix, as a function of t, of the separate components. But each component's geometry (vertex coordinates) or colors don't have to be decoded again or converted to a GPU-optimal format again.

Yeah, it's not pre-computing SPIR-V code but I still don't think it's prohibitively expensive, and depending on SPIR-V has its own trade-offs.

Based on the goals of compactness and simplicity (per #4 (comment)), I would probably suggest the first approach of just rerunning the program. One way to do this would be adding a "time" variable that can be used to compute the coordinates different in some way. However, that would require significant new features for math.

Well, yes, that's what I meant by "Animation... in some form, which I still think comes naturally from adding Parameters and some sort of general compute to Compound Graphics" from another #4 comment.

Having said all that, I question the target audience here.

As a rough and simplistic approximation, I'd like to be able to say <img src="animated.iconvg">.

I suspect most places that care about animation care about performance above compactness and simplicity.

Sure, but I still think this can be reasonably performant. I still think that the bulk of the time is in vector rasterization (e.g. in Skia), not in decoding the coordinates (e.g. in the IconVG library per se). In terms of pixel width and pixel height, the former is O(W*H) and the latter is O(1).

Yeah, the Dart decoder is not as fast as the C decoder, but my takeaway from that data is more about Dart than about IconVG.

[Hixie]

Compound Graphics

Right, that's the big change from the current format that I was referring to.

As a rough and simplistic approximation, I'd like to be able to say <img src="animated.iconvg">.

In that case I would strongly recommend getting multiple browser vendors on board, maybe having the spec be a WHATWG document, that kind of thing.

[nigeltao]

In that case I would strongly recommend getting multiple browser vendors on board, maybe having the spec be a WHATWG document, that kind of thing.

Well, sure, but that's not the next step. The next few steps, I think, involve settling File Format Version 1, especially in a forward-compatible way. I'd like a C encoder too, not just a C decoder. Then, per #4, animation and other major new features "is more open ended and will require extensive prototyping". Only after all of that would I consider starting the browser vendor / WHATWG conversations.

And I'm also not wedded exclusively to <img src="animated.iconvg"> as an end goal. If Flutter or another GUI framework or a game with 2-D graphics want to play with IconVG, that's cool too. I was just suggesting <img> to give an idea of the scope I'm aiming for - an 'elevator pitch'.

[Hixie]

In my experience, if you want the browsers to implement something, you need to get them on board before you decide the name of the format, let alone deciding what features it should support, whether it's text-based or binary, etc. It's good to have a proof of concept to guide the discussion, and you have that already, so I wouldn't delay in starting discussions and I definitely wouldn't make any more decisions until you have them on board. If browser implementations is a goal.

[nigeltao]

OK, noted. Although this is drifting off-topic from Animation per se, and as I said, I'm not 'betting the farm' on browser adoption.

[tomasdev]

From After Effects to "animated SVG" there's https://airbnb.design/lottie/ which has a native implementation for iOS and Android of their json-alike format. In web, it ends up being an SVG animated through JS.