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 

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.


Gimp-developer mailing list

Reply via email to