Is there any hope for IlmThread being retired in favor of OpenMP, TBB, or the C++ 11 std threads library?
On Tue, Apr 2, 2013 at 6:23 PM, Peter Hillman <pet...@wetafx.co.nz> wrote: > > 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<https://lists.nongnu.org/mailman/listinfo/openexr-devel> > -- I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it.
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
