To thread or not to thread?

Started by
6 comments, last by Raghar 15 years, 5 months ago
(in C#.net) So i'm designing an application that desplays a winform, inside of which is a direct3D panel. Direct3D is also displaying to a seperate video output. Frame rate has to stay high regaurdless of what the user is doing inside of the winform which includes loading content files. Would putting my directX code into another thread help me or would it just make my code needlessly complex?
Advertisement
A thread can only do one thing at a time. If you give it two long tasks that both need to stay active at the same time, then it has to work on the first one, pause it, work on the second one, pause it, go back to the first and do some work, pause it, etc. If you have two threads you can give each thread one of the long tasks, and no pausing will be required (and pausing a task can be a headache to code depending on the task, so no pausing is a double plus). I'm not sure what the user would be doing in your program, but it sounds like multithreading might benefit you here.
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]
Quote:Original post by Neon_C
Frame rate has to stay high regaurdless of what the user is doing ... which includes loading content files
At least thread that.
Quote:Original post by Neon_C

includes loading content files


Asynchronous file IO is another way to tackle this particular problem which may be better suited for the task anyway, even in combination with threads.
With more investigation it seems that the best course of action would be to put the entire winform and rendering code into a 'game loop' and put things like content loading into a low priority thread. thatway the threads i'm only creating threads as i need them.
You should def. just do threading ad-hoc. The simplest way is the best IMO - just do this - if some action actually causes your application to FREEZE and not respond for some time, then you should put that action in a seperate thread. Loading content is a perfect example of this - maybe it takes 5 or 10 seconds to load a model into memory for your usage... if your application is frozen and cannot respond for those 10 seconds, then you need a thread, but only for that one function call that loads the file.
FTA, my 2D futuristic action MMORPG
Good rule! I like it.
Main rule of Java GUI is, don't do ANY long work in event dispatch thread. Event dispatch thread is running with windows priority 0.7, while rest of the program is running another thread with priority 0.5, rest of the programs on the system are also running at 0.5 priority, thus doing work in event dispatch thread would damage all other programs running on that system.

I suspect C# GUI has also more than one thread, and its event queue also has different priority.

This topic is closed to new replies.

Advertisement