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.