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 lately. 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! -Brennan _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
