[Kdenlive-devel] scenelist
Rolf Dubitzky
dubitzky at pktw06.phy.tu-dresden.de
Sun Dec 1 17:02:55 UTC 2002
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).
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 ;-)
> 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. 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.
--
Cheers,
Rolf
***************************************************************
Rolf Dubitzky
e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************
More information about the Kdenlive
mailing list