Multi-threaded image capture in Direct2D

CK: So I have the whole “bitmap capture” and export solution in place. It works fine. But I want to verify my solution with you. I went with the split solution, where the rendering thread does everything up to the copy from (GPU) target bitmap to CPU-readable bitmap. It then posts the readable bitmap to the main thread (via post message) and never touches it again.

When the main thread handles the bitmap capture message, it does the map, and then does all the WIC stuff, writing the image to disk. It then commits, unmaps, releases the bitmap pointer, and that’s all.

This is a handy division of labor, because the map operation is what actually copies the image from GPU to CPU memory, and that part can be quite slow. So it’s very convenient that that’s occurring on the main thread’s time, because that way it doesn’t disrupt rendering.

My understanding is that this scheme does comply with the COM rules. If I use COM without enabling multi-threaded mode, then I am responsible for preventing race conditions. In other words, I am responsible for ensuring that any given COM instance is accessed by one and only one thread at any given time.

My scheme certainly ensures that. As I said, once the render thread posts the bitmap, it never touches it again. The simple fact of queuing via the windows message loop ensures there is no possibility whatsoever for a race.

Do you agree with the above?

The mere fact that the scheme appears to work proves nothing of course, with multi-threading we must be on sure footing conceptually.

ChatGPT o1: Yes, your handoff scheme should be perfectly valid under Direct2D/COM’s single-thread concurrency rules, as long as:

1. The render thread never touches the CPU-readable bitmap object again after posting it to the UI thread.
2. The UI thread fully “owns” that object from that point on (maps it, does WIC, unmaps, releases).

That ensures there is no concurrent access at all—exactly what COM’s single-thread apartment model expects. Below is a bit more detail on why it’s safe:

1) COM Single-Thread Rules

• In default (STA) COM: Each COM object instance is associated with the thread that creates it, and is not automatically “marshaled” to other threads.
• However, Direct2D and DXGI objects are somewhat “special.” They aren’t strictly STA for all their internal logic, but the official stance is that any one ID2D1 object is not guaranteed to be thread‐safe. So if you want to pass it across threads, you must ensure there’s no overlapping usage.

Your usage pattern is:

1. Render thread calls CreateBitmap(..., CPU_READ | CANNOT_DRAW), then does CopyFromBitmap(...).
2. Render thread posts the resulting ID2D1Bitmap1 * to the UI thread via a Windows message.
3. Render thread never touches that bitmap pointer again.
4. UI thread receives the message, does Map(...), WIC encode, Unmap(), Release(), etc.

No concurrency occurs. Each piece of code “owns” the bitmap at different times, with no overlap.

2) Typical Precedent in D2D/DX

• This pattern is quite similar to a “CPU readback” approach in D3D, where you create a staging resource on one thread, then pass it to another for final saving. The key is that only one thread interacts with that resource at a time.
• The D2D docs mention that ID2D1Bitmap1 is not thread‐safe, but it’s fine if you exclusively access it from a single thread (the UI thread), after you’re done setting it up on the render thread.

3) The Windows Message “Boundary”

Posting a pointer in a WM_USER + X message is a classic way to pass COM pointers between threads. Since your render thread is done with that pointer, the UI thread can safely do Map(...) and so on. The Win32 message queue ensures a “happens-before” relationship—by the time the UI thread processes that message, the render thread has finished. That eliminates any race condition concerns.

4) Summary

Yes, the fact that you see it “working” is consistent with being on correct conceptual footing: you are ensuring that once the resource is handed off, only the UI thread uses it. That’s exactly the recommended approach for single-thread concurrency in Direct2D/COM. You avoid stalling your render loop (the slow disk I/O or GPU→CPU copy occurs on the UI thread’s time) and you keep the concurrency model simple.

So, your scheme is indeed safe and correct for the reasons you outlined. Nice work!