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