Re: Unifying the rendering approach

On Tue, Jan 28, 2014 at 11:10 PM, Victor Carbune
<victor.carbune@gmail.com> wrote:
> On Tue, Jan 28, 2014 at 12:11 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>>
>> 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.
>
>
> I'm sorry, then I misunderstood your line stating that "snap-to-lines: cues
> in a region don't have snap-to-lines positioning.", as I would say that
> snap-to-lines positioning remains the same within the region.

Right, what I meant is that right now regions don't allow for line
positioned cues, but that we can accommodate that, in particular in
anonymous regions that cover the full viewport, but also more
generally in all regions. Currently regions have a default number of 3
lines, so line positioning within those is somewhat restricted unless
the author extends the number of lines.


>> > *) 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.
>
>
> It's not about overlapping - you need the final region surrounding the cue
> to match it's contents in order to honor the authored
> percentage-positioning.

I don't follow. Why does the region have to be shrunk for the cue to
be correctly positioned?


> So if your anonymous region surrounding the cue ends
> with a larger size, translating it with (-regionAnchorX%, -regionAnchorY%)
> ends up positioning the cue differently.

I don't follow this problem either. Anonymous regions cover the video
viewport and are anchored to the bottom left corner. What is the
"larger size" you are referring to? Can you maybe explain via an
example?

Silvia.


>> > 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 Sunday, 2 February 2014 02:23:14 UTC