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 project, now in use in most desktop
> GNU/Linux distributions.
> regards,

Gimp-developer mailing list

Reply via email to