Fullscreen and WM_PAINT
Author
Do you work with WM_PAINT in full screen? or do you work around it?
Does your main render inside window procedure under MS_PAINT or is it outside in a different loop?
What is the better way of drawing with fullscreen?
I wouldn''t work with WM_PAINT at all, if I had my choice. Why can''t you just render your frames when you''re not actively handling any messages?
while (do_message_pump()) {
render_frame() ;
}
WM_PAINT is only sent to the application when Windows thinks it''s necessary for it to redraw itself. So, your app isn''t getting WM_PAINTs all the time, just when you min/maximize it or some other window occults it.
---
http://www.gapingwolf.com
while (do_message_pump()) {
render_frame() ;
}
WM_PAINT is only sent to the application when Windows thinks it''s necessary for it to redraw itself. So, your app isn''t getting WM_PAINTs all the time, just when you min/maximize it or some other window occults it.
---
http://www.gapingwolf.com
yeah, DefWndProc() just revalidat6es your window for a WM_PAINT message, and thats all your directX program should do for the message. the method suggested by FenrirWolf is the only way i ahve seen directX programs handle rendering, because it just makes sense.
the above posters are assuming you''re creating an app that needs to be rendered over and over at some high rate of speed. that assumption is not always correct. for instance, WM_PAINT processing works fine for apps that are fairly static in nature and depend upon some external event (user interaction, timer, etc.) to cause re-rendering. this could easily be handled by an InvalidateRect call which would then lead to the WM_PAINT message. there''s a fairly large number of games and graphics-based apps which don''t require this constant updating.
a good example is a 3D board game of chess i wrote. the renders on slower boxes yield only around 4-6 fps due to the amount of eye candy. if i were to use a render loop for this app then the in-game menuing system would be completely unresponsive, plus unnecessary cpu cycles would be wasted that could go instead to the chess board solver.
a good example is a 3D board game of chess i wrote. the renders on slower boxes yield only around 4-6 fps due to the amount of eye candy. if i were to use a render loop for this app then the in-game menuing system would be completely unresponsive, plus unnecessary cpu cycles would be wasted that could go instead to the chess board solver.
There is a nice trick where if you don''t call BeginPaint/EndPaint in your WM_PAINT handler, the window will remain invalidated and you''ll receive a continuous stream of WM_PAINT messages whenever there are no other messages to handle. (And as madman_k says, don''t call DefWindowProc either.) So you can use the classic GetMessage/TranslateMessage/DispatchMessage message pump. It''s nearly the same as using a PeekMessage pump and rendering when the queue is empty. By not calling BeginPaint you also save yourself from those pesky WM_ERASEBKGND messages.
I believe that calling InvalidateRect after handling WM_PAINT would have essentially the same effect of giving you a continuous stream of WM_PAINTs -- in case you really need a PAINTSTRUCT.
I like this trick. Whenever I create a new Win32 app via the Visual Studio app wizard all I have to do is comment out those two lines, I don''t have to rewrite the message pump.
I believe that calling InvalidateRect after handling WM_PAINT would have essentially the same effect of giving you a continuous stream of WM_PAINTs -- in case you really need a PAINTSTRUCT.
I like this trick. Whenever I create a new Win32 app via the Visual Studio app wizard all I have to do is comment out those two lines, I don''t have to rewrite the message pump.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement