Re: Unifying the rendering approach

On Mon, Jan 27, 2014 at 8:35 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Fri, Jan 24, 2014 at 12:26 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> 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?
>
> I wrote about how I think we should solve this in
> http://lists.w3.org/Archives/Public/public-texttracks/2013Nov/0012.html

Sorry I missed that. :-(

> To reiterate, I'd like to turn the scrolling into part of the overlap
> avoidance, so that when a cue would overlap at its preferred position,
> one of two things happen:
>
> 1. The cue (horizontal text at line -1) is moved up until a free space
> is found and it is left there. (this is the current spec)

This would be used for scroll=false. I like this, it meets with what I
suggested above (in more complicated words).
Since anonymous regions would have scroll=false, they get this
behaviour, which meets with the existing overlap avoidance algorithm
for snap-to-lines. So, the new thing would be that this also applies
to percentage-positioned cues.

> 2. The cue is moved down until a free space is found. Then, this cue
> is moved (optionally animated, i.e. scrolling) up to its preferred
> position. Any cue it then overlaps is moved up by an equal amount. Any
> cues that overlap in turn are also moved up, and so on until
> everything has been moved.

Right, that's what happens when scroll=true right now already.


> The overlap avoidance mode would ideally be a property of the cue, to
> relieve regions of that responsibility.

Hmm, interesting. Scrolling would happen within the region, but it
would take into account all other cues currently rendered?

> Scrolling or not becomes a
> matter for CSS, to animate the relevant property on the cues or not.

That's already how it's specified.

I think this can work...

Silvia.

Received on Tuesday, 28 January 2014 08:17:42 UTC