AnimationGadget : fix crash related to dragging keys on adjacent frames

[mattigruener]

Hey John,

I've spent some time today looking into the crash that Dan reported and think I've finally been able to fix it.

What happened: When moving keys on adjacent frames, if the order in which we processed keys was wrong, we removed an existing key A because another key B was moved to A's location in time, but then processed A as part of the current selection and relied on its parent being valid. The key didn't have a parent at that time though, and Gaffer crashed. Looks like I just never tested with keys on adjacent frames...

What I've done now to fix it is to determine the order in which we process keys by the direction in which the user wants to drag them. Can you have a look at what I've done? The whole thing with a templatized, internal method might be a little clunky, but it allows me to easily reverse the iteration direction by using reverse_iterators. I can look into making that a free function that accepts m_overwrittenKeys as an argument if you find it annoying to have that little templatized helper show up in the header.

After doing that, it took me a little bit to figure out the second part of the puzzle: I had a test scene that worked when building with DEBUG=1, but a release build would always crash. It seems that when doing a debug build, we can rely on Keys getting created in order. With compiler optimizations turned on, that doesn't seem to be the case anymore. What bit me is that we sorted keys by memory address instead of their time value. I've fixed that, as well.

Would you have a look to see if what I've done makes sense?

Cheerio,

Matti.

[johnhaddon]

Hi Matti,

Good detective work! I think the change of sorting criteria for m_selectedKeys is problematic though :

• Keys from different curves, but with the same time, are now considered identical, but they're not. Among other things, this causes problems when trying to drag two curves at the same time.
• Changing the time of a key means the selection is no longer sorted, which breaks subsequent set operations. Among other things, this breaks the selection in one AnimationGadget if you move just a subset of it using another AnimationGadget (or via undo, or any other operation).

Basically, using the time breaks the requirements of std::set. The main reason for KeyPtr to exist at all was to allow the AnimationGadget to have a consistent handle for each key. The selection is all about key identity (rather than value), so it should continue to sort by address as before. That means we'll need a different approach to the bugfix. Seems like these might be options :

1. Don't assume the key has a parent. If it doesn't, re-aquire the parent by querying m_overwrittenKeys, and add the key back.
2. Make a temporary vector<Key *> in each call to moveKeyframesInternal(), sorted by time, either ascending or descending depending on the offset. Iterate that.

I'd expect 1 to be quicker in the ideal case of no clashes, but 2 to be quicker in the worst case of everything clashing. I'd be inclined to go for 2 first though, because 1 introduces addKey()/removeKey() calls that aren't really reflective of what we're trying to achieve - it puts the Animation::CurvePlug into strange intermediate states.

Hope that makes sense...
Cheers...
John

[johnhaddon]

would be better to pass KeyPtr by reference rather than by value, to avoid unnecessary increment/decrement of reference count.

[johnhaddon]

This could definitely do with a comment explaining the reason for the different ordering.

[mattigruener]

Hey John,

I believe I've implemented something very close to (2) now. Could you have a look?

Thanks!

Matti.

[mattigruener]

Updated. Removed the templated little helper function and moved the sorting logic into the lambda.

[johnhaddon]

Thanks Matti - merged manually after fixing a small formatting problem...