odd repaint issue

[wbonnell]

If while simulating games in FOF I move another application to the foreground, FOF appears to hang. According to task manager, it is in a "not responding" state. However, if I wait a bit (approximately the amount of time it would take to complete the simulation), control eventually returns to FOF. Not a bug per se, but certainly unexpected and odd behavior. Here are my specs:

-Windows XP Pro, Service Pack 1 and all windows update patches
-512MB PC2700 DDR Ram
-Amd Athlon 2500+ Barton
-Geforce 4mx, 64MB (detonator driver version 52.16)
-Maxtor 80MB , 7200RPM, 8MB cache hard drive
(anything else you need to know?)

None of my other programs exhibit this behavior. Any ideas?

[fof playa]

I've lived with this forever but I hava aslow-ass computer. y53s3-,

[RendeR]

Actually I've had this problem with fof2001, 2002, and fof4, even TCY does this from time to time. SOmething happens in the video translation while you're running simulations.


I get it most often when I am simming an entire season quickly, if I go back and forthe between windows my FOF window will go blank or partially blank, the program returns to normal once the simulation completes. I just have to be patient and let it finish. My machine is slower than yours, but I'm thinking its a matter of open RAM during long simulations.

[wbonnell]

Originally posted by RendeR
Actually I've had this problem with fof2001, 2002, and fof4, even TCY does this from time to time. SOmething happens in the video translation while you're running simulations.


I get it most often when I am simming an entire season quickly, if I go back and forthe between windows my FOF window will go blank or partially blank, the program returns to normal once the simulation completes. I just have to be patient and let it finish. My machine is slower than yours, but I'm thinking its a matter of open RAM during long simulations.

From what I can tell, FOF never uses more than about 45MB or ram. And I can assure you that I have plenty of available main (not swap) memory.

I find it interesting that you experienced this problem in 2001; I've never noticed it before...

[fof playa]

Originally posted by fof playa
I've lived with this forever but I hava aslow-ass computer. y53s3-,

Anyone ever gotten so pissed off at their own typing and seen this before?

[Surtt]

If you have a program doing a cpu intense operation such as compiling a program, recalculating a spread sheet, or simulating a NFL season, it will be to busy to respond to your operating system. The operating system will then report it as "not responding." Once the operation is complete it will start responding again and the operating system will remove the tag.

There are not a lot of cpu intense programs commonly used so you don't see it much. Normally this is a sign that a program has ether entered an endless loop or has called a corrupt routine and is waiting for a response that will never come, i.e. crashed.

[wbonnell]

Originally posted by Surtt
If you have a program doing a cpu intense operation such as compiling a program, recalculating a spread sheet, or simulating a NFL season, it will be to busy to respond to your operating system. The operating system will then report it as "not responding." Once the operation is complete it will start responding again and the operating system will remove the tag.

There are not a lot of cpu intense programs commonly used so you don't see it much. Normally this is a sign that a program has ether entered an endless loop or has called a corrupt routine and is waiting for a response that will never come, i.e. crashed.

True, but I run CPU intensive applications all the time (ie compilers) and they don't exhibit this behavior.

I don't know how the GDI works in win32, but in Swing, there is an AWT thread that handles UI updates (among other things). If you monopolize that thread (ie run the simulation on it), the entire application blocks. Therefore, if you wish to provide some useful user interface feedback, you <b>ought to do your CPU intensive stuff on a separate thread.</b>

[Surtt]

I'm running w2k. If I bring up the task manager I can watch the game peg my cpu usage and be reported as not responding while simming a season or if I "skip remaining stages" of a free agency period. Afterward it goes back to normal.

In win32 a message (invalidate window) is passed to the program and the program is responsible for repainting itself.
Unless there is code to check for this message during the sim it won't be handled until the program returns from the routine.
And windows will report it as not responding.

I'm just throwing this out there,
I have no idea of how Jim has programmed FOF.

[wbonnell]

Originally posted by Surtt

In win32 a message (invalidate window) is passed to the program and the program is responsible for repainting itself.
Unless there is code to check for this message during the sim it won't be handled until the program returns from the routine.
And windows will report it as not responding.

And that thread won't have an opportunity to dequeue the event if it's busy crunching numbers. Thus, a separate thread should be spawned specifically for the number crunching. If you don't want the user interacting with the application in the meantime, you can display a modal dialog.

Anyway, I think we've geeked out enough. Clearly this isn't a bug, but it could be handled relatively easily.

[Surtt]

Agreed