William Skaggs wrote:

> First, it's not clear whether you are bothered by the resources
> Gimp consumes in creating lots of layers, or by the nuisance of 
> managing them.  If it's the former, don't worry about it:  text
> layers are very lightweight, and you can create hundreds of them
> without putting much of a burden on Gimp.  If it's the latter, that's
> a different story.  At some point Gimp will get the ability to
> group layers together and collapse the groups in the Layers 
> dialog, but not quite yet.

That will be great when it happens. The short-term problem is that the
files I generate are very large (12,500 x 2500 pixels x 15 layers that
I need to access easily). Here's the example that I'm currently
working with:

-rw-r--r--   1 skod     staff    188878323 Jun 29 10:08 image.xcf

That's not a typo... In any case, stacking up a large number of text
layers on top of the layers with the graphical info I need is a bit
painful. And you can imagine that major layer manipulations on layers
that large can be very resource-intensive. A simple save of that file
takes 4 minutes and 20 seconds.

Since yesterday, I've found a couple of useful workarounds: First and
most importantly, do *not* create an empty full-image-size layer for
the text before adding it in. Doing so was required in the old Gimp,
but in the new one it makes the merge with the many tiny layers that
get created with each 2- or 3-letter annotation very slow. Instead,
just add text and repeatedly merge so that only the first new text
layer is retained, dynamically growing with each merge. This makes the
rendered text layer (significantly!) smaller than the entire image
size. The smaller dataset helps keep Gimp away from the swap thrash
that it would otherwise encounter, and makes the merges remarkably
faster, especially when first starting the annotation process. That
might be worth mentioning in the doc... Secondly, merge all the text
layers every 30 or 40 annotations, *especially* before attempting to
pan the view into a new area of the overall image- also to minimize
the overall data structure, presumably make viewport clipping easier,
and avoid the swap thrash.

Minor aside: dynamic key bindings are a godsend. I long since bound
the merge-down to lowercase L on the keyboard, and I'm getting a bit
more used to it now...

Due to the enormous datasets I need to work with, I seem to be
constantly running right up against the thrash limits of the tool
(tile cache set at 256Mb on a machine with 1Gb physical memory). It's
the nature of the work I do. The bottom line is that I'm probably
working with slightly larger images than the average user. Time for a
dual-2GHz G5 with 4+Gb of main memory, I think. Nothing succeeds like

> The best suggestion that I can think of, if you really want the old
> nasty behavior back, since your situation is probably so unusual as 
> not to be worth supporting in the core, is that it would be possible to 
> write a plug-in that would behave more or less like the old text tool:  
> you would make a selection, activate the plug-in, a dialog box would pop 
> up allowing you to type some text, and when you press Okay the text would 
> be written onto the image at the site of your selection.

I might have to work on that at some point soon, once I can get this
dadgum paying work out of the way. Coding is not my primary forte, but
I'm sure that there is some unsuspecting plug-in out there that I
could shamelessly plagiarize as a framework. My needs are pretty
simple here- black text in 10-pixel Helvetica in the currently
selected layer will always work for me, for example. It could even
auto-anchor: I don't even need to be able to move it after it is
placed. Or if I do, I'll select it as a separate action. 

Still, I'll bet that I'm not the only stick-in-the mud out here. (;-)
There are technical applications for this tool, like mine, that far
exceed what it was probably intended to do at the outset- and are
probably orthogonal to the original authors' intentions. And there are
probably other nerds like me that will run aground on this, and will
wish for the old nasty behavior. If it isn't too painful, it might
be worth considering a backwards compatible mode, even though it
is ugly...

The true magic of the Gimp is that it works as well as it does on
these enormous datasets. Thanks for the quick responses! All help is


Scott Griffith
9745 Steeplechase Drive
Franktown, CO 80116
303-660-2542 fax

Gimp-developer mailing list

Reply via email to