Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Fullscreen and WM_PAINT


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 The C modest god   Banned   -  Reputation: 100

Like
Likes
Like

Posted 07 October 2003 - 11:11 PM

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?

Sponsor:

#2 FenrirWolf   Members   -  Reputation: 288

Like
Likes
Like

Posted 08 October 2003 - 08:08 AM

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

#3 madman_k   Members   -  Reputation: 122

Like
Likes
Like

Posted 08 October 2003 - 11:35 AM

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.

#4 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 08 October 2003 - 12:49 PM

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.

#5 Donavon Keithley   Members   -  Reputation: 328

Like
Likes
Like

Posted 08 October 2003 - 02:56 PM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS