Fix CSS step timing functions jump-both, jump-start, start at timestamp 0; Early return when possible

[yezhizhen]

• The keyframe selection used <= for normal direction, causing the first keyframe to be selected at progress 0; changed to < for normal direction (kept <= for reverse to avoid Fix CSS step timing functions jump-both, jump-start, start at timestamp 0; Early return when possible #342 (comment)) and added direction‑aware step‑function handling.
• Guard against division‑by‑zero for zero‑length keyframe intervals.

Make early return happen earlier:

1. total_progress ≥ 1.0 and total_progress < 0 now handled immediately. Also make it direction aware.
2. At timestamp 0, for normal direction, non‑jump step functions (jump‑end, jump‑none, end) now return the start‑keyframe value early, instead of proceeding to interpolation.
3. Zero-interval: we exit early to avoid division‑by‑zero in percentage_between_keyframes

Try
Servo PR: servo/servo#43594

[Loirooriol]

Should this be < too?

[yezhizhen]

Actually we shouldn't. Otherwise for reversed direction at timestamp 0, we jump while we shouldn't for jump-start, jump-both, start.

But there's more severe problem I've been trying to fix based on horrible test results..

[Loirooriol]

I tend to think this seems the wrong place to handle timing functions. Shouldn't it be handled in calculate_step_output()?

[yezhizhen]

It is handled there. But previously never get the chance to reach there (L723) due to early return.

The test result looks decent.

There's only one failure case that I hope to check tomorrow.

[xiaochengh]

Agreed to Oriol. Btw I also find PropertyAnimation below weird, as it's resolving the timing function for every property. I imagine a better process would be:

1. Use timing_function.calculate_output() to resolve the progress to a resolved_progress, which is number in [0, 1]
2. Use prev_keyframe if resolved_progress is 0; Use next_keyframe is resolved_progress is 1
3. Otherwise, calculate a linear interpolation between the two keyframes at resolved_progress

In this way we don't need handle special handling of any timing function here.

[yezhizhen]

Shouldn't it be handled in calculate_step_output()?

fn calculate_step_output() is shared with Firefox. But Firefox doesn't have the problem we have here :/
This PR only changes Servo specific code.

[yezhizhen]

We also made early return happen earlier in various cases, instead of proceed to interpolation.

See "Make early return happen earlier" in description.

[yezhizhen]

This is because:

1. We always have steps at 0% and 100%

   stylo/style/servo/animation.rs

   Lines 174 to 175 in a4f1d69

   	debug_assert!(intermediate_steps.first().unwrap().start_percentage == 0.);
   	debug_assert!(intermediate_steps.last().unwrap().start_percentage == 1.);

2. This always exists for total_progress in [0,1), no matter reverse or normal.

[simonwuelker]

The % between two keyframes should never be zero, because if it was then IntermediateComputedKeyframe::generate_from_keyframes should have coalesced those two frames.

If you're seeing two keyframes with the same % then I suspect the bug is in that function and not here.

[yezhizhen]

It is not a bug of that function, but the result of index computation.

For example, reverse direction at total_progress == 0.0 can trigger the equality.