On a related note, can someone elaborate on the performance of using sockets. I would assume given that it's on the same machine that there wouldn't be that big of a performance hit. Especially if the data being passed was done in big chunks to avoid the overhead of whatever protocol was being used.
I know it's not the point of the article, i am just wondering about it for curiosity's sake.
It's the serialization/deserialization that gets you. And not just the actual transformation, but also the fact that you have to turn every operation into some message. What could be a fast loop to read/modify/write the bytes in some rectangle in video memory, now has to read all those bytes into a flat buffer, do the modify (probably with extra code because the layout of the mask and the layout of the buffer are no longer compatible), send through the kernel, and then get unpacked and written to video memory in the other process. For infrequent or batch jobs this might be a well-structured interface with some good robustness features. For user interfaces which should be low latency it takes 10-100x as long and for no actual benefit.
Also doing things in big chunks is more efficient, but usually adds latency.
It depends. Any IP-based socket will still go through some protocol stack (routing and filtering). On the other hand, unix domain sockets are optimized for IPC and should perform well. But any socket will require a copy, and thus be slower than shared memory.
On the other hand, if you are going to exchange json messages, you can stop worrying about socket overhead.
Even on the same machine using sockets is going to be much slower than function calls, or shared memory access. One of the criticisms of early X Windows system was its slow performance on local machines.
But the client-server design of X-Windows was quite deliberate. Makes me wonder if this CAD system had a similar pedigree? I think we’re only hearing half the story here.
Well, many systems do IPC and often this is done over sockets.
Maybe a better question is, in 2018 why don't we have much better, cleaner, simple, IPC?
If the system was slow due to this, it might have been the sheer quantity of data over the IPC/Socket. Looks like they were rendering on one side (i.e. 'making the picture') and then pushing that to a different process to rasterize, i.e. 'draw it on screen' which just seems a little crazy. I'd imagine this was probably due to some kind of legacy thing.
I think a common approach for IPC these days is to use named pipes. Chromium uses it and I've used it in one of my projects. You still have to deal with serialization and deserialization overhead but its usually pretty quick.
I know it's not the point of the article, i am just wondering about it for curiosity's sake.