Re: Progressive updates for image window of Windowsconsole app
"Russell Lang" <[email protected]> Sat, 10 Jul 2004 17:47:51 +1000
| Newsgroups | gmane.comp.printing.ghostscript.patches |
|---|---|
| Message-ID | <40F02BC7.30543.B96889EF@localhost> |
Igor, > > So the only way this could take 1 minute to get > > between those to GetSystemTime calls is if your system is *really* > > busy and the thread scheduler gives that thread no time at all. > > Yes, but if the system was busy for a minute due to another task, > why do you delay THIS task for TEN minutes ? It doesn't delay THIS update, it delays the NEXT update. If the system is busy for a minute due to another task, and never once gives the image thread 50ms of CPU, the system is in serious trouble. Your system is going to be so unresponsive that it doesn't matter what you do. If it takes less than 10 minutes to render the page, then having the update interval set to 10 minutes effectively means never. The timer gets stopped when a sync or page occurs. I don't see what the problem is. The code measures the time it takes to copy the raster to the display, which with an accelerated video card is < 10ms. With display device separations format it might be 750ms due to each pixel being converted to CMYK then RGB as it is displayed. So for it to take longer than a few seconds to get between the two GetSystemTime calls, there must be a thread switch between them, and then it not get another time slice for a long time. This is unlikely and if it does happen then the system is stressed. If the system is stressed, we stop doing updates. Measuring CPU time for executing that task rather than elapsed time would be better, but I don't think it is worth the effort.