Created attachment 33491 [details]
New vbr brushes to replace the gbr brushes

I'd love to do this change but I don't think we can just replace the brushes
since too many scripts rely on the availability of these brushes with exactly
these names.

Perhaps you could bring this up on the mailing-list?

Tobias are you sure this should this be marked as urgent?  
I thought 2.2-pre1 was pretty much frozen except for bugfixes, so this might
have to wait until after.  


Is .vbr an open standard used by other software?  Why choose .vbr?  

What I'm trying to say is that before you go through all the hard work of
changing file formats is there an open standard we change to as it might open up
the potential of creating brush sets that can be shared between various
applications?  

As they are "Vector Brushes" perhaps it might be possible to use some subset of
a Vector format like SVG (for example) and have something that could potentailly
be shared with Inkscape, Sodipodi and others?  

(and I should probably wait for the message and discuss this onlist...)

Alan, it was me who marked this as urgent. Also, your comments clearly show that
you don't understand what this report is all about. Can you please let us handle
this on our own? Thanks.

Tobias. I think we can and should do this change for 2.2 but we would need
brushes that register with the same name (and preferably have the same filename
except for the extension) as the brushes we used to ship with. Of course the
brushes should also match the look of the brushes they replace.

Created attachment 33498 [details]
Brushes with the same names and filenames than the old one.

The Diagonal Stars and the Calligraphic Brushes don't look 100% like the old
one, but as similar as possible.

Looks good. I wonder if this change could break things. The advantage of doing
it is that you could duplicate any of these standard brushes and then edit it.
The only problem that I could imagine is that someone could set the writable
flag on the system brush folder and edit the system brushes. The user would need
write access to the system brushes folder to be able to do that (note that Win32
users often have those permissions). But then, changing the writeable flag on
the system brush folder is definitely asking for trouble and unlikely to happen
by accident.

Created attachment 33531 [details]
New version with pixel.vbr and 1circle.vbr

Has anyone yet played with this? Perhaps we should just do the change for
2.2-pre2 and see if any problems turn up?

The circular brushes look identical to their old counterparts, but the
calligraphic and crosses differ.

@Michael Schumacher  
Yes, I know that and mentioned it in #6.

I guess we should postpone this. I am not willing to do this change now that
2.2.0 is that close. Moving to the Future milestone.

Now would be a good time to get this change into the HEAD branch. Michael, you
mentioned that the calligraphic and cross brushes look different. Do you think
this is a problem or do you agree with Tobias that they are close enough?

The round ones and the diagonal stars are really close, but the different cap
style (flat vs. rounded) of the calligraphics ones is noticeable. Also, the
preview  in the brushes dialog for the big diagonal stars is quite different,
the big vbr one looks almost the same as the medium one.

Replacing them is ok, provided that the old ones are available for reference -
maybe we could turn the brushes page at www.gimp.org from a mere list into
something useful...

Created attachment 48752 [details]
A comparison of the new brushes and their counterparts (inverted difference layer composite)

Created attachment 48753 [details]
The XCF source for the previous attachment

Bug #322176 proposed an alternative approach, similar but perhaps less problematic.

Fixed in trunk, revision 22129:

2007-03-15  Martin Nordholts  <martinn@svn.gnome.org>

        Converted .gbr to .vbr brushes where possible. Fixes bug #322176 and
        bug #157506.

        * data/brushes/Makefile.am: Changed .gbr for .vbr-counterparts for
        converted brushes.

        * data/brushes/*circle.gbr:
        * data/brushes/*fcircle.gbr:
        * data/brushes/DStar*.gbr:
        * data/brushes/callig*.gbr: Removed.

        * data/brushes/Circle-*.vbr:
        * data/brushes/Circle-Fuzzy-*.vbr:
        * data/brushes/Diagonal-Star-*.vbr:
        * data/brushes/Calligraphic-Brush-*.vbr: Added.

There seems to be a bug somewhere that should be addressed. The size of the brushes as shown in the Brushes dialog has changed. The Circle (01) brush for example is shown to have a size of (3 x 3).

The problem lies in the way the mask buffer size is allocated for generated brushes (code from gimp_brush_generated_get_half_size()):

    case GIMP_BRUSH_GENERATED_CIRCLE:
      *half_width  = ceil (sqrt (x_axis.x * x_axis.x + y_axis.x * y_axis.x));
      *half_height = ceil (sqrt (x_axis.y * x_axis.y + y_axis.y * y_axis.y));
      break;

For a 0.5 radius brush, *half_width and *half_height will both be 1 on the break, causing a 3x3 mask buffer to be allocated later on through (code from gimp_brush_generated_calc()):

  mask = temp_buf_new (half_width  * 2 + 1,
                       half_height * 2 + 1,
                       1, half_width, half_height, NULL);

Since I consider this a minor issue, (I personally doesn't care of the size of the buffer as long as the brush width is what I want,) I will concentrate on other 2.4 milestone bugs and let someone else handle this, at least until there are no other 2.4 bugs left of which I have contributions to make.

Fixing this should involve a single file patch (app/core/gimpbrushgenerated.c), given that the algorithm can be easily modified to handle the smaller buffer size (of which I'm not sure).

Opened bug #419256 since this is more of a separate bug than directly related to this bug.

I am reopening this report because the parametric brushes that have been added as a replacement for the pixmap brushes have different spacings. Most (or all) of the old brushes used to use 20% spacing while the new parametric brushes all use 1%.

This results in a drastic slowdown in painting performance and the result also looks vastly different. We need to look at the old brushes and restore the original spacing values.

2007-07-11  Sven Neumann  <sven@gimp.org>

	* data/brushes/Calligraphic-Brush-*.vbr
	* data/brushes/Circle-*.vbr
	* data/brushes/Diagonal-Star-*.vbr: restored spacing values. Closes
	bug #157506 again.