Sign in to follow this  
DartraKraft

Should I put RenderFrame() in another thread?

Recommended Posts

I just got into the 3d programming and have just finished a whole lot of directx tutorials. Should I put RenderFrame() in another thread? All the tutorials I have seen put the render function in the windows message loop along with PeekMessage. Well when the window gets a message or a whole lot of them (like dragging the window) the render function has to wait. I want it to render even if the window is being dragged. If I put it in another thread do I need to use a mutex with the d3d device if accessing it from multiple threads?

Share this post


Link to post
Share on other sites
I never tried but I think this is not a wise thing to do because while a window message is being processed , drawing to it might interfere or produce some undesired results. (Remember that you render frame thread will not be synchronized with the message pump thread).

Share this post


Link to post
Share on other sites
On a side note, Fraps gives really strange frame rate readings. Seems like most of the time it only does 85 fps. But if I drag a window over the top of mine, it jumps to 5000 or 6000 fps. What causes that?

Share this post


Link to post
Share on other sites
There are good reasons for wanting to put your rendering code into a separate thread, but my guess is that this isn't one of them. Do you have any evidence (statistics/profiling data) from your application to suggest that handling large numbers of messages from Windows is causing a problematic slow-down?

If so, then yes, maybe it would be worth shifting rendering to a separate thread (or maybe not - depending on circumstances there may be some other alternative), but if you're just going by your guess of something that will cause a slow-down, then it would be better to wait till you have some hard evidence before worrying about it.

Besides:
1 - People probably won't be watching your application extremely closely while they're dragging the window (so a render slow-down probably won't be noticed).
2 - Dragging a window isn't something that happens all that often, and when it does happen it's usually over pretty quickly.
3 - Computers are really fast nowadays; you might be surprised at how well rendering continues even when your application does seem to be receiving lots of messages.

Having said all that, if you do decide to go multithreaded, be careful to check the documentation for all the functions you use. Some of them can only be called from the thread that owns the window anyway. Others are designed to be thread-safe if you pass D3DCREATE_MULTITHREADED to CreateDevice.

You will need to use synchronisation primitives like Mutexes for various things if you go multithreaded, but unfortunately it won't be quite as simple as wrapping all DX calls in mutex locks.

John B

Share this post


Link to post
Share on other sites
You could also simply reorganize your message pump loop so that it always calls RenderFrame within some time frame regardless of how many messages are waiting in the queue, instead of pumping every message until the queue is empty and then calling RenderFrame. And for those cases when a string of messages is sent to the window message procedure rather than posted to the queue, you can still call RenderFrame from the message procedure at the desired minimum frequency.

[Edited by - Mastaba on March 16, 2007 8:37:07 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by DartraKraft
On a side note, Fraps gives really strange frame rate readings. Seems like most of the time it only does 85 fps. But if I drag a window over the top of mine, it jumps to 5000 or 6000 fps. What causes that?


This is because the rendering (or at least part of it) doesn't take place due to the render window being obscured. None of the rendering gets past the early stages of the graphics pipeline and therefore renders extremely fast resulting in an extremely high frame rate.

Degra

Share this post


Link to post
Share on other sites
Quote:
Original post by Degra
This is because the rendering (or at least part of it) doesn't take place due to the render window being obscured. None of the rendering gets past the early stages of the graphics pipeline and therefore renders extremely fast resulting in an extremely high frame rate.

Degra


I just realized something, setting PresentationInterval to D3DPRESENT_INTERVAL_IMMEDIATE actually allows a 5000 - 6000 fps (with only 2048 triangles lol). Go GeForce 7800 GS!

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