Am Samstag, 26. Oktober 2002 00:05 schrieben Sie: > On Friday 25 Oct 2002 10:10 pm, Christian Berger wrote: > > I personaly doubt moving an image around in memory is _THAT_ > > consuming. Just think of that Sinclair guy, he moved images around on > > a Z80 50 times per second. > > If we considered PAL, at 720x576 at 25 fps, then we are looking at > copying between 20 and 40 Meg to the screen per second, depending on the > color depth of the screen.
Well but I doubt many systems can do a preview of the cut at _THAT_ speed. What might be more important here is to have exactly the right image. If you use overlay, the overlay might lag behind a frame or two. > However, if we were to copy data from the Cutter to the GUI, then the > problems that arise are due to context-switching. We would have to > consider looking at the Cutter as a seperate thread rather than as a > seperate process. Well this wouldn't probably work without integrating the cutter a lot more tightly. > I don't like the idea of threads for a number of reasons : Firstly, if > the Cutter crashes, it will take the GUI with it. Secondly, we would > still have to allow the Cutter to run as a seperate process so that it > could be run remotely or for batch processing anyway. Thirdly, it would > really screw up my idea of having a scheduler for multiple cutters > distributed on multiiple computers ;-) Well first of all if we programm propperly, the cutter won't crash. But I completely agree with the other 2 arguments. However that's why I was suggesting the cutter to anounce it's posibilities. If the cutter completely runs over network it might only offer the frames or might even just display frames on a seperate display. > Cheers, > Jason Servus Casandro -- Warning! (this is no commercial ad) This e-mail probably will be read by secret services. Therefore please get pgp or gnupg and send me your public key so we e-mail encryptedly. http://www.gnupg.org/
