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 <https://github.com/openexr/openexr/blob/develop/OpenEXR/IlmImf/ImfTiledInputFile.cpp#L267>. 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 Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
