On Wed, Feb 17, 2010 at 6:14 AM, Brandon Lewis <[email protected]> wrote:
> The question is, "when should Transition objects be created and > destroyed?" Our notion of transitions implies that they can only exist > when at least two clips "overlap" each other on the same layer (have > equal priority), like this (here the clips are staggered for clarity): > > [AAAAAAAAA] > [BBBBBBBBBBBB] > |---Time---------------> Ok > Furthermore, Transition(A, B) is invalid (should not exist) in these > situations: > > [AAAAAAAAA] > [BBBB] > > [AAA] > [BBBBBBBBBBB] Ok > Do we consider Transition(A, B) and Transition(B, A) to be the same > transition? It will probably be simpler to implement if we think of > transitions as "directional", and require that transitions always go > from earliest to latest. Thus Transition(A, B) is not the same as > Transition(B, A). So Transition(A, B) is invalid in the following case > [but Transition(B, A) is valid]. > > [AAAAAAA] > [BBBBBBBB] > > In other words, Transition(A, B) is valid (should exist) IFF > * A.priority = B.priority, and > * A.start < B.start < A.end < B.end > > So much for the case when there are exactly two clips to consider. If > have three or more overlapping clips, there suddenly seem to be too many > cases to consider. > > [AAAAAAA] > [BBBBBBBB] > [CCCCCC] > [CCCCCC] > [CCCCCCCCCC] > [C] > [CCCCCCCCCC] > .... > > I would argue that we should add the restriction that a transition can > only exist when exactly two clips overlap. Put another way, we should > also consider Transition(A, B) invalid if there exists some clip C that > intersects the area defined by Transition(A, B). Agreed. Let's keep it simple for now. > The simplest approach for automatically managing transitions is just to > do some house-keeping after any operation which adds, removes, or > modifies at least one clip: [...] > The tricky part is defining valid(), because you need to check for clips > which might intersect the region between A and B. Once you have valid() > you can write getOverlapping(), which returns all the valid pairs at the > given priority. > > I could develop this approach, but it doesn't lend itself to giving > instantaneous feedback during interactive operations (i.e. showing when > transitions are created or destroyed while the user is moving the > mouse). I'm concerned that iterating over all transitions and track > objects repeatedly will create lag in the U.I. Any ideas? Is the any of > the gap prevention code relevant? Yes, in fact I think reusing the existing gap prevention code is the easiest solution. We already track overlapping clips having the same priority. At the moment when we detect overlaps (a gap has duration < 0), we rearrange clips so that they never overlap. MoveContext.finish() in pitivi/timeline/timeline.py uses the gap code and implements the logic to avoid gaps while moving clips. Take a look at that it's pretty simple. Ciao Alessandro ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Pitivi-pitivi mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
