Hi Jason, hi Christian, > On Wednesday 23 Oct 2002 10:14 am, Peter.Q at gmx.net wrote in thread: > http://lists.kde.org/?l=kde-multimedia&m=103537308631406&w=2 > > Essentially my idea has always been based upon the GUI and engine running in > seperate processes and communicating between each other. BUT before > everyone starts wailing and nashing teeth at how slow chucking > video from one process to another would be; the plan I have is that the > engine will display it's own video window, which will then be embedded into > the GUI. So no video will be passed from GUI to engine.
Ok, that is a must. You cannot pass any video data arround. > timeline and moving them around at least one at a time, and in some cases > multiple selections at a time (the code just needs finishing off to make it > work in all cases). As I mentioned above though, I was thinking that for seperation it makes > better sense to put the KVideoWidget into a simple window in the engine, Well, I think this is one of the points I meant, when I said that you will not be able to separate engine and GUI 100%. Putting a KVideoWidget into the engine is clearly not what I want. But that is not a real problem. Any two parts need a inteface layer. This layer will necessaryly depend on a specific GUI and on a specific render engine. I think that such a layer will not ruin a nice design. And btw you will need at leas two video windows. Ony in which you see the curent frame, maybe rendered in preview quality, maybe even with low quality, but HW accelerated versions of the effects, and another kind of window to preview subscenes that have already been rendered. My engine will be capable (not yet working) of using idle time to prerender parts of the production so that they can be quickly displayed. > and to then control it remotely. The most difficult bit of this will be > actually settling on the actual format of the communication. This communication will very much depend on the capabilities of the engine. E.g. I don't use a serial timeline. It's more like a tree. This is extremely efficient and easy to manage, but not vary convenient to visualize. Same is true for effects and transitions, actuall, in my engine there is not even a difference between the two. I use dynamic path effects, which can appear like transitions, or something else. It's a very nice concept I think. I just mention it to make clear, that the path nodes have to be visualized in the timeline which means, that it will be difficult to write a generic gui and a generic engine with a generic interface. On the other hand, you are right, there are a number of things basically every engine and every gui will have in common, but you probably don't want to restrict yourself to this common denominator. And then, may I ask about Christian Berger's engine? In which state is it? Are you two working closely together? I work together with a friend of mine who is doing the GUI stuff, I would like to try and convince him that we all work together, but I am not sure that'll work. He is not eager to work with Qt. Cheers P.S. Don't be puzzled about the e-mail. 'Peter' is a nick and an old alias, I use when mailing from home. *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ ***************************************************************
