IntervalBinaryTree might require auto-balancing

[alexandercerutti]

When a document is well-composed (no unordered cues, correct timings, etc.) or perhaps streamed (during live content), the Interval Binary Tree beneath the Tracks, will be an all-right tree. This might lead, potentially, to higher retrieving time to reach the last element to show as the current time increases (as we have to navigate the whole tree on the right - e.g. when the content is in the middle of its duration).

The solution is to let it auto-balance, which is an AVL-Tree feature (it can be seen here) when new cues are available. This would let us cut in half the time to retrieve the time of retrieving.

Of course, the discussion is open (if anyone will ever read this 😄) and to implement an auto-balancing, we should decide first a limit after which the balancing is needed.

A little concern that comes to my mind is that auto-balancing could be decided to be performed in as small as possible chunks, as it might require some time (depending on the number of cues in the tree). Even if it is decided to be performed as a micro-queue activity, it should be performed as fast as possible to not block the retrieving of the current cues, which happens through a setTimeout (hence "macro-queue" or whatever is it called).