Hi Gerrit, Gerrit Voss wrote: > On Wed, 2009-02-11 at 09:34 +0000, Christoph Schmidt-Hieber wrote: >> I've written my own interfaces and options classes as you suggested for >> my custom device. This works very nicely on a dual core machine and was >> very straightforward to implement. Thank you very much for your nice >> framework. >> Using the same code on a single-core PC, the input from the custom >> device is correctly read, but it doesn't move the scene any more >> (although Hyperthreading is enabled). I suppose that's a problem with >> the threading? > > hmm that is strange it should actually work on a single core pc. > >> Would it be possible to use the dual core PC as a server that processes >> the input from the custom device, and the single core PC as a client >> that does all the rendering? If so, what would be a good starting point >> to learn how to do that? Or would it be easier to modify the threading >> part of the existing EventMouse code so that it works on single core >> machines? > > I would actually try make the code run on a single core. I'm pretty sure > a very similar implementation works on single core machines with > threading, so something seems odd. > > Ok, I guess the problem is to work with relative values from the device > interface and accumulate in the outer OpenSG layer. That might only work > if the threads run reasonable parallel but has a good chance of failing > on a single core machine. I'll see if I can move the accumulation part > into the device interface so that the outer OpenSG layer can grep the > accumulated transformation values instead of the relative device values.
Can't follow you exactly, but it sounds like a reasonable thing to do ;-). Let me know if I can be of any help. Thanks, Christoph ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
