On Fri, Nov 12, 1999 at 02:51:04PM +0100, Ewald R. de Wit wrote:
> > This has optimal performance when the image data is on disk, and there is
> > precisely enough memory spare to store a duplicate image in memory, and
> > assuming that your disk is very slow and your memory is very fast, which
> > is probably true on a typical PC architecture.
> Right. This would be the typical case that I'm interested in.

Great. For a specific operation you can make really great speed-ups like
this, and I wish you luck with it (though I really wonder if there
isn't already a perfectly good free solution somewhere). Tile behaviour
won't win much (anything?) in this case, though some image formats
like TIFF provide for tiling on disk...

Gimp doesn't often do this, so perhaps Gimp wasn't the place to look for
examples in doing this kind of operation.

[Both images in memory]
> I don't follow this. L1/L2 cache is being trashed if you use non-tiling
> images??

Yeah, think about it, or wait for someone who does this stuff for real
to step forward. I am tired and not in the mood for drawing ASCII Art
diagrams of memory access. No offense.

[Too little memory example]
> One doesn't want to encounter this case in an interactive application
> whether you use tiling or non-tiling images.

Yes, but in one (tiling) it would suck, and in the other it either
won't work or will suck much worse. So all other things being equal
this is a vote in favour of tiling.

[Sub image example]
> Right, for out-of-mem images this is an example were the tiling
> comes in handy.  

Yes, this example supports tiling too. 

> > So Ewald, unless your critique of the Gimp tile system is going to
> > get a bit more sophisticated I'd prefer to see time spent on fixing
> > the thing to not leak tiles onto disk, rather than trying to take
> > us back down to the level of Paint Shop Pro 4.0
> Well I'm writing an image processing library right now and I was
> wondering whether it would be better of with or without a tile system.
> That's why I was studying the way Gimp is doing things. No need for
> getting upset about me wondering about the workings of it.

That's understood now, I was more defending tiling as a practise than
Gimp's implementation. I thought you were suggesting a return to 0.54s
amateurish "malloc(width * height * depth)" approach. For your app
this might be the appropriate thing to do of course...

> Anyway, I won't be using tiling myself as images that don't fit into
> memory are of little concern to me. Like you said earlier, photoshop
> doesn't handle insanely huge images at all so it's just not an
> immediate need for the vast majority of people. This is a matter of
> setting priorities (what to optimize and what not).

Um, no, I said Photoshop won't load OUR huge images, these images are
not just huge because we have too much disk - they're Tiled JPEG TIFF
arranged in pyramid format for tile-at-a-time network access via a
thing called the Internet Imaging Protocol. Gimp only loads this stuff
because I (re)wrote Gimp's TIFF loader (and recompiled my libtiff)

If I dig out a 5Kx5K cartoon, and load it into a similarly specified
PotatoShop I can do some comparisons, but I'd guess it will kick
Gimp's arse. However, it will do so while using tiles, COW, and all
the same tricks as Gimp, just better. Tiling isn't a crazy Gimp hack
as you may have thought -- it's The Right Thing To Do in an app of
this kind.

Now, perhaps we can steal some of your nice fast algorithms for our
nasty complicated application :)


Reply via email to