I''m also sick of people claiming that MFC is slower than the Win32 API. I started off not using MFC becuase everyone said it was slower. Then I thought better of it, and am using it now. Here are the results: Hardware AMD K6-3 450MHz, CL Riva TNT, 128MB SDRAM Window Size: 300x400 pixels Polys: ~30,000 For the Win32API, Dx gets the hwnd from the main dialog window For the Win32MFC, Dx gets its hwnd from a CStatic window inside a derive class from a CDialog. Both compiled in release mode, optimizations for speed on. Win32API renders when there''s no msg''s. Win32MFC renders OnIdle(), always returns true. MFC Frame Rate while moving (dInput->Keyboard) and clicking on buttons & tabs & other MFC objects. Win32API just moving, since there''s no buttons or tabs. Frame Rate: Win32 API: 28.3fps //!PeekMessage() Win32 MFC: 27.4fps //OnIdle() no clicking Win32 MFC: 26.7fps //clicking... Well, I guess you do lose %3.18 of your frame rate... Yes I can accurately measure to 0.1fps. (How? See my thread on Frame Rate & digital filtering.) The performance impact of writing this message is 0.4fps. ... Anyone else ever run MFC vs Win32 API speed test? I''m curious if I made a api dialog box with a child window, if the frame rate would drop 1fps, just like the MFC version...

well, MFC cannot be slower if you don''d actually do anything with it.
5-10 buttons with clicking and mouse-moving etc. cannot take so much time that you would notice any difference.

but that changes when you come to interface coding, GUI stuff, windows, views, the whole shit... then MFC will(!) decrease performance!

the point in not using MFC in d3d/dd apps is that you don''t control over allocation/ freeing of resources (the window etc.) unless you override some functions that you would not have needed anyway. good example is OnClose().

next thing is you don''t need it for anything, it uses memory (well, not much as it is only mapped into your process''s space since it is used by other programmes anyway), and it can confuse you easyly - unless you are aware of what exactly MFC is, and you are doing. and of course it will increase your code-size.
even though much code is in an external .dll, it will. believe me. many inline functions, much stuff you don''t ever need, but is used by MFC, and so on.
will blow-up your app, no matter what you''re doing

besides, everyone is switching away from MFC, not to Win32 but to ATL which makes a lot more sense when going to app-developement. and i mean the ATL window classes, not the COM stuff.

but for games it really doesnt matter anyway.
have fun, have a nice day,

anyone without name

p.S.: MFC must (!) be slower than pure Win32 API, since it resides on top of it, doing some nasty stuff like processing messages you could ignore at all, takin care of things thant wouldn''t normally bother you, and ever so on. the only fast thing in/ with MFC is CString, which is on the other side not really part of MFC, since it doesn''t depent on the rest of the framework.

I don''t need to do speed tests I can just run my debugger through my mfc app. and immediately see the message passing back and forth thousands of times, something that I can control in win32. Here I''m talking about doc/view with 4 views all using one message pump and using the splitter window to separate the views. Perhaps if I were to not use doc/view and instead opted to create my own classes and specify their properties with mfc macros then I would get slimmer app but by then I would have spent lots of time in mfc source code rather than in my app. source code

P.S. Sometimes mfc is just not appropriate to solve some types of problems I guess...