On Tue, Feb 08, 2005 at 01:42:05 +0100, Didier Dambrin wrote: > >I dont know how slow you think local IPC is, but were talking microseconds > >here. ie. tiny fractions of the screen refresh time. > > > > really? Under windows? From my tests it was more at the millisecond level. I dont think it can be that high. I've use remote desktop to windows machine in th epast and it was no where near as slow as milisecond roundtrips would suggest. If window's IPC performance really is that bad (3 orders of magnitude worse than UNIX is hard to belive) then windows hosts will have to stick to running the UI from a different thread, unless they want to use hardware/external acceleration, when the UI will be a bit sluggish. I dont accept that we should cripple the GMPI specification, even if one target OS underperforms so badly. Each host could have the choice of how it wants to implement the comms (potentially), so in your case you can use inter thread comms, and people who know the windows IPC APIs better can use inter-process. > Yes, tiny fraction of refresh time, BUT whatever the user tweaks is > supposed to alter the AUDIO process, and this should be done ASAP, not with > an added latency. Changes can only take effect at block boundaries anyway. > And the huge wasted CPU is still a problem. There is no huge wasted CPU. - Steve ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe