Unifying the rendering approach

Hi all,

The introduction of regions created a second code path in the
rendering spec with some duplication.

At FOMS, several people voiced that they are unhappy about it.
We discussed if it was possible to unify that.

The proposal that we came up with was to put *all* cues into regions.
A region is thus basically the background box into which cues are
rendered.

Cues that have no region reference will be put into an anonymous
region that has:
* no identifier,
* the dimensions of the viewport (vw, vh),
* no scroll,
* a region anchor of (0,100),
* a region viewport anchor of (0,100).

The intent is to allow us to create a single rendering path for all cues.

However, there are differences between cues that are currently
rendered without a region and those that are rendered into a region
and we have to work these out. We can either try to retain the
previous behaviour or come up with a better, more integrated way of
doing it.

So, I've gone through and tried to identify the differences.

* overlap avoidance: cues without a region have a means to deal with
overlap and move cue positions. The approach here is different between
snap-to-line positioned cues and percentage positioned cues. I'd like
to come up with an algorithm that deals the same with all cues. Also,
it needs to be deterministic for the JavaScript developer so they can
potentially do even more repositioning if necessary. So, my thoughts
are that we should just avoid placing cues into lines (for horizontal
cues; rows for vertical cues) that are already occupied by another
cue. That's basically the algorithm for snap-to-line positioned cues.
It wouldn't apply to scrolling regions, but to all other ones.

(BTW: I think we need two levels of overlap avoidance: one within a
track and one that optimizes between all tracks, not just VTT tracks.
So, we may need to create an algorithm for the HTML spec for this,
too. But this is a discussion for another day.)

* snap-to-lines: cues in a region don't have snap-to-lines
positioning. When we place such cues into anonymous regions, we
calculate the number of lines from the size of the region, which for
an anonymous region is the size of the viewport. So, this should be
fine.

* title area: right now we have a means to specify a "title area" for
snap-to-lines cues. I think we can remove that because we now have
padding on the cue background box (which will be the region in
future), so we have that covered for all types of cues.


Are there any other issues I have overlooked?


Thanks,
Silvia.

Received on Friday, 24 January 2014 05:27:02 UTC