[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz] A vob matcher that knows about connections
From: |
Benja Fallenstein |
Subject: |
[Gzz] A vob matcher that knows about connections |
Date: |
Fri, 28 Feb 2003 15:30:27 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 |
I thought more about my idea from yesterday. We would have a vob matcher
with an additional method:
addConnection(int cs1, Object key, int c2);
This would tell the matcher that cs1 and cs2 are connected in a way
specified by the key. For example, when showing two RDF nodes connected
by an RDF triple, we could put the property as the key. We could also
use the triple.
Implementations of this interface would have to follow the following
constraint:
If there are transforms 'x1' and 'y1' in the first vob scene
and transforms 'x2' and 'y2' in the second vob scene, and
there are connections (x1, key, y1) and (x2, key, y2) for
some 'key', then x1 can only be interpolated to x2 if y1 is
interpolated to y2; and y1 can only be interpolated to y2
if x1 is interpolated to x2.
(Of course, vobmatchers should be allowed to violate this constraint if
the application programmer explicitly requests so through some
vobmatcher-specific interface.)
How to compute a non-trivial (like, non-empty) interpolation table
matching this constraint isn't clear to me yet; if there's no way, we
need to drop this, but I'd hope there to be something simple.
Ok, this is very formal, but I'm having difficulties explaining the
actual advantages so far. Let's try an example::
A-B
\
C-F-A-B-C
/
D-E
F is focused. Now we move left or right; it's clear what should not
happen: the upper left A interpolated to the A to the right, for
example. But if the F in the middle is interpolated correctly, then the
A right of it must also be interpolated correctly, due to my constraint,
and because of that, the B right of the A... and the C right of *that*,
if we moved right and it's still visible.
This, combined with simple telling the matcher which cs moved to the
focus, would go a long way to solve many repetition problems, even when
interpolating between similar views like simple & wheel. When
interpolating between dissimilar views, the connections will be
different ones, the constraint won't apply, and we'll have normal
key-based matching.
(Oh, I'm making the assumption that a single cs can only be interpolated
to a single other cs. Otherwise, after moving right in the above
example, the upper-left A could be interpolated to the to-the-right A,
because the upper-left A wouldn't be in the target vob scene, and so the
connection to the upper-left B wouldn't either, the constraint doesn't
apply, and the upper-left A is free to move whereever.)
- Benja
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gzz] A vob matcher that knows about connections,
Benja Fallenstein <=