Contributions: big or small? How about big?

[earlye]

This work is available as releases at my fork: https://github.com/earlye/friction I'm happy to create a PR back to upstream once it's stabilized, if y'all want it. If not, no harm no foul - I'll just keep this fork going.

This past weekend I implemented a capability to animate elements inside a linked svg. This changes friction so that svg docs can effectively be "reusable puppets" and friction can act as the puppeteer.

You can rig the svg itself in inkscape (or other svg software that supports <desc>) by injecting a tag containing yaml:

<g id="foo"><desc>
kind: animation-node
</desc></g>

These kind s of yaml doc exist:

kind: animation-node # the enclosing element should get an animation track to adjust translation and opacity.
---
kind: pivot # the enclosing element is the pivot point for its enclosing animation-node.
---
kind: flipbook # the enclosing element is a flipbook
map:
  0: "other-element-id"
  1: "another-element-id"

There is a new "camera" object that you can add, which is always enclosed in a flipbook. The active camera replaces the normal cropping region so that you can animate it and/or switch as a render progresses. This feature's a little buggy right now; I'm working through that. "C" switches from "look through the active camera" to "look at the world".

Oh, and I changed it so "insert key" is always 'k' regardless of platform so I can speak in hotkeys with my family despite having a "degenerate" macbook pro.

There's also a known bug on windows where playback appears to be dropping the cached frames. I can't reproduce on mac, so I've got a slow process to collect logs from a PR.

Thoughts?

[pgilfernandez]

Looks nice, could you add visual examples please?

[earlye]

https://github.com/earlye/friction/blob/main/earlye-fork.md <-- I took a minute to build out a doc w/ some screenshots. Mostly on the inkscape side. I'll try to find some time to show how the animation-node and flipbook things change what you see in friction, but it may be a day or two. Day job and all that.

[earlye]

That doc also groups PRs that were purely bug fixes. The vast majority are "I'm adding a feature and didn't get it quite right" fixes, but some were pre-existing. Would you like me to re-craft the fixes for pre-existing bugs for mainline friction first?

[rodlie]

Hi,

big contributions are welcome (if we split them up). Note that main is mostly in a feature freeze (we may allow some new stuff as long as it's not too complicated or break anything) before the upcoming v1.0.0 release (a week or two ish), after that main is open for new features etc as we continue the development of v1.1.

I will need some time to go through the changes, but direct bug fixes (not introduced by the fork) are very much welcome. When I have more questions I will add comments to this issue.

---

Going through your list I see earlye#18 as something we can include now, note that it will need some changes:

• The change in getVideoFrame seems like a workaround for an issue fixed in cd80c0c . You scale the image, that's a no go, if image does not match codec we throw instead:

if (c->width != image->width() || c->height != image->height()) {
       RuntimeThrow("Image size don't match codec size");
}

• The Image use-after-free is a valid fix

So add the check for image size and throw if wrong, the sws_getCachedContext change is ok, but no need to change from c to pixmap since we know that the dimensions are identical.

---

When doing PRs against Friction do not add claude as co-author, I'm fine with people using AI tools to figure out a solution, but the final PR must come from a human.