Vertical timeline centering

[tvoeroes]

This feature, when enabled in the UI (under options), changes the behavior of the timeline view when the TimelineItems are resizing. The timeline view keeps the TimelineItem that the mouse is hovering over in its location in the view. I have made the old behavior the default because I am not confident that everybody will prefer the new behavior but I still think its ready to be included. The first two commits make sense to be merged even if the rest is not approved. I would consider #286 to be fixed with this change.

• 1st commit refactors offset calculation in TimelineItem. There should be no observable changes.
• 2nd commit fixes a off-by-one-frame error in content height calculation. The fix is needed for the feature.
• 3rd commit adds the key to the TimelineItem. Also needed for the feature.
• 4th commit implements vertically centering the timeline on the mouse pointer.
• 5th commit makes the feature a run-time opt-in. The default is the old behavior.

[wolfpld]

The new behavior should be the default behavior.

How does the logic work when the mouse is outside the window and navigation in the timeline is performed with WASD keys?

[tvoeroes]

Should there be an option to switch to the old behavior?

When the mouse is outside of the timeline view window WASD has the old behavior. When the mouse is in the timeline view it uses the mouse position and has the new behavior. This is controlled via the drawMouseLine variable.

This makes vertical dragging consistent with horizontal dragging (it freezes when the mouse is dragged out of the timeline view). Though I think it would be cool if dragging beyond the window would be enabled but I haven't looked in to why this limitation is there (seems like drawMouseLine = true; works). In contrast the WASD controls (old behavior) use the mouse position even when it is outside of the window. I have not dealt with this separation.

But honestly I disabled the feature outside of the window because otherwise there is some weird behavior when the Tracy window is not focused. Probably needs handling of "disappearing" and "reappearing" mouse cursors. The cursor is not considered to have moved by ImGui if it disappears in one place and reappears in another.

[wolfpld]

Should there be an option to switch to the old behavior?

I don't see such need, but if you want it, I won't oppose.

But honestly I disabled the feature outside of the window because otherwise there is some weird behavior when the Tracy window is not focused. Probably needs handling of "disappearing" and "reappearing" mouse cursors. The cursor is not considered to have moved by ImGui if it disappears in one place and reappears in another.

ocornut/imgui#5599 (comment) and the following comments may be related.

[tvoeroes]

I removed the switch from GUI but I kept it in code. I don't want to burn the bridge yet. I also adjusted the shouldUpdateCenterItem() function such that the glitches that I mentioned wouldn't happen. I wouldn't blame that problem on ImGui the API makes sense.

Something else that I thought was a regression of a use-case but I just found a workaround: Sometimes I want to zoom out and see what is above the view without the additional step of scrolling/dragging up. The old behavior was that the items would just expand down but now (that took me a while to realize) you have to move the mouse up to where the timeline ruler or the frame view is to get the same effect.