Most efficient way to send images across processes

Question

Goal

Pass images generated by one process efficiently and at very high speed to another process. The two processes run on the same machine and on the same desktop. The operating system may be WinXP, Vista and Win7.

Detailed description

The first process is solely for controlling the communication with a device which produces the images. These images are about 500x300px in size and may be updated up to several hundred times per second. The second process needs these images to process them. The first process uses a third party API to paint the images from the device to a HDC. This HDC has to be provided by me.

Note: There is already a connection open between the two processes. They are communicating via anonymous pipes and share memory mapped file views.

Thoughts

How would I achieve this goal with as little work as possible? And I mean both work for the computer and me (of course ;)). I am using Delphi, so maybe there is some component available for doing this? I think I could always paint to any image component's HDC, save the content to memory stream, copy the contents via the memory mapped file, unpack it on the other side and paint it there to the destination HDC. I also read about a IPicture interface which can be used to marshal images. I need it as quick as possible, so the less overhead the better. I don't want the machine to be stressed just by copying some images.

What are your ideas? I appreciate every thought on this!

Answer 1

Use a Memory Mapped File.

For a Delphi reference see Memory-mapped Files in Delphi and Shared Memory in Delphi.

For a more versatile approach you can look at using pipes or sending bitmap data via TCP. This would allow you to distribute the image data between nodes more easily, if necessary.

Answer 2

Use shared memory to pass the image data, and something else (named pipes, sockets, ...) to coordinate the handover.

Answer 3

In some cases, you can pass HBITMAP handles across processes. I've seen it done before (yes, on XP/Vista), and was surprised as everyone else on the team when one of my co-workers showed me.

If memory serves me correctly, I believe it will work if the HBITMAP was allocated with one of the GDI function (CreateBitmap, CreateCompatibleBitmap,CreateDIBitmap,etc...) HBIMAP handles created by LoadBitmap will not work as it's just a pointer to an in-proc resource.

That, and I think when you share the HBITMAP across to the other process, don't try to do anything special with it other than normal BitBlt operations.

At least that's what I remember. We got lucky because our graphic libraries were already written to manage all images as HBITMAPs.

YMMV

Answer 4

As I can see this, you have two options:

1. Pass only the image handle / pointer to other process, so both processes work only on one collection of images.
2. Copy the image content to other process and work on a copy from then on.

Which approach is best depends on your design. Best tool for both approaches would be "memory mapped files", or "named pipes". This are the fastest you can get. Memory mapped files are probaly the fastest form of inter process communication but have the donwside that there is no "client-server" paradigm build into them. So you have to synchronize the acces to MMF yourself. Named pipes on the other hand are almost as fast but have the client-server paradigm build right into them. The difference in speed comes mainly from that.

Now because of the share speed of the updates, the first approach could be better, but then you have to watch out for synchronization between processes, so they do not read / write to single image at the same time. Also some sort of caching or other smart tehniques could be used, so you reduce your traffic to minimum. When facing such high level of communications there is always advisable to look for means of reducing that level if possible.

For a very fast implementation of IPC based on named pipes you can use my IPC implementation. It is message oriented so you do not have to worry about pipe technical details. It also uses thread pool behind the scenes and has mininal additional overhead. You can stress test it and see for yourself (a typical message takes 0.1 ms for full client-server request-response cycle).

Answer 5

Ok it seems as if memory mapped files and pipes are the right way to go. That is not too bad because the two processes already share a MMF and two pipes (for bidirectional communication). The only thing left to solve was how to pass the data with as little copy operations as possible.

The design which works quite well looks as follows (sequential flow):

Process 1 (wants image)

• give signal to process 2 (via pipe 1) to store image in shared memory
• go to sleep and wait for response (blocking read from pipe 2)

Process 2 (provides images)

• on signal (via pipe 1) wake up and tell hardware device to paint to HDC 1 (this is backed by shared memory, see below)
• give signal to process 1 (via pipe 2)
• go to sleep and wait for new job (via pipe 1)

Process 1 (wants image)

• on signal (via pipe 2) wake up and paint from shared memory to destination HDC 2

Now for the image transfer via shared memory (my goal was to use not more than one additional copy operation):

Process 2 creates a HBITMAP via CreateDIBSection and provides the handle of the file mapping and the offset of the mapped view. Thus the image data lives in the shared memory. This creates an HBITMAP which is selected into HDC 1 (which is also created by process 2) and which will be used from now on by process 2.

Process 1 uses StretchDIBits with a pointer to the mapped view's memory (as described here). This seems to be the only function for getting bits from memory directly into another HDC (in this case HDC 2). Other functions would copy them first into some intermediary buffer before you could transfer them from there to the final HDC.

So in the end it seems the bits needed to be transferred are about twice as much as in the beginning. But I think this is as good as it gets unless sharing GDI handles between processes would be possible.

Note: I used pipes instead of signals because I need to transfer some additional data, too.