GDI -painting from another thread

[Giuliano Suminsky]

I have that window with keeps some rects drawed(static) on the client
area, when I press start(WM_COMMAND), a thread is created within a
simulation model start to execute.
This simulation draws little ellipses ( width 5 ) inside the rects, at
each loop, witch means that they are not static, each loop a ellipse
can disappear or appear in different rects, multiple ellipses can
exist..

The proble is that I dont know a efficient way to make this, I tried:

loop{

InvalidateRect();//the original thread will draw the rects at
WM_PAINT, cleaning the ellipses( like a directX clear )

draw the ellipses here;

...
}
That produces odd results, is too much updates and the rects suffers
flickering, but the result is the expected...

Whats the best approach I should take? What applications like that
usally do to solve this?(maybe Im doing stupid )

[ScottMcP [MVP]]

Drawing from a secondary thread will greatly slow down that thread.
Any time it does anything to the window the secondary thread is
stopped and the drawing is actually done in the primary thread.

It is best to do all drawing in the primary thread. The secondary
thread can use PostMessage to the primary window to request updates.
The updates are done in the message handler in the main thread. (Use
a custom message, WM_APP + n).

Flicker is an unrelated issue. To avoid flicker you can use an
offscreen buffer for painting and blit it to the screen.

[Giuliano Suminsky]

"Any time it does anything to the window the secondary thread is
stopped and the drawing is actually done in the primary thread. "

Why the thread is stoped? Im using InvalidateRect so the primary
thread will eventually do the paint, in the secondary thread I have
get a dc ( not using OWNDC neither CLASSDC ) with allows the thread to
paint on the specific window..
I dont get it..

[ScottMcP [MVP]]

Every window is associated with one thread, because that thread's
message queue is where Windows sends its messages. When you do
something from another thread Windows makes the operation thread-safe
by suspending the calling thread, than calling the window's wndproc
(in the main thread). This makes sure the window is not accessed
concurrently.

The MSDN page for SendMessage says this: "The SendMessage function
sends the specified message to a window or windows. It calls the
window procedure for the specified window and does not return until
the window procedure has processed the message." Where it says "does
not return" it means the calling thread is blocked.

[Giuliano Suminsky]

I knew all that you just described, but I still dont get why the
thread will be stoped since Im not(at any time) waiting for the
primary thread do something ( not using anything like sendmessage );
Where in my code the thread will wait for the main thread?
Each thread has its own hdc, for the same window( with allows
painting operations at any time ), I dont see when my secondary thread
needs the wndproc..The only problem I suppose can happen is race
condition between "who draws first"...

[ScottMcP [MVP]]

On Nov 16, 7:44 am, Giuliano Suminsky <yksni...@gmail.com> wrote:
> Where in my code the thread will wait for the main thread?

Windows serializes the painting calls. Every painting call from the
secondary thread will block, and Windows will call the wndproc in the
main thread context.