[Kdenlive-devel] last CVS

[Rolf Dubitzky]

On Tuesday 19 November 2002 04:39 pm, Jason Wood wrote:
> On Monday 18 Nov 2002 3:22 pm, Rolf Dubitzky wrote:
> > Anyway, this reminds me of something very important we did not yet talk
> > about concerning the communication part. We nned to tansport all kinds of
> > snapshots from the effect engine to the GUI. A Track in the timeline
> > should contain a very small snapshot of the first and last frame at
> > least, and it would be nice to have the first frame of a clip in the file
> > list too. How should we do that?
> >
> > We cannot have tenth of embeded XWindows.
> > We probably don't want to push the images through a socket.
> > We could use a pipe in the filesystem or shared memory.
> > Shared mem is probably much faster but won't work if GUI and effect
> > engine are on different systems.
>
> I agree that we can't have lots and lots of embedded x-windows :-) But I
> was contemplating perhaps one window, which would act like a tooltip for
> when you are resizing - it would pop up when you start a resize, showing
> you the frame that you are on, and then vanish once the resize has
> finished.

Or we use plain files. The engine could dump a picture into a .png file in 
temporary directory. the gui could then use this .png and display it in the 
timeline. This would only be done twice for each clip in the file list (first 
and maybe last frame), or (if it's fast ennough) for each chunk in the 
timeline.

> Here are some thoughts on the thumbnail issue :
>
> For the most part, thumbails will remain static on all but one clips. In
> other words, the only time that we need to recalculate thumbnail images is
> when we add a new clip to the timeline, or resize a clip (and hence, change
> the frame that should be displayed in the thumbnail.) It is possible that
> we would have to re-create all of the thumbnails if we zoom in or out, but
> this would only affect us if we drag thumbnails across the entire length of
> the clip.

I would define a single fixed timeline-thumbnail size. If the user zooms out 
too much, the thumb just disappeares.

> So thumbnails are easy to cache - we will not need to constantly
> recalculate them.

right. If this cache is just a tmp directory, we can make piave create the 
thumbs directly into this cache. The this could even be reused when you open 
the project the next time?

> If we consider the current size of the video tracks (they are 50 pixels
> high), then to get a correct aspect ratio, we have 66*50 = 3300 pixels to
> transfer; at 32bit color, that would be around 13K per snapshot.

Well, if it's a .png, it's not that much.

> It should be an asyncronous operation - the GUI should not wait around for
> the thumbnails to arrive.

yep.

> I'm unsure as to how much effect throwing snapshots through pipe will have
> - if we consider 13K per snapshot, with 2 thumbnails per clip, then we
> would need approximately 38000 clips on the timeline to require 1 meg of
> data transfer.
>
> I realise I haven't actually said which way I would prefer to do things
> yet, I'm still deciding :-)

Very interesting calculation, 1 meg is not that much. I think we shold go for 
the file or pipe solution (they are pretty similar from implementation point 
of view, pipe is probably much faster (unless the GUI doesn't save to a file 
afterwards). If it turns out bollocks.... we'll try something else. What do 
you think ?

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky  
 e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************