On Monday 28 October 2002 05:46 pm, Christian Berger wrote: > Am Montag, 28. Oktober 2002 16:32 schrieben Sie: > > On Monday 28 Oct 2002 10:29 am, Rolf Dubitzky wrote: > > I'm not so sure about the GUI being a GStreamer app - mostly, I guess, > > because I don't want to tie the program too tightly to any framework > > untill I know that it is the right framework. > > True
I agree too, but ... > > I do not believe that there will be a significant (as in noticeable to > > the user) performance penalty for having communication through seperate > > threads, but if I turn out to be wrong, I am coding so that the details > > of the interface should be hidden from the cutter itself. E.g. all of > > the client/server code is in a base class which you then inherit and > > fill in a couple of functions. In the case of GStreamer, that would > > simply mean putting the GStreamer rendering code within this class. > > Well maybe we can issue a command to the cutter giving it the display > number as well as where to put it's window and the cutter might then (if > it can) display it's own window directly to the screen. ... I don't like the cutter to know about any kind of display. He would need to know Xv/FrameBuf/GL/younameit. So there _needs_ to be a interface. I agree however that relying on GStreamer is probably not the right thing, but I have a very strong opinion agains everybody brewing his own beer. I will for sure use GStreamer in my engine to benefit from it's input streams and and it's filters. Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ ***************************************************************
