Jon Winters forwarded this question from the Gimp User Mailing List in the hopes of getting more answers:
Yesturday I requested that our friend send me a copy of his image so that I could try the test on my computer at work. (PIII 400 128MB, Matrox G400, WinNT)
I chose to test with levels because I adjust levels or curves on almost every image I edit.
In Photoshop (v5.0) the redraw after letting go of one of the levels sliders was less than two seconds. (default 'out of the box' photoshop configuration)
In the gimp I was surprised that the performance is indeed terrible. With the tile cache set to 72MB it took 40 seconds. With the tile cache set to 96MB it took 16 seconds. Moving the tile cache to 128MB (on this 128MB machine) knocked it down to 11 seconds.
Is there some other configuration that I am missing?
Someone noted that the latest CVS version of the Gimp turns off the pre-vue of pixels that aren't visible. Jon's performance improved because of this, and the time is now down to 4 seconds.
Raphael Quinet writes:
I re-discovered an old problem with these scripts: some operations on the layers are not recorded on the undo stack. If I am not mistaken, these operations are:
- toggling the visibility of a layer,
- toggling its "preserve trans." flag,
- changing its opacity.
This has annoyed me a couple of times when working on some images by hand, but now the problem is more visible with the "Alpha to Logo" scripts that are undo-aware.Some of these scripts set the "preserve trans." flag on the original layer and apply some operations to it. If you undo the operations, you get back to the original image except that the flag is still set. Running the same script or another script on the image can give a different result than before, because of this flag. Some other scripts toggle the visibility of the layer and keep it in the final image. If you undo the script, you are back to the original image except that the layer is now invisible. This is not what you would expect from the "undo" operation...
So I have two questions:
- Is there any reason why these three operations are not put on the undo stack?
- If there is no good reason for that, could someone tell me how to change the code so that it is possible to undo these operations?
Austin Donnelly had some suggestions for Raphael, and asked the list if
Anyone else want to comment at this stage? As a user, would _you_ get
confused when you hit undo and all that changes is (eg) the layer
opacity?
And Sven Neumann replied that
I would be very unhappy if changing the layer opacity from 100% to 50% would eat up a dozen or more undo-steps since each value_changed signal from the slider triggers an undo which causes another undo-step fall off the end of the undo queue.
We could think about merging consecutive undo steps into one, but this wouldn't work well for paintstrokes for example. Another possibility would be to take only those undo-steps into account that save tiles. All other undo operations should consume so little memory that they can be safely ignored.
Austin agreed with Sven, saying
Oh, sure - that's clearly a bad idea.
I was thinking of only pushing the undo when you release the slider. That doesn't help those using the keyboard to nudge the slider though.
This could be done by pushing a group start on mouse down, and closing it on mouse up, for example.
Sven posted some example code, but emphasized that
I still believe that it is a bad idea to waste undo steps for operations
that don't save any shadow tiles. How hard would it be to change the
undo system so that the number of undo steps is calculated only from
"real" undos? What about the idea of merging consecutive changes to the
layer attributes into one?
Tom Rathborne agreed.
If I'm on a machine with limited resources and have the GIMP set up for only, say, 8 levels of undo, I don't want to lose the ability to undo image changes just because I toggle a few layers on and off.
The undo history dialog should probably note which actions count as "undo levels" and which don't. Also, it would be nice to be able to force a tile-changing undo (e.g. with Ctrl-Shift-Z) ... if you do 30 layer moves/visbility changes then you probably don't want to have to hit Ctrl-Z 30 times just to undo your last pixel change. The undo history dialog helps with this but I'm not sure I want to have it up all the time.
Several other people had some ideas, and it was decided that changes to the Undo system will have to wait until Gimp 2.0. There are some new ideas for the Undo stack like micro/macro undo where Ctrl-Z will undo the last brush stroke, and Ctrl-Shift-Z will undo all of the brush strokes since a Tool change.
Jon Winters posted a query for the Gimp Developers:
I was teaching a friend of mine how to save .gif anims with the GIMP the other day. Its easy to do some pretty cool stuff but the lesson left me wondering about a possible feature.
Would it be possible to add "tweening" simmilar to what Macromedia fireworks has.
Basicly you have two layers and you can tell gimp to morph from one to the next in the animation over N amount of frames. Might also be cool if we had a menu of transition effects for use in animations. Fades, Wipes, etc...
Kevin Turner mentioned that
Xmorph can be used as a GIMP plug-in.
http://www.colorado-research.com/~gourlay/software/Graphics/Xmorph/
For bonus points, go and port this great program to a Real Toolkit ;)