On 04/03/2013 12:25 PM, Larry Gritz wrote:
(This does assume that IlmThread's Lock mechanism is compatible with the way
your threads are created).
I'm not sure I followed that statement. Huh?
I'd understood that there are some high performance threading libraries
which aren't pthread compatible. On Posix systems, for example,
IlmThread::Mutex::lock() calls pthread_mutex_lock(). This might not
actually lock the thread if it is some exotic thread implementation
unrelated to pthread. If you are using pthread, windows threads, or
better still the IlmThread library, all will be well.
My threads do each set up separate frame buffers. It's too bad the framebuffer
isn't an argument to readPixels/readTiles rather than set by a separate call to
setFrameBuffer
There'd be little point in passing a framebuffer to readpixels unless
the file read is separated from decoding the pixel data, in the same way
that the rawpixel approach does in deepscanlines.
Under the hood, it might as well just do a lock, setframebuffer,
readpixels, unlock. It might be worth extending the deepscanline
rawpixel approach to regular images
As always, the fastest way to read EXRs is to read as much of the file as
possible in a single call, and let the EXR library manage its own threads.
Ha ha, yeah, until you have 2 TB of image files you're accessing incoherently.
Oh dear. Perhaps it might be worth the effort of implementing some
super system with a single thread that handles calls to
readPixels/readTiles, with other threads post requests to that and wait
for the reply. That thread can reorder the requests to reduce the amount
of file seeking that takes place. I'm guessing that file seeks are far
more expensive than decoding pixels.
Rather you than me :-)
Peter
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
