Of time, brushes and inks
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| Of time, brushes and inks | Joao S. O. Bueno | 21 Aug 06:57 |
| Of time, brushes and inks | Joao S. O. Bueno | 23 Aug 16:07 |
| Of time, brushes and inks | Adam D. Moss | 23 Aug 16:28 |
| Of time, brushes and inks | Juhana Sadeharju | 28 Aug 06:53 |
| Of time, brushes and inks | Adam D. Moss | 28 Aug 11:32 |
| Of time, brushes and inks | Sven Neumann | 28 Aug 13:18 |
Of time, brushes and inks
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,
JS ->
Of time, brushes and inks
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,
Of time, brushes and inks
Joao S. O. Bueno wrote:
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
Of time, brushes and inks
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
Is there any other way to read the mouse positions than via X? I would like to completely separate the mouse device and the graphics drawing because GTK drawing caused jitter in mouse readings.
When I move the mouse in circle slowly, the drawing is detailed. But when I move the mouse fast, the drawing is polygonal. Is the reason in mouse interface or in X, or both? Does the tablets have the same problem?
Are the fast drawings in GIMP 2.0 still polygonal? Could that be fixed with splines? Should the spline system be inside the mouse system, not inside the drawing system? I.e., some kind of simulated high time-resolution mouse (or tablet)?
Juhana
Of time, brushes and inks
Juhana Sadeharju wrote:
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
Is there any other way to read the mouse positions than via X?
You could use the crufty DGA extension if really desparate.
I would like to completely separate the mouse device and the graphics drawing because GTK drawing caused jitter in mouse readings.
I think you have leapt to the wrong conclusion.
When I move the mouse in circle slowly, the drawing is detailed. But when I move the mouse fast, the drawing is polygonal. Is the reason in mouse interface or in X, or both?
Somewhat the mouse interface, and somewhat because we simply drop (compress) mouse motion events at the gdk/gimp level if we're running behind. The 'Perfect-but-slow pointer tracking' option is supposed to stop that from happening, but it's true that X's mouse sampling time period can truly suck (sometimes the hardware's fault, sometimes the driver's fault for not knowing that the mouse can cope with a higher sampling rate, but this DOESN'T happen because 'GTK drawing caused jitter in mouse readings'). The sampling rate for tablets can indeed be much better.
--Adam
Of time, brushes and inks
Hi,
"Adam D. Moss" writes:
When I move the mouse in circle slowly, the drawing is detailed. But when I move the mouse fast, the drawing is polygonal. Is the reason in mouse interface or in X, or both?
Somewhat the mouse interface, and somewhat because we simply drop (compress) mouse motion events at the gdk/gimp level if we're running behind. The 'Perfect-but-slow pointer tracking' option is supposed to stop that from happening ...
"perfect-mouse" is the default setting in GIMP 2.0.
Filtering jitter in order to get smoother drawings has been suggested before (see http://bugzilla.gnome.org/show_bug.cgi?id=55366). But except for the cleanups in the paint core that should make it easier to implement such a thing, no code has yet been written to implement this.
Sven
