Tim Rowledge tim@sumeru.stanford.edu wrote:
I like the concept of time stamps.
So do I, unless it costs a lot - although keystroke and mouse button events are usually relatively slow (ie maybe a couple of hundred aminute at worst) some events (people have been considering serial or socket events for example) might be much higher bandwidth and could cause a problem if getting the time is costly. Something to keep an eye on; some OSs provide timestamps on event, some don't. Some have expensive clock() calls, some are cheap. We have to check and make sure we don't make life good on one platform by ruining it on another, just like always.
Hmm, I just put these two ideas together. On Unix, the timestamps for X events are going to be based on a completely separate clock from the ones for sockets. I guess the VM can just stamp the times itself, and ignore whatever X says, but something is definately lost: the input events will be less precise!
The alternatives on Unix seem to be:
1. Only use *input events*, and allow for precise timings. 2. Mix all events into the same queue, but use imprecise timings.
-Lex
Lex Spoon wrote:
The alternatives on Unix seem to be:
1. Only use *input events*, and allow for precise timings. 2. Mix all events into the same queue, but use imprecise timings.
Maybe I'm missing something, but why would we want to combine dissimilar events in the same queue (sockets/input/serial?)?
Wouldn't that require the queue reading process to know about each event type, or to pick through the queue for the next event of a particular type?
Is there some advantage to a single queue, or is it just because it's easier?
on 7/31/00 6:29 AM, Lex Spoon at lex@cc.gatech.edu wrote:
Tim Rowledge tim@sumeru.stanford.edu wrote:
I like the concept of time stamps.
So do I, unless it costs a lot - although keystroke and mouse button events are usually relatively slow (ie maybe a couple of hundred aminute at worst) some events (people have been considering serial or socket events for example) might be much higher bandwidth and could cause a problem if getting the time is costly. Something to keep an eye on; some OSs provide timestamps on event, some don't. Some have expensive clock() calls, some are cheap. We have to check and make sure we don't make life good on one platform by ruining it on another, just like always.
Hmm, I just put these two ideas together. On Unix, the timestamps for X events are going to be based on a completely separate clock from the ones for sockets. I guess the VM can just stamp the times itself, and ignore whatever X says, but something is definately lost: the input events will be less precise!
The alternatives on Unix seem to be:
- Only use *input events*, and allow for precise timings.
- Mix all events into the same queue, but use imprecise timings.
-Lex
Someone was mentioning the expensive cost of doing timestamps on the mac, well perhaps indirectly. David Simmons at Camp Smalltalk mentioned to me a way he used in QKS smalltalk to get microsecond timing very very cheaply. I'll look into exploring this option.
PS I'm not sure I understand why the clock for sockets on Unix is different than the one from X?
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== Custom Macintosh programming & various Smalltalk dialects PGP Key: DSS/Diff/46FC3BE6 Fingerprint=B22F 7D67 92B7 5D52 72D7 E94A EE69 2D21 46FC 3BE6 ===========================================================================
squeak-dev@lists.squeakfoundation.org