Re: Unifying the rendering approach

On Tue, Jan 28, 2014 at 8:46 PM, Victor Carbune
<victor.carbune@gmail.com> wrote:
> On Fri, Jan 24, 2014 at 6:26 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>
>> 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.
>
>
> I actually see the current spec mapped into regions like this:
> *) snap-to-lines positioning remains the same and applies now within regions
> (which have fixed height, in terms of number of lines, so being able to put
> a cue in a specific row of the region makes a lot of sense); further,
> overlap avoidance is enhanced with Philip's ideas of animating cue
> scrolling.

That's what I tried to say, too, in that first email.


> *) non-snap-to-lines cues are mapped artificially in an anonymous region
> with a two-step layout (if no height/width specified, then the region
> reduces in the second step to the rendered text sizes). I wrote some of my
> ideas here:
> http://lists.w3.org/Archives/Public/public-texttracks/2013Dec/0008.html

Hmm... why do we need to change the dimensions of regions to avoid
overlapping cues? I don't think we need to deal with region overlap.


> The default case, with
> *) cues that have snap-to-lines set and no region specified end up in the
> anonymous region you described at the beginning (hence the same rendering
> happens as the current spec)

Right.


Silvia.

> On Tue, Jan 28, 2014 at 9:39 AM, Philip Jägenstedt <philipj@opera.com>
> wrote:
>>
>> On Tue, Jan 28, 2014 at 3:16 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>> > On Mon, Jan 27, 2014 at 8:35 PM, Philip Jägenstedt <philipj@opera.com>
>> > wrote:
>>
>> >> 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.
>>
>> Oh, I hadn't thought about percentage-positioned cues. There's a bug
>> with a ton of comments on that topic:
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22029
>
>
> If we map these into anonymous regions (as briefly discussed at FOMS), then
> the problem really changes to supporting overlap avoidance for regions,
> which I remember we didn't want to support.
>
> Or, region overlap avoidance could be deferred to an upper level mechanism
> (on the lines of what Silvia briefly pointed out): each track (VTT or not)
> throws a couple of boxes (x, y, width, height) - regions in the case of VTT
> - with respect to the viewport and they are re-positioned such that no
> overlap happens. The good part is that this problem could be tackled in the
> future, when there's a need for it.
>
>> >> 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.
>>
>> Well, approximately, but it's completely separate from the other
>> overlap avoidance mode. My suggestion is to make it part of the
>> "Adjust the positions of boxes according to the appropriate steps from
>> the following list:" steps.
>>
>> >> 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?
>>
>> I'm suggesting that moving other cues (possibly animated) be an
>> overlap avoidance mode, not dependent on regions at all. It would be a
>> per-cue thing, so that when a cue that has this mode is rendered, it
>> can move any other cue in order to get the position it wants. (You can
>> create interesting cases with cues being pushed back and forth, but I
>> don't expect this to be a problem since the algorithm handles the cues
>> in a deterministic order.)
>
>
> This sounds great, from my point of view.  In my suggested mapping, I see
> this blending in good for snap-to-lines cues within regions (I believe the
> approach you're suggesting doesn't care whether the cue lies in a region or
> not).
>
> Victor

Received on Tuesday, 28 January 2014 11:12:47 UTC