GIMP Version: 2.8.14
Operating System: Windows
GIMP Experience: Basic Level

---

Hi Gimp gurus!
Is there a "detailed" tutorial on the use of gimp_paintbrush (full options, i.e. including a multicolor gradient) in a filter?
The simple explanations found on PDB doc like
"This tool is the standard paintbrush. It draws linearly interpolated lines through the specified stroke coordinates. It operates on the specified drawable in the foreground color with the active brush. The "fade_out" parameter is measured in pixels and allows the brush stroke to linearly fall off. The pressure is set to the maximum at the beginning of the stroke. As the distance of the stroke nears the fade_out value, the pressure will approach zero. The gradient_length is the distance to spread the gradient over. It is measured in pixels. If the gradient_length is 0, no gradient is used."
is not sufficient (at least for me)to understand the behaviour of the command.
It would be nice to have some examples with explanations of all the relationships among the parameters and the brush characteristics.
Thanks a lot

peanuts info

the PDB Doc says
"The "fade_out" parameter is measured in pixels and allows the brush stroke to linearly fall off. The pressure is set to the maximum at the beginning of the stroke. As the distance of the stroke nears the fade_out value, the pressure will approach zero"

Do you like to make a simple test?
Open the Python console.
Enter there statements

This is what you get:


Do you consider this as being a "fade out" effect? It looks more to me like a .... "fade in"

Let me put it this way, the PDB browser incorrectly specifies the fourth parameter to 'gimp-paintbrush'. It should probably read: Array of stroke coordinates: { sn.x, sn.y, ..., s2.x, s2.y, s1.x, s1.y }

In other words, stroke arrays provided as PDB arguments and returned as PDB values are always specified in "reverse" order.

now it's clear!
in fact I thought to draw in the reverse order....
but, wouldn't it be better to correct the filter to stroke in the "natural" direction?

1) There are about 15 years worth of filters out there that may depend upon the current behavior.
2) The underlying implementation of a path stroke is a simple linked list. The easiest way to add an element to a linked list is to insert the new element into the beginning of the linked list. In order to add an element to the end of the linked list, it is necessary to "walk" along the list from its beginning until the last element is reached, which can be inefficient if there are tens of thousands of elements in the list*.


* One could maintain two pointers for every linked list -- one to the first element and one to the last element -- and thus obviate the need to ever "walk" along the list, but that is not how it was initially done and it is a little late to change things now.

ok, so it's simpler to update the documentation, but at least this should be done IMO, so the users get clear understanding of the behaviour before starting using the function

and there is also another oddity:
if the option to use the gradient is chosen it seems that the stroke goes "naturally" from the first point to the last (left to right) as opposed to the behavior discussed previously
so, in the same filter the same parameter (the array of strokes) is interpreted in opposite ways when using the "fading" and when using the gradient.

(the result is the same both using method 0 and method 1 -BTW I do not understand when and how this parameter is taken into account-)
another aspect (in the use of the gradient) is the behaviour at the end of the "space" indicated by the user for the gradient span: the last colour is then repeated indefinitely, while it could be nice to see the gradient be repeated; maybe also this one is something "historical", but not "nice" per se