Windows7 stating T3D is not responding although all is fine

#1 Yep, it seems to happen while loading resources, especially if you're importing lots of shape files. The resource manager isn't run in a background thread, so the UI can't update while resources are loading, and I suspect the OS just thinks it's gone into an infinite loop (i.e. it's not responding to inputs). But it hasn't, and it comes out eventually. It'd be great to do something about this, but running a thread for the UI and a thread for loading is... complicated.

#2 Shouldn't be terrible if the UI is in the main thread - that's how most systems do it anyway. If that's not the case then it gets weird, but maybe we can come up with something clever.

#3 I have seen this as well, Should be fixed, though I don't have a clue where to start. Just looks bad.

Ron

#4 The exact reason this is occurring is because the program hasn't touched the message queue after several seconds. The only fix is to make sure to have a thread process message queue while another thread is doing the real busy work. Not so easy to do currently as Torque uses the main thread for almost everything except audio and networking.

#5 Thanks for the answers guys. I think I may have a work-around:

In Engine/source/main/main.cpp add the following:

int PASCAL WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCommandShow)
{
   char filename[4096];
   char gameLib[4096];

   DisableProcessWindowsGhosting();// <== Add this line

   GetModuleFileNameA(NULL, filename, 4096);
   filename[strlen(filename)-4] = 0;

According to msdn:

Quote:
Disables the window ghosting feature for the calling GUI process. Window ghosting is a Windows Manager feature that lets the user minimize, move, or close the main window of an application that is not responding.

It seems that it also disables the not responding message.

#6 Seems like that would be a good PR if its solid

#7 @Richard: Nice! This has been an annoyance for some time...

#8 Time to start implementing background loading threads....and watch torque go kaboom since its not threadsafe at all :/

#9 DisableProcessWindowsGhosting(); is not a fix. It just hides the symptom and prevents windows from presending a ghosted window with not responding title which allows the user to move/minimize the window out of the way. Calling this function will instead cause a not responding dialog prompt to display which gives the user the option to kill the program. Which is confusingly similar to the program crash dialog for normal users.

#10

Quote:DisableProcessWindowsGhosting(); is not a fix

You're right, it is not a fix, but I never said it was a fix.

Quote:this function will instead cause a not responding dialog prompt

I've run my game a few times with this work-around and all seems to be running smoothly, I have not seen any dialogs whatsoever although I did perform the same actions as I did before causing the annoying message, but feel free to try it yourself and see what happens.

#11 Another consequence of this is that when resources are loading, you can't restore the window from being minimised. It's very frustrating :P.

#12 @Daniel:
Yes, it isn't a very nice work around, I know. There are a few drawbacks as you might have discovered, so I did some Google-search about DisableProcessWindowsGhosting, and it seems that Microsoft is using it regularly in their Office products. I'm still looking into a real solution but for now this method does its work for me and get rid of the very annoying not responding thingy.

Maybe some kind of message pump hidden somewhere in the resource manager that kicks in when loading ...

#13 Is this happening while importing DAE files? I have not seen this issue otherwise. Its possible my computer is fast enough I do not. For our shipped product we do not load dae files but instead force load the cached.dts files.

#14 @Tim:
No/Yes it happens when you're loading your models (dts or dae or textures) into your mission. It started when I switched over from XP to Windows7. In XP this issue didn't occur.

The problem is that Torque isn't responding to messages Windows sends to programs to check if they are responsive while loading the resources, because it is the same thread :(

The solution to this issue is to move all resource handling to another thread, but as someone mentioned before: this is not an easy thing to do unfortunately.

#15 For Cortex we stuck the DisableProcessWindowsGhosting call in Win32WindowManager::Win32WindowManager(), but sticking it in WinMain should have the same effect.

Unfortunately there is no real equivalent for this call on other platforms. On OSX if I recall correctly though there is a separate thread for the main loop which makes more sense in this scenario.

A better solution of course would be to have threaded, asynchronous loading of mission files. We experimented with this a bit by storing the mission as a binary serialised list of SimObjects and loading the mission in blocks according to time spent. However this turned out not to be too beneficial as other processes in our loading process were taking longer negating the benefits of this approach.

Doing everything in a thread is sadly even more difficult since for example if you are allocating vertex buffers it needs to be done from the same thread (unless we're talking about stuff beyond DX9).

In general I suggest if mission loading is taking too long profile it and optimize where necessary. :)

#16 Richard: I meant a consequence of the existing behaviour, not of your fix, sorry. Seems like it might be a good idea to have the workaround in with a #define and some documentation. A proper fix may be a long time coming :P.

#17 Daniel: I haven't interpreted like that, so no need to be sorry ;) I would rather see a solution for the cause and not for the effect, but in this case, I don't know...

Quote:Seems like it might be a good idea to have the workaround in with a #define and some documentation.

That was the way I had planned it: make a define in torqueConfig.h, but this was not available in WinMain, so you have to call it from somewhere else. I have digged something deeper in the resourcemanager, but as you said, a proper fix might be along way unfortunately.