Fixed part 2 in CVS:

2004-01-22  Michael Natterer  <mitch@gimp.org>

	* app/core/gimpitem.[ch]: added "gboolean use_default_values"
	to GimpItem::stroke().

	* app/core/gimpselection.c: changed accordingly.

	* app/core/gimpchannel.c
	* app/vectors/gimpvectors.c: if use_default_values is TRUE, don't
	use the GimpPaintOptions passed in the GimpPaintInfo, but create a
	new one.

	* app/gui/stroke-dialog.c: pass FALSE so the values as set in the
	tool options are used.

	* tools/pdbgen/pdb/edit.pdb
	* tools/pdbgen/pdb/paths.pdb: pass TRUE so tool options settings
	don't affect PDB stroke calls. Fixes part 2 of bug #132145.

	* app/pdb/edit_cmds.c
	* app/pdb/paths_cmds.c: regenerated.

I can't reproduce the problem described here but looking at the output of the
script with default parameters makes me agree that the script is somewhat broken.

I have looked at this report several times. I have tested the script in both the
2.0 and latest CVS versions of GIMP and I don't see a problem with it. Unless
someone can attach some sample images showing bad output and a comment saying
what is wrong in the samples I would be inclined to close this report.

Created attachment 33286 [details]
xcf.gz image showing the output of the frosty logo script in gimp 2.0

See http://www-pool.math.tu-berlin.de/doc/GimpLogos/Frosty.gif for an example
of how it used to look like.

What I see is not so terribly bad as Michael Schumacher's example actually. See
http://perso.wanadoo.es/p.gimeno/temp/frosty_ok.png (good) and
http://perso.wanadoo.es/p.gimeno/temp/frosty_bad.png (bad) to see the
difference. According to a conversation with Michael Natterer on IRC some time
ago, the problem might be in either the Noisify or the Sparkle plug-in:

20040805T172200 <mitch> pgimeno: i bet it tracks down to a bug in either noisify
or sparkle

It tends to be more easily reproducable after closing the image and creating it
again, perhaps because the memory is not blank the second time. Sometimes it's
just a mild, almost unnoticeable noise but sometimes the effect is as bad as
seen in that sample image. The reproducability is random but frequent. When
invoking the script just after launching gimp the problem tends to not show up,
but when closing that image and then invoking the script again it is very likely
to show up.

*** Bug 15084 has been marked as a duplicate of this bug. ***

The problem shows up in the Sparkle layer. I ran some tests on the script where
I commented out either the call to noisify or the call to sparkle in an attempt
to narrow down which of the plug-ins may be at fault. My tests are pointing me
in the direction of the sparkle plug-in.

Created attachment 35341 [details] [review]
A Patch to correct a bug in sparkle.c

This is a patch to correct a problem I found in sparkle.c which I discovered
while comparing the GIMP 1.2 sparkle.c to the GIMP 2.2 one, while trying to get

to the root of the problem with this bug.

Note that it doesn't correct the problem reported here, but it's still a bug.
The problem is that the alpha pixel is taken from the start of the row instead
of from the current pixel.

Created attachment 35345 [details] [review]
A Patch to correct 4 regressions bugs in sparkle.c

This patch fixes four regression bugs that surfaced between GIMP 1.2 and GIMP
2.2. Now the output seems quite identical to GIMP 1.2's except for some noise
in some places. (which is probably not due to the sparkle plug-in).

Applied to both branches:

2005-01-02  Sven Neumann  <sven@gimp.org>

	* plug-ins/common/sparkle.c: applied patch from Shlomi Fish that
	fixes regressions in Sparkle plug-in (bug #132145).

I am closing this bug now. If someone thinks that the script is still somehow
broken, then please reopen.

Created attachment 35355 [details]
A resultant (.xcf) image with some noise marked

There are still some problems in the script. This attachment shows a noise in
the output of the script which is caused from some reason. (some of the rays
are missing).

I would have re-opened this issue, but I don't have the bugzilla permissions to
do so.

Re-opening as requested by Shlomi Fish.

Created attachment 35400 [details]
Test Script to Demonstrate the Problem.

Well, this is a test script based on the original frosty logo that still
demonstrates the problem (sometimes). To use it put it in one of your script
directories (e.g: $HOME/.gimp-2.3/scripts/) and then type the following in the
script-fu console:

(script-fu-shlomif-frosty-test "The GIMP" 100 "Arial Black" '(255 255 255))

Note that I'm less successful in being able to reproduce the problem with the
other fonts I tried besides "Arial Black". Moreover, it seems that it's
sometimes OK. Especially if gimp was started with one or two (but not more)
images specified as command line arguments, which are then closed, and then the

script is invoked.

I was able to reproduce this problem with the "Becker" font (the default font
for the script) only at size 200. It seems the "Gill Sans Ultra Bold" font also
exhibits this problem at size 100.

Another regression bug found:

<<<
--- plug-ins/common/sparkle.c.orig      2005-01-05 19:05:05.716613560 +0200
+++ plug-ins/common/sparkle.c.orig.corrected    2005-01-05 20:37:21.287078936 +0200
@@ -692,7 +692,7 @@
             {
               if (has_alpha && s[alpha] == 0)
                 {
-                  memset (dest, 0, alpha);
+                  memset (d, 0, alpha);
                 }
               else
                 {
>>>

Now the results are almost identical (at least to the naked eye) but there are
still some differences. I'll investigate further.

Created attachment 35501 [details] [review]
A Patch against CVS head to correct more regression bugs in sparkle

This patch corrects more problems in the plug-in:

1. memset(dest) instead of memset(d) always initializes the beginning of the
row. (I missed this one last time, because the statements looked alike)

2. The alpha is not initialized from the pixel, and so may be used
uninitialized. This has been present in gimp 1.2 as well, and I can produce a
similar fix for this version of the GIMP as well, if the need arises.

On IRC, Michael Natterer said (or should I saw threatened) he'll make me the
maintainer of the sparkle plug-in, because now I am the expert on it. I should
say, that despite all that my understanding of it is a bit superficial - I just
make sure it works as before and carries exactly the same operations. 

Nevertheless, being a plug-in maintainer for this would be accepatable.

2005-01-06  Sven Neumann  <sven@gimp.org>

        * plug-ins/common/sparkle.c: applied patch from Shlomi Fish that
        fixes more regressions in Sparkle plug-in (bug #132145).

I think we should close this report as FIXED now.

Sven: "I think we should close this report as FIXED now."

Hold your horses. There is still a problem in the script's output. (not in the
sparkle plug-in). It was still present in gimp 1.0.x, but is nevertheless
relevant. The problem is that there are often shadows whose edges are shaped in
straight horizontal (and sometimes vertical) lines. I can post an image
demonstrating the problem, and am working on determining what in the script is
causing it.

Created attachment 35608 [details]
A more minimal script exhibiting the new problem.

This is a closer-to-minimal test script that still exhibits the problem I'm
talking about. Everything is OK when run with:

(script-fu-shlomif-frosty-test "The GIMP" 200 "Bazooka" '(255 255 255) FALSE)

However, when run with:

(script-fu-shlomif-frosty-test "The GIMP" 200 "Bazooka" '(255 255 255) TRUE)

There is some horizontal noise at the top. The last boolean parameter executes
only one statement.

Note that I am not done removing the various statements from there, so the
script is not entirely minimal. Nevertheless it indicates a problem in the GIMP
internals.

Created attachment 35626 [details] [review]
A Patch against CVS head to correct the problem with the shadow

I discovered that the problem with the shadow was due to the fact that the
shadow was generated within the image boundaries and then the shadow layer was
moved (= translated) by an offset which caused it to have horizontal edges at
the top of the resultant image.

This is a patch against CVS head to correct this. It plays with the sizes and
offsets to get it right, and make sure that the upper-left L-shaped area not
covered by the shadow layer previously will be properly rendered.

Comment on attachment 35626 [details] [review]
A Patch against CVS head to correct the problem with the shadow

please commit to both branches

Shlomi committed to HEAD but forgot the stable branch. I've merged the fix for him:

2005-01-07  Sven Neumann  <sven@gimp.org>

	Merged from HEAD branch (fix by Shlomi Fish):

	* plug-ins/script-fu/scripts/frosty-logo.scm: made sure the shadow
	is given enough space and then truncated instead of translated to
	the center of the image, thus preventing the display of shadows
	with a completely horizontal or vertical edge (fixes bug #132145).