DrEvil: I hope the message you got from all of this is that you should use MFC for your tool, right? [smile] Because as far as getting a Windows GUI application up and running quickly, MFC is great. The time you save in development, frustration, and avoidance of mundane Windows tasks is well worth any small hit in speed that doesn't matter much anyway in this case (unless you're developing a real-time application which most classes of level-editor-related tools are not).

It's almost impossible to make a general case analysis of MFC's performance or viability as compared to another framework (or just raw Win32). The problem is that not only does the specific tasks of the application affect its performance, but many times in the Real World these performance comparisons alone are a moot point. If a game development studio needs to get a tool up and running for their artists/designers in the shortest possible time, then they're going to go with whatever solution leverages ease of programmability, functionality, maintainability, speed, and development time, and it just so happens that MFC is good in most those areas. Of course it's not a general solution to all your Windows application needs. But you simply have to determine what your real goals are. If you have the time to sit down and write your own Win32 framework, that's fine. If you have to sit down and write raw Win32 code because your application requires lighting performance, that's fine. Overall, I just wish people (not necessarily you) would start seriously considering the tools available and stop worrying about random - often irrelevant - benchmarks pulled out of thin air.

Properly setup the only overhead MFC will introduce is the memory needed to load the required DLLs, which can be substantial if you have limited memory ( which is rarely the case ). Beyond that the performance hit is negligeble, like all code if you write bad MFC code it will run badly.

I have written a number of game tools using MFC and the only problem I have had is using windows timers to trigger rendering, they are horribly inaccurate. More often then not the tool is dealing with a very small subset of game functionality and doesnt require every last drop of performce ( ie, UI editor, effect editor, sound editor... ). Even if you are very abmitious and want to do an editor that is basically running the entire game and doing stuff ( ie neverwinter nights ) the UI will not being doing anything unless touched and unless you have controls updating all the time ( histograms, charts, ect ) MFC will not being doing anything at all.

Jason

MFC is still ok to use in my books, as when I use it, I only
use it as a Windows class wrapper. There's really no noticable
performance loss when used this way. Windows receives messages
by the 100's, and when done it spends the 99.99% rest of its
time idling away. Now using the DocView... that's a diffent story.
I think DocView is why most people hate MFC with a passion,
but other than that it's not that bad at all. OWL was nice
back in its day, but when Borland introduced their DocView,
OWL died.