Encapsulate the delay ratio

[HeroicKatora]

Two major reasons:

• This avoids the public dependency on num_ratio.
• The internal representation can be changed. This already proved
  necessary once (from u16 rational) and in this manner we are free to
  do it again by adding an inner enum representation.

Note that we already have rounding semantics for the meaning of Delay as
gif rounds to the nearest 10ms when writing frames. Any more or less
precise representation can be made to round to the closest u32 ratio.

[HeroicKatora]

After this PR the only remaining public dependency will be num-traits for which the risk of a breaking change seems moderate due to the widespread use and this issue specifically noting that the API is de facto stable. This is tested for with travis.

[fintelia]

Could we avoid adding a new type here, and either use a f32 / u32 with an associated base unit or just a Duration? GIF images can only have delays in multiples of 10ms so it won't impact accuracy for any current uses, and we are probably going to want to redesign this area of the API again anyway

[HeroicKatora]

Good point, an interaction with time::Duration seems trivial and very useful. But the new type can't be easily avoided. The representation varies between image formats, and an exact representation will be impossible with f32. Additionally, I'll argue that a newtype is to more ergonomic choice not only due to its documentation and constructors describing the precise units.

• It allows us to define associated constants, independent of time::Duration such as FPS_30 etc.
• We don't need to choose now and can provide both inexact conversion (the current) and fallible, exact conversions.
• We might be abled to interact with the known image formats by, e.g., providing a gif_delay constructor, although the exact benefits should be discussed sometimes else.

I'll add the rounding, and best effort conversion from time::Duration though as it does seem quite useful regardless.

[HeroicKatora]

@fintelia With conversion from time::Duration added it should be much more useful than the previous representations. However, it was quite involved as we have a lot of edge cases to consider when converting the (essentially) fixed point digit representation to u32 ratios. It should be alright though, and all the complexity hidden which only increases its usefulness.

[HeroicKatora]

Note: we can reuse the implementation of closest_bounded_fraction if we want to add a multiplication operation and addition.

[fintelia]

I'd feel much better about this if we had multiple different image formats that used the animation API, rather than just extrapolating from GIF. Especially since a bunch of the bounded fraction stuff is really only relevant to formats that don't encode frame delays as an integer number of milliseconds. Because of that, I'd lead towards a minimum viable option of just exposing the GIF frame delay, and planning to make a minor breaking change (to add the rest of this proposal) if/when more formats are added

[HeroicKatora]

Especially since a bunch of the bounded fraction stuff is really only relevant to formats that don't encode frame delays as an integer number of milliseconds.

• Right, gif only has a integer delay of 10ms.
• Animated WebP uses a 'u24' integer delay in milliseconds.
• It is APNG which encodes the delay as a ratio of seconds.
• WebM has a TimecodeScale that scales the Timecode etc. of all clusters based on nanosecond resolution but according to the documentation it ' SHOULD be set to a default of 1.000.000 nanoseconds'...

That is already a sufficiently complex amount of conventions to warrant an opaque representation in my opinion, although we might as well switch to an inner enum representation right now instead of later. But let's just get the interface correct and not worry about implementation too much.

and planning to make a minor breaking change (to add the rest of this proposal)

A change can't be both minor and breaking, and lib.rs shows the version churn results, many outdated dependencies that are stuck without security and stability updates.

[HeroicKatora]

I'll take it 👍 means that this is fine? Then I'd merge this and prepare release notes for 0.23.

[fintelia]

Sounds good. If you're confident that the design will work for all those other formats as well then I think we should be fine