It's a little bit of a battle to fit all of the media controls in the
available width of the media element. We currently cram everything on
one horizontal line. We've made adjustments to be able to fit it all,
but the controls (in particular the media timeline) are rather squished.
This paints the timeline above the other media controls now. This
provides much more granular control over the playback position when
scrubbing, and makes it much more likely for the timeline to render at
all.
This implements the ability to drag the timeline and volume buttons on
UA-rendered media controls. The two behave a bit differently:
Volume is updated as the user drags the volume button. This isn't a very
expensive operation, so updating in real-time and hearing the volume
change feels nice.
The current time, on the other hand, is not committed until the user
releases the mouse button. Performing a seek every time we get a mouse-
move event is pretty laggy, especially for video. However, we still want
to render updates on the timeline itself (so the position of the button
and the timestamp update as you drag). To do so, we internally pause the
media and override the timestamp provided to the layout node.
In the future, we may be able to seek video periodically to provide some
visual feedback. For example, we can seek after every N seconds of
scrubbing, or when the user pauses scrubbing for a while.
The idea here is to let us decide ahead of time what components to paint
depending on the size available. We currently paint each component left-
to-right, until we run out of room. This implicitly gives priority to
the left-most components.
We will soon paint volume controls on the right-side of the timeline.
Subjectively, they should have a higher priority than, say, the timeline
scrubbing bar (i.e. it's more important to be able to mute audio than to
seek). By computing these components before painting, we can more easily
allocate sections to the components in priority order, until the area
remaining has been depleted.
This moves the painting of the media timeout out of VideoPaintable into
a base MediaPaintable. This is to allow re-using the same timeline logic
and controls for audio elements.
