[Kdenlive-devel] GUI

[Jason Wood]

On Thursday 02 Jan 2003 11:12 am, Rolf Dubitzky wrote:
> I am implementing the parsing of the scenelist. It's a little more work
> than I thought, but I'll get there. One thing that makes problems is that
> kdenlive sends the scelist mcuh too often. when dragging a clip in the
> timeline I get a lot of traffic, not that this is only slowing down the
> system, but it also overstrains the renderer. I could buffer all the sent
> scenelists as ascii, and only parse them if a <seek>-command is sent, but I
> think that the renderer is the wrong place, we should be economic with
> recources.

The buffering should definitely happen on Kdenlive's side of the 
communication. However, the main optimisation that I want to try first is to 
only send the updated parts of the scenelist - this adds another command to 
VEML, so I want to wait until we have released 0.1 source pacakges first.

> In the last kdenlive version I have the feeling that the scrolling through
> the video is more stuttering. The renderer sees very often, that many
> <seek> commands are sent in a single message. Did you introduce some kind
> of buffer or anything? Apart from the fact, that sending multiple <seek> in
> one message does not make much sense anyway (they'll just get dropped) I
> have the impression that the scrolling is not as smooth as it used to to
> be.

Hmm, there is no buffer implemented unless it exists in QT's code. I'll look 
into it.

> Where is that razor tool you mentioned?

It should be available on the Timeline menu, and on the toolbar. If you cannot 
see it, you need to ./configure --prefix=kdeinstalldir and do a "make 
install" to put the kdenliveui.rc file into the correct place.

The spacer tool is also partially implemented - it will select all clips which 
are to the right of where you click, and if you hold down shift, it will also 
select clips which are at the point where you click. Currently, you cannot 
move them though.

> Another thing we need to discuss is, how to handle gaps. kdenlive allows
> for gaps between clips, and especially because the first clip does not snap
> to 0.00 the is almost always a gap between 0.00 and the start of the first
> clip. We have two options: a) the renderer just displays "something" for
> gaps. This "something" could be 'black' a test frame and/or be userdefined.
> b) kdenlive does allow for gaps in the timeline, but does _not_ send gaps
> to the renderer but fills them up a still image element. This way the GUI
> is always in control over what gets displayed in gaps.

If you tell me what you would like me to send for "black", it should take 
about three lines of code to implement.

> Do you think it makes sense to have the first clip _not_ start at 0.00? If
> there is no major reason to not do so, I think it would make sense to
> define 0.00 as the starting point of the first clip. If the user wants a
> few seconds of black before the first clip starts, he can still insert it
> explicitly.

The main reason would be if you are editing your project non-linearly. For 
instance, let's say that I start editing somehwere in the middle of the 
project, I would not bother lining it up with the 0:00.00 mark. When I have 
finished with the middle section, I will just move it to the right on the 
timeline to get it out of the way, and then start work on the title sequence.

If you edit like this (using the timeline as a temporarty workspace, as well 
as for the final edit), then having to specifically specify areas of black 
will feel quite awkward - and I do edit like this ;-)

One feature that I do need to add though, is a "snap to 00:00.00" feature.

Cheers,
Jason

-- 
Jason Wood
Homepage : www.uchian.pwp.blueyonder.co.uk