Whenever I try to do this, the dlgproc of the "file open dialog" takes over processing, and if you drag the dialog around, the main DX9 window gets smeared dialog trails all over it since the main window is no longer rendering. Does anyone know the correct way to handle this? There must be some way to re-render the main DX9 window whenever the dialog moves and causes a smear, but i'm not sure how. WM_PAINT message in main window? I would appreciate it if anyone can help me with the correct way to solve this issue. Thank you. testyturtle

You might be able to catch the WM_MOVE message for the dialog and then fire the WM_PAINT message at the underlying window.

Dave

You could bung in a render in your WM_PAINT handler, but I'm not sure how good an idea that would be...

Thanks you guys calling render() followed by ValidateRect() when receiving the WM_PAINT message seems to do the trick. ValidateRect() ensures the WM_PAINT message isn't sent repeatedly as Endurion stated.

There are some other weird side effects (my timing calls to QueryPerformanceCounter() inside render() stop working if I call render from WM_PAINT just once), but I can live with that for now.

Quote:Original post by testyturtle
my timing calls to QueryPerformanceCounter() inside render() stop working if I call render from WM_PAINT just once

You shouldn't be doing any timing from your Render() loop at all. The Render() loop should just render the current state, and not do any updating.

Hi Evil Steve. This is not final code.

I don't have a compiler with profiling, so i'm using QueryPerformanceCounter() along with QueryPerformanceFrequency() to do as much profiling as I can manually by timing function entry and exit on various functions.

I realize the absolute timing values will be skewed a little by the calls to QueryPerformanceCounter(), but the relative times between functions is accurate. I've actually managed to do a fair bit of optimizing of my ID3DXSPRITE code, etc using this. My rendergui() call has gone from eating 14% of overall application CPU time to just 6%.

What I do is accumulate the time spent in various functions, then divide that by the total app runtime and write the results out to a log so I can examine it later.

If I remove my "#define PROFILING", then all the QueryPerformanceCounter() calls are dropped by the preprocessor and my render functions go back to full speed. :)