Averaging numbers is easy. Deciding which numbers to average is not, and it has a name.
A hamburger has three strokes. A cross has two. Before anything can be interpolated, something has to answer three questions:
None of those has an obviously correct answer, and every one of them is visible when you get it wrong.
Answer them yourself. Every arrangement below is legal, nothing errors, and several look absurd, which is the point: the browser will faithfully animate whichever correspondence it is handed.
Start with the easiest-looking question and watch it fail. Say the top bar becomes the \
diagonal. Both are single strokes, one pair, no ambiguity.
A bar runs left to right: it starts at (4, 6) and ends at (20, 6). The diagonal also
runs left to right, (7, 7) to (17, 17). Pair start with start and it rotates cleanly.
Now the other diagonal, the /. Lucide writes it as (18, 6) to (6, 18), which is
right to left. Pair start with start and the bar's left end has to travel all the way
across to the icon's right side while its right end travels left. The stroke passes through
itself, collapses to a point in the middle, and comes out the other side backwards.
Nothing is broken. The maths did exactly what it was told. The two paths simply disagreed about which end was the beginning, and that disagreement is invisible in the source.
Three bars, two diagonals. One bar has nowhere to go.
The obvious answer is to fade it out, and the obvious answer is wrong in an interesting way. Fading leaves the stroke sitting in the middle of the icon getting fainter while the other two rotate around it, which reads as a bug rather than as a decision.
The better answer is that the spare stroke should be somewhere specific: sitting exactly on top of one of the other two, so the animation reads as one stroke splitting into two rather than as a stroke evaporating. That is called parking, and it turns out to have a subtle rendering problem of its own, which is Part 5.
With three bars and two diagonals there are six ways to assign them. Most look wrong. One or two look right, and which ones depend on what you think the icon means.
Now scale that up. Two icons with six strokes each have 720 possible assignments. The count is factorial, so this is not something you can brute force past a handful of strokes, and it is not something you can eyeball for a library of two thousand icons.
You looked at the hamburger and the cross and knew what should happen. Top bar becomes one diagonal, bottom bar becomes the other, middle bar tucks away. It took no effort.
That is because you understand what the icons mean. You know a hamburger is a stack and a cross is an X. You know the visual grammar the designer used.
A computer has two lists of numbers. It has no idea that one drawing means "menu". Every approach to this problem is some way of recovering, from geometry alone, a decision that you made from meaning.
Correspondence is the whole problem. Interpolation is arithmetic. Everything interesting a morphing library does is an attempt to answer which becomes which, without being able to see.
There are only two places to answer it.
You can answer it at runtime, on the user's device, every time the page loads. Look at the two shapes, measure them, score the possible pairings, pick the best one. This is what most libraries do and it is genuinely clever work.
Or you can answer it once, ahead of time, and write the answer down as data that ships with the icons.
Those two choices lead to completely different products, and the difference is not really about performance. Part 3.