[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Thu, 2004-07-08 at 03:00 +1000, Peter Wang wrote:
> `interval' is the amount of time passed between the current iteration of
> the while-loop and the last iteration. We're supposed to call the
> callbacks some number of times, depending on how big that interval
> actually is (it can depend on how long select() blocks for and how long
> the callbacks run for, and maybe on the overhead of the mutexes).
>
> I think I've figured out what happened with the code at the top of the
> while-loop. It traces back to usigalrm.c (written by Michael and
> present in v3.9.32), where the `i = i * (TIMERS_PER_SECOND/100) /
> 10000L;' line is actually not useless. I must have copied out that
> chunk and not thought about it more.
>
TIMERS_PER_SECOND.. that's some constant derived from some PC timer
component, which is used as timebase for the Allegro timers. But what
does it have to do with unix scheduling? And INT_MAX.. wth has the value
of INT_MAX to do with it? heh.. at least there should be a comment for
such magic constants :P
> Anyway, the goal is to call the callbacks at an average rate of 100
> times per second. Whether the current code does that is for someone
> else to investigate :-)
>
It does. I made it print the number of calls in one second, and there's
lots of 99 and 98, some 97, and even one 100 :) More surprisingly, this
is also true for expal - so I was on the wrong track all the time - the
select(...,1) just causes something which then causes the real problem
of the delays to disappear. The delayed keypresses must be somewhere
else (me remembers past glances into xwin.c with horror and postpones
investigating this any further). Maybe in xwin.x there's another timing
to decided how much to process (and of course I remember the only-4-
events-at-once - might try upping that some time and see how expal
reacts).
--
Elias Pschernig