0

I am in the situation where I have text files representing a game object. What I have to do is parse the file and get the points that the game object will be drawn to. For example

fruits.txt
pear 10, 20
orange 10,38

Whenever I grep a point I use dispatcher begininvoke to update the new fruit to the screen. This works better than invoke for a single thread. Whenever I have more than one screen updating their points in parallel it becomes very slow and it begins to hang or the frame jumps while drawing to the screen. Is this because BeginInvoke queues the messages? Despite the freezing BeginInvoke still works faster than Invoke, although Invoke has a smoother update. How can I make BeginInvoke "flush the messages" to screen. There was an idea in some other post where I can save the points in a queue and draw to the screen while there is still something in the queue, but there wasn't any difference. Please any ideas? Thanks.

Lews Therin
  • 10,907
  • 4
  • 48
  • 72
  • 1
    The Dispatcher mechanism isn't really lightweight. If you have to call it multiple times you may consider to create a thread-safe queue and to BeginInvoke a single ProcessAllItems method. – Adriano Repetti Jun 11 '12 at 18:21

1 Answers1

0

According to MSDN Control.BeginInvoke():

Executes a delegate asynchronously on the thread that the control's underlying handle was created on.

In your case, repeatedly calling BeginInvoke is adding lots of calls to the MAIN UI thread, bogging it down with other work.

You are definitely best off batching up your points in a queue and then drawing them to the screen at once, rather than trying to have multiple draws running asynchronously on the same thread.

Jon Senchyna
  • 7,867
  • 2
  • 26
  • 46
  • You can't have "multiple draws running ansynchronously on the same thread", a thread can only do one thing at a time. But you are correct in that he's throwing a lot of unnecessary messages at the UI thread, where queuing them up and processing them all at once would likely reduce the "lag" he sees (although it probably won't eliminate it completely if he's doing so many updates at once that it freezes the UI thread all-together). – CodingGorilla Jun 11 '12 at 18:24
  • If I have to queue them once it will definitely be unresponsive. How can I have the batch so that it updates when there is enough stuff. I tried using a timer, if timer > maxTimer basic code to update it but that didn't help. I tried checking the queue size to see if it is 500 and then update. But these aren't optimal solutions. – Lews Therin Jun 11 '12 at 18:31
  • Is there other code being processed, aside from the actual drawing of your game objects? If so, you could potentially move that logic to a separate worker thread and have the UI thread only handle the actual drawing. – Jon Senchyna Jun 11 '12 at 19:52
  • @LewsTherin you do not need to process them all together. You may process them one by one in a cooperative manner with the main thread (http://stackoverflow.com/questions/4502037/where-is-the-application-doevents-in-wpf) if, and only if, you really need to do it in the UI thread. – Adriano Repetti Jun 11 '12 at 20:34
  • Application.DoEvents doesn't exist in WPF. And I heard it is a sign of bad design. 1 thread is fast, if I can get it be smooth for multiple threads I will be glad. I tried handling it using events but I still end up having to call invoke/beginvoke – Lews Therin Jun 13 '12 at 17:42