After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 133266 - Adaptive Supersampling in Blend tool should refresh progress more often
Adaptive Supersampling in Blend tool should refresh progress more often
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
1.x
Other All
: Normal minor
: 2.0
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2004-02-03 01:56 UTC by leigh
Modified: 2004-02-29 17:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description leigh 2004-02-03 01:56:16 UTC
Overview Description: 
when applying shapeburst gradient to a layer and setting the adaptive
supersampling values to maximum, gimp locked up and then crashed



Steps to Reproduce: 

1) make layer with white fill

2) cut out three (square with rounded corners) windows to transparency to
give a window frame effect

3)select window frame layer 

4)apply gradient tool with default values except tick the adaptive
supersampling box and move both sliders to the far right.

5)apply gradient to frame layer


Actual Results: 

The cursor busy symbol comes up for a long time. Eventually a "this
programme is not responding" (windows ?) message comes up and gives the
option to end programme. where apon gimp shuts down


Expected Results: 
Gradient should have been applied


Additional Information: 

There only seems to be a problem with the supersampling ticked, and max
values. I tried several gradients both with and without the supersampling
box ticked but only ran into trouble when i selected the maximum values

Windows 2000 - 5.00.2195
AMD Athlon 1700
ASUS a7n266 MOBO
500 meg ram
Comment 1 leigh 2004-02-03 01:58:02 UTC
Gradient to apply is shapeburst, not sure which one tho
Comment 2 leigh 2004-02-03 02:03:36 UTC
Forgot to add: layer "keep transparency" should be selected to apply
the shapeburst effect to just the frame and not the whole layer
Comment 3 Sven Neumann 2004-02-03 09:34:09 UTC
Actually the application doesn't crash. But you asked for an insane
amount of oversampling and this can take a while.

The problem here is that the gradient is being rendered with the mouse
grabbed and that there's no way to cancel the tool operation. Marking
as a duplicate of #113564.

*** This bug has been marked as a duplicate of 113564 ***
Comment 4 Raphaël Quinet 2004-02-03 12:17:51 UTC
This bug report describes a problem that is more serious than the
enhancement requested in bug #113564 and apparently specific to the
Windows platform: if an application does not process its event loop
for a while (which is the case here), then Windows will automatically
tell the user about it and propose to kill the application.  In this
case, it looks like the GIMP is stuck in the tool code for more than
30 seconds and then Windows wants to kill it.  This is a bug.  So we
should re-open this bug report, increase the severity of bug #113564
from 'enhancement' to 'normal' or submit a new bug report that is
specific to the Windows platform and mark it as dependent on #113564.
Comment 5 Sven Neumann 2004-02-03 12:52:45 UTC
If the tool action could be cancelled that would imply processing the
main loop at regular intervals so it would also fix this problem.
Comment 6 Pedro Gimeno 2004-02-05 17:06:22 UTC
The real problem here is that each step of Adaptive Supersampling can
take *too* long, even in the order of several minutes for just a very
minor update of the progress bar. Whenever it (the progress bar) is
updated, messages are processed and Windows restarts the timer that
marks the application as non-responding.

By the way, the "application not responding" message is never shown
automatically; it's only shown if the user clicks in the Close button
of an application which is marked as non-responding, which in turn
depends on a timeout of about 5 seconds without processing messages.

Playing with the settings I've managed to get a refresh of the
progress bar every 4 seconds more or less, and then clicking in the
Close button showed the gimp's close dialog instead of the app not
responding one. This is IMO the correct way to go here: just to ensure
that the progress bar gets refreshed often enough no matter how hard
the tool is working, and I'm changing the summary, severity and
milestone accordingly, and lowering the severity of bug #113564 back
to enhancement.

I think that this report is independent of #113564. The ability to
cancel is not related to this: the status of the cancel button will be
polled whenever the progress bar is updated, it just needs to be
updated more often. There may be other points in the application
affected by this problem and there may be a tracking bug for them once
they are located.

A quick fix would be to disallow Max Depth values greater than 5. That
number seems to work reasonably fast.
Comment 7 Pedro Gimeno 2004-02-05 17:27:47 UTC
Just an additional short note: when rereading what I've written I've
realized that the reasons why I'm reopening this bug may be not so
obvious; the fact is that fixing bug #113564 would not automatically
fix this one.
Comment 8 Sven Neumann 2004-02-09 14:53:35 UTC
Does it make sense to allow for Max Depth > 5 at all? IMO the best
solution is indeed to provide sane ranges for the values that can be
selected in the blend tool options.
Comment 9 Pedro Gimeno 2004-02-29 12:20:50 UTC
I agree. This can be considered a regression but I doubt that anyone
would want to use such an insane resampling level except perhaps for
very small images or selections. However risking to freeze gimp for
several days is a high price to pay.
Comment 10 Sven Neumann 2004-02-29 15:02:22 UTC
2004-02-29  Sven Neumann  <sven@gimp.org>

   * app/tools/gimpblendoptions.c: changed the upper limit for the
   supersampling depth from 10 to 6 (as a workaround for bug #133266).
Comment 11 Pedro Gimeno 2004-02-29 17:23:29 UTC
The pace of the progress bar is now acceptably fast IMO, even when
applied to 2000x2000 images. Resolving as FIXED. If this is not the
desired fix, feel free to reopen.