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,
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
