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. On Saturday 21 August 2004 01:57, Joao S. O. Bueno wrote: > Hi there, > > > I've been greping the code in search for a nice implementation for > enhancements described in bugs 143216 > (Airbrush does not take into account speed ) > and 150227 (PIPE_SELECT_VELOCITY unimplemented for painting with > brush pipes) > > Basically, both need the time information of a paint event in order > to give out interesting results. The one thing in the GIMP which > uses this time information is the ink tool. > > While a more imediate solution might be re-implementing > instantiating objects that are part of the ink tool operation in > other parts of the GIMP (that would have the bennefict of > functionality, while avoiding code duplication, but I guess the > relevand code would have to leave the .c files with an *ink* in > their name), while examining the time treatemnt in > app/paint/gimpink.c there is this comment circa line 248: > > /* The time resolution on X-based GDK motion events is bloody > * awful, hence the use of the smoothing function. Sadly > this * also means that there is always the chance of having an * > indeterminite velocity since this event and the previous * several > may still appear to issue at the same > * instant. -ADM > */ > Meaning that the timing we currently have with the ink tool is > mostly a big hack and a lot of guessing. > > I think that both for the Ink tool and for a much nicer > implementation of the airbursh tool, and even a future eye-poping > implementation of bug 119240 ( Dynamic Brush stroke panel and/or > Dynamic path stroke), a clean code would need at least 1/100 of a > second resolution for mouse events. > > So, I am not intimate with GDK, but certain of you certainly > are...could we reimplement for a next generation GDK (one that will > be around for GIMP2.4/3.0) a new set of time resolutions for > events? > > Is that limited by X11? If so...maybe we can change/ask to change > things as deep in the X.org project, now in use in most desktop > GNU/Linux distributions. > > regards, >
