[Kdenlive-devel] scenelist

[Jason Wood]

On Sunday 01 Dec 2002 5:02 pm, Rolf Dubitzky wrote:
> On Sunday 01 December 2002 05:19 pm, Jason Wood wrote:
> > > > > I am not yet convinced that this XML via loopback is the right way
> > > > > to do it.
> > > >
> > > > Well, we are getting close to the time when we find out, I think :-)
> > >
> > > Are you working on the nullcutter, or should I start looking into the
> > > SAX/thread thing?
> >
> > At the moment, I am more interested in writing the Kdenlive side of the
> > communication than the server side, probably because I am eager to get to
> > a point where we can say "here is Kdenlive Version 0.x, Here is Piave
> > version 0.x, download them and enjoy" :-)
>
> Ok, that's fine. I just wanted to make sure that we are not working on the
> same part ;-)
>
> > The other point is that I am a little concerned about the scene
> > generation at the moment. I was expecting a small performance hit for
> > transfering across the network (and I believe that this is just a small
> > performance hit), but I wasn't expecting the generation of the entire
> > scene list to be _quite_ as slow as it is at the moment :-)
>
> This whole communication thing adds at least a lot of programming overhead.
> For each feature you have to implement a command here and parse a command
> there, insead of just call a function where you need it. It would be _much_
> easier if we would just link kdenlive agains libpiave and abstract the
> communication part in a class with network and XML transparancy in mind
> (but not yet implemented).

The entire communication process is already abstracted inside Kdenlive by the 
KRender class - as far as any other part of Kdenlive is concerned, the 
KRender object is the renderer.

So from my perspective, it would be fairly straight forward to link to Piave 
instead of using the network - but I really think it is important to get the 
general case working before we "optimise".

> Are you going to reuse all the work what went into this communication
> protokoll when saving prjoct files? If so, I might be wrong and the time
> might not have been wasted ;-)

Drag'n'Drop works via XML, the project is saved using XML (yes, you can 
already save your timeline if you so desire - but you can't load it back in 
yet ;-)

Not all of the XML is reused, but for most of the VEML commands take only 4 
lines of code to create and send anyway. And whilst the SAX code is 
annoyingly long winded, it does automatically mean that the KRender class 
supports asynchronous communication - so Kdenlive doesn't wait around when 
you add a file waiting to find out how long it is.

> > I think it may be necessary to add a new command "updateSceneList" which
> > only transmits the modified sections of the scene list, rather than
> > transmitting it fresh on each generation.
>
> Well, as I seaid, it would be _much_much_ easier if you could directly
> update the render tree in memory, rather than send commands ;-)
> Later, when we want to render in batch, it's not a problem, then you can
> send XML via network because you don't have to do it very often, just once
> before the process starts, but for the interactive part ... it just feels
> clumsy to me.

It works for X11 ;-)
(I think I should add that I have only just thought of that comparison - I'm 
not basing the entire design on the fact that if it's good enough for X, it's 
good enough for us ;-))

I don't know, at least for seeking around, I have not noticed any latency 
other than what I would expect given that Piave is not dropping seek 
commands.

The setSceneList command is in it's current state, a problem simply because it 
is an expensive command that is going to be called a lot at the moment. I 
think an updateSceneList command would make sense.

> Anyway, that's the way we go and I might be prooven wrong
> after I implemented the skipping of skippable commands in the queue and we
> have a more effcient way to transport the timeline at each modification.
> Actually the latter might really be a showstopper.

Without an updateTimeline command, it is a showstopper if you try and edit 
something with more than about 20 clips at the moment :-) However, that is 
because kdenlive is regenerating the entire timeline list from scratch when 
it could get away with modifying one or two scenes - it's a slow operation 
network transparency or not.

Optimising the scene generation is my next priority, it should be possible to 
get the current method from approximately 20% of the entire programs runtime 
down to practically nothing, I think :-)

Cheers,
Jason

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