On 3 April 2013 00:01, Peter Hillman <pet...@wetafx.co.nz> wrote: > There is a mechanism for DeepScanlineInputFile/Part that allows two separate > threads to read scanlines more efficiently. Instead of calling > setFrameBuffer, you can call rawPixelData from each thread (locking to > ensure the calls serialise) then call the versions of readPixelSampleCounts > and readPixels that take a FrameBuffer and the rawdata. This allows > simultaneous decompression/pixel copying of data. It has to be used with > care, and is probably only useful as a last resort for maximising > performance.
OpenSlide has a nice solution to this: they lock for the tile read, but do their jp2k decompress outside the lock. So reading with several threads doesn't cause terrible IO thrashing, but does give a good speedup. As you say, for best performance you need something in the client to order reads and to prevent repeated decompression between threads. It's probably sensible to keep that outside the core library. John _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
