How to divide graphics and game logic in WPF?

I'm creating a game in WPF and I'm wondering if it is 开发者_运维技巧a wise decision to divide game logic and graphics to different threads.

My game logic works in steps (one step takes about 30 ms).

I'm quite afraid that locks will decrease the performance.

What do you think? Does anyone have an experience with that?

Thank you!

The cons regarding this far outweight the pros (i.e., manual message passing, synchronisation issues). Don't forget that the back-end presentation logic may already be executing in a separate thread. Most likely, the functions are already queuing up operations on a message bus and return instantly.

It really depends how much you do. Liocks are not an issue if you are not stupid programming your update logic.

Normally you would go client/server internally. The UI has it's own model it "renders", the logic has it's own non-visual model.

You can work with 2 queues (to model, to visual) where status updates are inserted (operations to logic, ui updates to visual model).

Then the WPF - timing or triggered wise - pulls updates from the queue and updates the model, making the visual changes as it is going.

Works pretty nice depending on the "game" you do. My "game" is a financial trading application working pretty exactly like that (albeit I have X visual queues, as multiple screens have all their own UI thread).