On Wed, 27 Feb 2008, Bill Skaggs wrote:
> It isn't tile *allocation* that matters here, it is tile *locking*,
> and locking only happens in one place, tile_lock() in
> app/base/tile.c.  It should be pretty straightforward for
> you to throw some debugging code in there.
> As I wrote before, though, tile locking happens *a lot*.
> Many internal operations lock tiles transiently, and also
> any time tile data is transferred to a plugin, the tile is
> locked during the process.  You might consider experimenting
> with an image small enough to fit entirely within a single
> tile (i.e., less than 64x64), if you are going to play with this
> stuff without getting flooded.

My apologies for the delay; I've had to do quite a bit of travelling 

As Bill suggested, I instrumented tile_lock().  The coffee stain plugin is 
definitely leaking tiles, and plug_in_gauss_iir appears to be the culprit, 
although I haven't dug any deeper.  Running the coffee stain 
plugin from the UI repeatably results in leaked tiles (the more stains, 
the greater the leak; at least 5 always results in a leak).  I haven't 
been able to cause leaks from the UI by using only Gaussian blur, although 
Liam has apparently observed this.

Unfortunately, I don't have the time (or Scheme experience) to dig 
further.  There doesn't appear to be a Bugzilla bug open for this; shall I 
file one against the plugins component?

Thanks to everyone for the help tracking this down!

Gimp-developer mailing list

Reply via email to