Multithreading an Pixel-Drawing

Hello,
I come from another OS than Win32, and when it comes to graphics, I am a little bit confused by the event-driven design of the win-os.

what I want to do:
I want to compute an image, pixel by pixel in a another thread than the main-thread.
the image should be drawn in a window also pixel by pixel. this means, when a pixel of my image is computed it should be drawn to the window.

problem:
as I understood, drawing it is only possible in the WM_PAINT-handling of the window-procedure. therefore I am not allowed to use SetPixel in another thread. Or, to say it correctly, I am allowed to do this, but it doesnt result in the pixel to be displayed. am I right ?

a possible solution:
I compute the pixels for the image in a separate compatible bitmap/DC-combination. each time a pixel is computed I call SetPixel on the separate DC. then I invalidate the window-rect of the window. In the WM_PAINT-handling of the window I BitBlt the separate bitmap to the window-dc.

what I don't like about this:
I assume to be that solution to be awful slow, because for each little pixel a lot of system-overhead must be performed. especially BitBlt-ing the whole bitmap for each pixel.

my question to you:
is there a "smarter" way to perform the task ? what is the fastest way that you windows-profis know about doing such a work ? for short: what is your advise ? or do you mean I just can forget this ?

thank you for your help

highhead

You can call GetDC() at any time and call SetPixel() on the DC, even from another thread. The only reason this is usually frowned upon is that when the window needs to be redrawn (in response to WM_PAINT), those things that were done would be lost. So, applications are typically organized so that all drawing happens in response to WM_PAINT. However, this is not required, and is certainly not the best for intensive operations such as yours.

I would recommend that as you calculate pixels in a worker thread, SetPixel() to the window DC as well as to a memory DC. Then, in response to WM_PAINT, BitBlt() from the memory DC to the client area. This way, you get good performance, and the window can be redrawn correctly. You are essentially drawing directly to the window DC, but also "saving" the results for when redrawing is necessary.

There might be other methods, but this one is pretty reasonable.

[Moved thread]

Thanks,
I read about the possibility of GetDC late in the evening yesterday and thought this might be a good solution. But there was still the problem you mentioned, that the results will be lost at the next WM_PAINT.
Thanks for helping, because with the second DC and BitBlt only at WM_PAINT-Time, I think this is the optimal solution.

Thanks again

highhead

Quote:

---

Originally posted by Myself dot NET
You can call GetDC() at any time and call SetPixel() on the DC, even from another thread. The only reason this is usually frowned upon is that when the window needs to be redrawn (in response to WM_PAINT), those things that were done would be lost. So, applications are typically organized so that all drawing happens in response to WM_PAINT. However, this is not required, and is certainly not the best for intensive operations such as yours.

I would recommend that as you calculate pixels in a worker thread, SetPixel() to the window DC as well as to a memory DC. Then, in response to WM_PAINT, BitBlt() from the memory DC to the client area. This way, you get good performance, and the window can be redrawn correctly. You are essentially drawing directly to the window DC, but also "saving" the results for when redrawing is necessary.

There might be other methods, but this one is pretty reasonable.

---

Quote:

---

Originally posted by Andreas Masur
[Moved thread]

---

Hi andreas,
hmm if I had posted this in the multithreading-forum, it might have been moved to winapi, because it has much winapi related stuff inside.

look:multithreading is available and simmilar to (for example linux and win32). Event driven painting called WM_PAINT and so called DC's are only available at Win32.

So my opinion is, that my question is 80-90% Win32 related.

so why have you moved the posting

regards

highhead

ps: I'm very lucky that you moved my question after somebody answered me allready ;) otherwise there had been a good chance nobody answered because of "wrong forum" :D

Quote:

---

Originally posted by highhead
So my opinion is, that my question is 80-90% Win32 related.

---

Well...actually there would have been several choices...it is also a Graphics question. Nevertheless, since you are asking more about the Win32 I follow you and have moved it back...