🔒 Locked

DefWindowProc

Started by walkingcarcass Nov 30, 2002 at 8:54 AM 19 replies 1.3k views

Original Post

Nov 30, 2002 at 8:54 AM

i sincerely doubt, with all the zillions of messages flying around windows, and given the efficiency of other API functions, that DefWindowProc is fast. i wrote a test program that wrote a char to a file at each and every message. the program sat there aas the only running app, doing nothing for a short while. it printed hundreds upon hundreds of characters. after rough calculation, there must have been thousands of cycles per second lost to this invisible hoover. what if someone just wants an idle fullscreen window that sits there and is used by D3D or OGL for painting. it responds only to quit, destroy, power emergencies, screensaver requests, and losses of focus to signal a pause() is needed. no handling mouse movements, window resizes, etc etc etc having looked through the SDK reference, there are a lot of functions that can safely return 0 having done nothing. in DefWindowProc they make calls to cursor functions etc. you can''t return 0 on everything because the program hangs. has anyone written an ultra minimalist DefWindowProc which responds to only the most critical messages? ******** A Problem Worthy of Attack Proves It''s Worth by Fighting Back

elendil67

Nov 30, 2002 at 2:55 PM

You could just do something like this:

  
LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    return MyDefWndProc(hWnd, msg, wParam, lParam);
}

int MyDefWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    switch(msg)
    {
    case blah:
    }
}

Judging from what you want, you could simply write it yourself▬you realize that you only need to handle about six messages or so.

[code matrix]

niyaw

Nov 30, 2002 at 3:48 PM

quote:
Original post by walkingcarcass
has anyone written an ultra minimalist DefWindowProc which responds to only the most critical messages?

no, because it's not needed. when you're using directx for everything, there are no messages sent to your window, and defwindowproc isn't called at all.

<edit> you will also break upward compatibility with future versions of windows by avoiding defwindowproc, which is a bad thing. not to mention that there are private messages flying around that you generally have no idea how to handle. </edit>

this is also the reason why using high-level frameworks, such as atl/wtl/mfc, doesn't really affect your framerate once the game is running -- their code isn't executed!

[edited by - niyaw on November 30, 2002 4:50:14 PM]

walkingcarcass

Author

walkingcarcass

Dec 1, 2002 at 9:27 AM

say i was using opengl and i don''t get the directX benefit of fewer messages, there may be a small benefit by ignoring cosmetic messages, or notifications of other threads denying screensavers etc. what are the few critical messages which must be responded to?

********

A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

niyaw

Dec 1, 2002 at 9:39 AM

i told you: by avoiding defwndproc, you're breaking forward compatibility with future versions of windows, and your code may break even on existing versions of windows on another computer because of some important message you didn't know of. don't do it.

you're optimizing the wrong thing. replacing defwndproc with something homemade won't increase your fps. better improve your game code.

[edited by - niyaw on December 1, 2002 10:40:13 AM]

walkingcarcass

Author

walkingcarcass

Dec 1, 2002 at 10:17 AM

i don''t expect a noticable increase in performance, i really am just curious. are there some undocumented messages?

********

A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

niyaw

Dec 1, 2002 at 10:21 AM

1) registered messages
2) are you still not getting upward compatibility?

Evil Bill

Dec 1, 2002 at 11:01 AM

niyaw:

quote:

no, because it''s not needed. when you''re using directx for everything, there are no messages sent to your window, and defwindowproc isn''t called at all.

Is that because of DirectInput? Or has it something to do with Direct3D / DirectDraw taking exclusive access of the display?
So does this mean that in a fullscreen (it''ll be different for a windowed app, surely?) DX app, you don''t need a message pump?

S1CA

169

S1CA

Dec 1, 2002 at 1:34 PM

The only messages you''ll be passing on to DefWindowProc are those which YOU have passed to DispatchMessage() in your pump.

You''ll notice "filter" parameters for things like GetMessage() so that you can simply ignore certain sets of messages which you aren''t interested in.

With GetQueueStatus() you can snoop on the queues (there are multiple message queues of different priorities attached to each thread in a process), this could be used in cunning ways to only check certain types of messages.

Most of the messages you''ve been getting are probably simple input ones such as the current mouse status.

In general though, although you might get lots of messages, it usually isn''t worth worrying about unless its causing visible stutters.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

niyaw

Dec 1, 2002 at 11:32 PM

quote:
Original post by S1CA
You''ll notice "filter" parameters for things like GetMessage() so that you can simply ignore certain sets of messages which you aren''t interested in.

won''t this kind-of leak memory because the unprocessed messages will be stuck in the message queue, which will be constantly growing?

Oluseyi

526

Oluseyi

Dec 1, 2002 at 11:46 PM

quote:
Original post by niyaw
won''t this kind-of leak memory because the unprocessed messages will be stuck in the message queue, which will be constantly growing?

Such messages are either discarded or handled by the OS.

Barn Door

Dec 3, 2002 at 2:22 AM

quote:

no, because it''s not needed. when you''re using directx for everything, there are no messages sent to your window, and defwindowproc isn''t called at all.

How does windows know that it shouldn''t send or post messages when an app is using DirectX?

quote:

The only messages you''ll be passing on to DefWindowProc are those which YOU have passed to DispatchMessage() in your pump.

What about the nonqueued messages which Windows sends directly to the Windows procedure thus bypassing the message pump and any filtering?

BD.

niyaw

Dec 3, 2002 at 4:05 AM

quote:
Original post by Evil Bill
Is that because of DirectInput? Or has it something to do with Direct3D / DirectDraw taking exclusive access of the display?

i presume both. basically, i had an mfc-based application that apparently used gl for rendering (a plugin system, driver exe loading plugin dlls referencing core d3d/gl/di kinda thing), and what i did was i overrode wndproc in my window class and before passing all messages to mfc's wndproc i logged them using outputdebugstring(). it turned out that my app was receiving messages during init and shutdown, as one might expect, but positively no messages in between (app was running for about half a minute). [edit] it was actually a windowed app, but i didn't move the window around or anything. [/edit] dinput apparently takes over keyboard completely (dx docs also mention this; a side effect is that you don't get the mouse cursor in exclusive mode because windows doesn't get any input at all), and d3d/gl manage to render scenes without using any messages.

quote:

So does this mean that in a fullscreen (it'll be different for a windowed app, surely?) DX app, you don't need a message pump?

not really, you still need to process messages during init/cleanup, and you may want to know about some events happening such as computer going to powersaving mode.

quote:
Original post by Barn Door
How does windows know that it shouldn't send or post messages when an app is using DirectX?

i think that dx takes over hardware completely, bypassing windows services and providing you with direct access to hardware (kinda explains its name). so windows just doesn't get anything from hardware, and it doesn't have anything to give to your app.

[edited by - niyaw on December 3, 2002 5:06:21 AM]

Evil Bill

Dec 3, 2002 at 6:49 AM

Cool, thanks

walkingcarcass

Author

walkingcarcass

Dec 3, 2002 at 8:25 AM

i never understood the message filtering, the paramater names suggests you request messages only within a certain range ie you couldn''t order windows to send eg WM_QUIT, WM_DESTROY, WM_PAINT and WM_POWERBROADCAST exclusively

the discarded messages can''t go unhandled, some are critical, so i expect they get sent directly to DefWindowProc.

if directX prevents eg keyboard and mouse messages from being sent, fine. anyway, they are a few of dozens which can be quickly and safely handled with an "else return 0".

GetQueueStatus is a bit useless, it tells you what messages are unhandled. it is there, i suppose, for a program to prepare for the arrival of certain messages.

still, the crucial question is "WHAT IS THE SMALLEST SET OF MESSAGES WHICH HAVE TO BE HANDLED IN A STABLE PROGRAM?"

another crucial question is "which messages need a nonzero return value?"

the point being, we should need a handful of messages to process, and everything else returns zero without doing anything.

this set of mandatory messages is extremely unlikely to expand between windows versions, older apps which handle some manually may conflict with new standards.

********

A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

Evil Bill

Dec 3, 2002 at 8:40 AM

(2nd attempt: bloody HTTP500 errors...)

quote:

still, the crucial question is "WHAT IS THE SMALLEST SET OF MESSAGES WHICH HAVE TO BE HANDLED IN A STABLE PROGRAM?"

I''m sure this isn''t what you want to hear, but in a *stable* program, you want to handle them all. There won''t be a noticable slowdown (unless for some reason your app is recieving zillions of messages)

quote:

another crucial question is "which messages need a nonzero return value?"

Check the MSDN for WM_* messages and see what the return value should be. It varies from message to message. This is yet another reason for having DefWindowProc().

davepermen

160

davepermen

Dec 3, 2002 at 9:00 AM

i''ve logged all my messages in my opengl application. i have one window, with opengl in. no exclusive mode, nothing. plain win32.

i get:
mousemove
mousemove
mousemove..
tons of mousemove
some button press down
some button press up
mousemove..

etc..

there are _NO_ other messages going on over 99.999% of the time in my windows program. but if there are, and i don''t know them, guess what i do? return DefWindowProc. it does not hurt performance, but it saves me from any troubles.

oh, and who knows, possibly defwindowproc is different per windows? and guess what? it _IS_ different in different os. => you should use it, as its a blackbox.

"take a look around" - limp bizkit
www.google.com

niyaw

Dec 3, 2002 at 11:39 AM

quote:
Original post by walkingcarcass
still, the crucial question is "WHAT IS THE SMALLEST SET OF MESSAGES WHICH HAVE TO BE HANDLED IN A STABLE PROGRAM?"

another crucial question is "which messages need a nonzero return value?"

why are they crucial?

quote:

the point being, we should need a handful of messages to process, and everything else returns zero without doing anything.

that''s what defwindowproc is doing, except when a message requires freeing a memory block or releasing some other resource.

quote:

this set of mandatory messages is extremely unlikely to expand between windows versions, older apps which handle some manually may conflict with new standards.

since you have no idea what that set is, you don''t know whether that set will expand in future versions of windows.

will you listen to every post made by other people in this thread and spend your time optimizing something that will make a difference? you won''t get any performance improvement by replacing defwindowproc with something you wrote, as davepermen and me demonstrated, but you are asking for trouble by not using the windows implementation when you should.

do you realize that optimizing a function that is not called during most of your program execution is not going to make a difference in how fast your program runs?

walkingcarcass

Author

walkingcarcass

Dec 4, 2002 at 3:51 AM

ive said it before and ill say it again: i''m not asking for the sake of speed, i''m not a mindless slave to optimising, i''m just curious.

to hell with it, this is going nowhere. don''t bother posting any more.

********

A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

davepermen

160

davepermen

Dec 4, 2002 at 4:31 AM

okay. just to clarify

DefWindowProc (and the other ones for other type of windows), is a function _POINTER_ to a function in the _CORE_ of windows. even an old window app gets the pointer to a new defwindowproc. and due that fact, it''ll use the correct one.

you _can''t_ know what defwindowproc has to do, because this depends on operating system and sometimes even on installed programs. so you can''t replace it. you would have to update your own function for each operating system.

DefWindowProc does the right thing. you can _never_ know what that is. so you have to use it to do the right thing.

i know this by having tried the same you did. dropping DefWindowProc..

never again:D

"take a look around" - limp bizkit
www.google.com

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.