Multi-threaded graphics
-
Using VC7/MFC I have a dialog app that has a seperate thread to handle animation. How can I do a lock so that I can update a back buffer(double-buffering) between the main thread and the graphics thread. When I try to lock in the main dialog it freezes which I think is being caused by the message pump being stopped by the lock in the thread. Any ideas as to the proper (and hopefully easy) way to handle multi-thread screen updating? Thanks
-
Using VC7/MFC I have a dialog app that has a seperate thread to handle animation. How can I do a lock so that I can update a back buffer(double-buffering) between the main thread and the graphics thread. When I try to lock in the main dialog it freezes which I think is being caused by the message pump being stopped by the lock in the thread. Any ideas as to the proper (and hopefully easy) way to handle multi-thread screen updating? Thanks
-
Using VC7/MFC I have a dialog app that has a seperate thread to handle animation. How can I do a lock so that I can update a back buffer(double-buffering) between the main thread and the graphics thread. When I try to lock in the main dialog it freezes which I think is being caused by the message pump being stopped by the lock in the thread. Any ideas as to the proper (and hopefully easy) way to handle multi-thread screen updating? Thanks
Off the top of my head, put a critical section in both the back buffer drawing routines and the main drawing routine. Another common method is to create two back buffers and ping pong between them using a BYTE index (which is always atomic) to indicate which buffer is active for painting in the foreground and drawing in the background.
-
Off the top of my head, put a critical section in both the back buffer drawing routines and the main drawing routine. Another common method is to create two back buffers and ping pong between them using a BYTE index (which is always atomic) to indicate which buffer is active for painting in the foreground and drawing in the background.
Tried the critical section but when it tries to lock in the main thread, everything hangs for some reason. I think the message pump may be getting blocked. Used critical sections a lot in my server code and they work great. For some reason it doesn't seem to want to cooperate with graphics routines.
-
Tried the critical section but when it tries to lock in the main thread, everything hangs for some reason. I think the message pump may be getting blocked. Used critical sections a lot in my server code and they work great. For some reason it doesn't seem to want to cooperate with graphics routines.
I'm going to guess you have one path in the thread which doesn't release the critical section. If that doesn't work, try running around your office screaming and waving your arms in the air.:)
-
I'm going to guess you have one path in the thread which doesn't release the critical section. If that doesn't work, try running around your office screaming and waving your arms in the air.:)
-
Using VC7/MFC I have a dialog app that has a seperate thread to handle animation. How can I do a lock so that I can update a back buffer(double-buffering) between the main thread and the graphics thread. When I try to lock in the main dialog it freezes which I think is being caused by the message pump being stopped by the lock in the thread. Any ideas as to the proper (and hopefully easy) way to handle multi-thread screen updating? Thanks
Messages for a window can be processed only by the thread that created the window. That's how message pumps work. Designing you code so that another thread updates the UI will likely result in other problems (or at the very least, inefficiencies when the threads have to wait on each other). But sticking with your question, if the worker thread is the only one touching the back buffer, why do you need a lock at all? --Mike-- THERE IS NO THERE IS NO BUT THERE IS MAGIC PIXIE DUST BUSINESS GENIE CODE PROJECT Homepage | RightClick-Encrypt | 1ClickPicGrabber "You have Erica on the brain" - Jon Sagara to me
-
Messages for a window can be processed only by the thread that created the window. That's how message pumps work. Designing you code so that another thread updates the UI will likely result in other problems (or at the very least, inefficiencies when the threads have to wait on each other). But sticking with your question, if the worker thread is the only one touching the back buffer, why do you need a lock at all? --Mike-- THERE IS NO THERE IS NO BUT THERE IS MAGIC PIXIE DUST BUSINESS GENIE CODE PROJECT Homepage | RightClick-Encrypt | 1ClickPicGrabber "You have Erica on the brain" - Jon Sagara to me
-
Thanks for the info. The back buffer is processed by the paint routine in the main thread as well. What's the best way to handle multi-threaded graphics to a dialog window?
-
lol tried both. The screaming worked better than the critical section. I checked all the paths, only use it in one place in each thread. Had that happen before so it was the first thing I thought to check. Very perplexing problem.
Yes, but was it a manly scream or a high-pitched girly scream? I've found that only high-pitched girly screams help with threading problems. Seriously though. Could you post some of your code?
Software Zen:
delete this;