Sign in to follow this  
testyturtle

win32 file open dialog smears over windowed DX9 app

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
You need to do a call to your render function from WM_PAINT as well. You should either use BeginPaint/EndPaint or manually use ValidateRect to make sure WM_PAINT doesn't get fired again.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this