RFC re winmm/time.c
pouech-eric at wanadoo.fr
Sun Oct 10 12:04:24 CDT 2004
Jeremy White a écrit :
> Hi Folks,
> I ran into a problem with PowerPoint and winmm timer events,
> that has led me to radically alter this file.
> However, I'd appreciate a gut check from anyone more
> experienced with it than I.
> The fundamental problem is that Powerpoint does a
> timeBeginPeriod(1), trying to set timer resolution
> to 1 ms; we steadfastly discard that, and continue
> generating time updates and events on a roughly
> 10 ms interval, this can, in rare situations,
> lead to some awkward delays.
> Some investigation with a test program shows that most Windows systems
> start with a default resolution of 1 ms.
> This test program is attached; the 'average' reported
> at the top is the default resolution. Further, Windows seem to
> steadfastly ignore any timeBeginPeriod(x)
> where x > the current period. I surveyed about 6 systems;
> a mix on Win98/Win2k and Win XP. All but one rogue
> Win 2K system had a 1 ms timer interval (the rogue system
> had a 10 ms interval; why, I do not know). The MSDN
> pages suggest (but don't state clearly) that this
> is the expected behavior.
mm timers have been created to give better resolution than the old
ticker from DOS (55ms, 18.2 ticks per second). But this requires
specific hardware to do so, hence the various results you get. I would
assume that on recent boxes you get 1ms as lowest resolution.
> This behavior essentially means that on most Windows systems
> the timer resolution of winmm is 1ms and can not be changed.
> So, question #1: anyone object if I fix the timer resolution at 1 ms?
> Next, if I make this change, it makes the code in time.c,
> which is fairly awkward imho, even less efficient.
> We'll basically be scanning a loop every ms for no
> particularly good reason.
> I couldn't stomach this, so I rewrote it.
> Question #2: anyone object to my change? I have tested
> it with my attached test program, and I appear to have
> gotten it right, but...
the current code had been written (hmmm) with the assumption that
GetTickCount() could have a resolution of 55ms, hence you couldn't rely
on it and had to do the job yourself for a better resolution.
Wine provides 1ms resolution in GetTickCount, ReactOs does also (through
a quicly browsing of the code) (and the number of cases where winmm
will be run on Windows), so the basic proposition sounds fine.
From an implementation point of view, there's something wrong with it.
The time returned from TIME_MMSysTimeCallback (time to wait for next
timer to elapse) only takes into account the timers which existed when
the function is entered, not the ones which could have been created or
deleted while processing the callbacks.
Another point, with your proposal, we could use the fact that the global
time no longer needs to be maintained, hence the worker thread can be
destroyed when no more timers exist.
More information about the wine-devel