Too much silence. I see problems here :-)
Probably means most people agree with the issue, but that I am not the only one who find it a hard question to deal with.
I had tought on an unclean alternative to have a higher time resolution on gdk/gtk+ events, that would be to have a core GIMP time object with higher resolution. Events would then be timed GIMP side whenever they are received. The upside: this would not depend on other projetcs to implement. The downside: if for some reason the events get delayed to be passed to the GIMP, they'd be misshandled.
I'm not sure that you understand the problem -- we need the timestamp of when the physical event occurred, NOT when it was de-queued. X11 timestamps events because it is conceptually (and sometimes physically) much closer to the input hardware. The events then get serialized, (then sometimes buffered, wired, unbuffered), deserialised, queued, and eventually unqueued at leisure. The point is that we want the velocity of the physical event, not the velocity at which GIMP unqueues the event (!). Something relatively close to the hardware is the only thing that can with some reliability timestamp a physical event -- and as commented, the resolution of that timestamp is pretty lousy. So this either gets 'fixed' by X11 (which just can't make guarantees on timestamp resolution, so it wouldn't be a particularly reliable fix, but it would be nice) or we resort to some sort of digital time smoothing, which is what we have (and which can probably be improved upon, but is not a 'big hack').
--Adam
--
Adam D. Moss . ,,^^ adam@xxxxxxxx http://www.foxbox.org/ co:3
"Forget climbing trees and learning the tin whistle. Here is The Chineapple Punx guide to smashing the system with your runner beans, running riot with broccoli florets and reclaiming the streets with organic damsons."
