But it's not optimal for a use pattern like TextureSystem where the typical
> request is ONE tile, and the next tile it wants may not even be adjacent.

Whoops. What I pointed at look like its only the case if you read through
Imf::InputFile.  If you use Imf::TiledInputFile (like in exrinput.cpp), I
don't think you hit that buffering.

Wait, I'm not quite sure how threads play into this. Is this allocated
> framebuffer part of the ImageInptut itself? Do threads lock to use it? Or
> is this per thread, per file?

I think the per-thread part is around ImfTiledInputFile.cpp::267
Each TileBuffer has an uncompressedData ptr which is what the compressor
fills during decode.

This *should* just be a tile per thread, but it does look like it's held
over the lifetime of the ImfTiledInputFile.
Openexr-devel mailing list

Reply via email to