Gimp Traffic #23 For 19 Jun 2000

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?

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?

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.

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.

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.

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...

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 ;)