Re: Unifying the rendering approach

On Wed, Jan 29, 2014 at 11:25 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> On Tue, Jan 28, 2014 at 4: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.
> > *) 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
>
> I'm sorry I didn't reply to this at the time, I had drafted a reply
> but then got distracted by other things.
>
> From a very high level, the idea of having only snap-to-line cues and
> a single mechanism for absolute positioning is appealing, because it
> sounds like it *could* simplify the model, and avoids the somewhat odd
> absolutely positioned cues within absolutely positioned regions.
>
> So, the first step is to get rid of the snap-to-lines concept and just
> always snap. That's nice, it makes the model simpler, both in API and
> rendering algorithm.
>
> It also makes WebVTT less capable, so how do we bring back absolute
> positioning? For fixed-size regions it's rather uncomplicated, and for
> auto-sized regions this is what the mail from December says:
>
> > Assume we have "height:auto width:auto" and a chunk of text (multiple
> > cues) belonging to it. Now, what follows should essentially be a
> > two-step layout: first we artificially set the (height, width) to
> > (video height, video width) and simply render the lines within this
> > box following the the CSS wrapping rules or manually entered line
> > breaks.
> >
> > In most of the cases, we will actually end up with a box which is of
> > smaller sizes (at least in one of the dimensions) and then we
> > translate the origin of the resulted rendered box (considering the
> > actual sizes) with (-regionanchorX%, -regionanchorY%) and we honor the
> > region anchor.
>
> OK, do layout, shrink to fit, and then treat that box as a unit,
> anchoring it where it's supposed to be. I see no reason why this is a
> terrible idea so far. What happens when cues are added or removed to a
> region? I assume that each render would work the same, so that the
> region can grow and shrink dynamically?
>

Yes. The goal of re-sizing the region would be to honor cleanly the anchor
point - if the region anchor point is (0, 0) then, regardless of its size,
it will have its top-left corner fixed in some point on the viewport. Same
happens for (50, 50) when the middle of the region will now be anchored
somewhere on top of the video.

Is my understanding correct? At this point I'm somewhat optimistic
> about this approach. I think that in order to see if it really works
> we have to flesh out the model in detail, go through all the modes of
> rendering we can currently achieve and see if they can be represented
> in the new model. If the new model turns out to be *more* powerful,
> then we need to make sure there are actually (reasonable) use cases
> for the new things.
>

Yes, I think we are on the same page with the model.

I didn't think a lot about corner cases, but I'm tempted to say that this
can be a backwards-compatible change, transparent to existing content
(unless we drop support for things in the syntax)


Silvia, your turn :)
>
> (I've avoided talking about how to map the current model to a new
> model, because I think that if enough content depends on the current
> model then we shouldn't mess with it.)
>
> Philip
>