#1 will be very helpful for the socketInput class because it has to accept an
incoming connection when it is opened, which is not something that can be
easily redone. the multiple calls to open caused me to add some
less-than-elegant code to guess when I truly ought to establish and/or close
the connection.
-chad
On Apr 2, 2012, at 11:56 PM, Larry Gritz wrote:
> Anybody have opinions on this?
>
> Good idea? Bad idea? You like?
>
> -- lg
>
>
> On Mar 27, 2012, at 1:10 AM, Larry Gritz wrote:
>
>> In the continuing quest to make create/open more efficient, here are two
>> minor API changes:
>>
>> 1. In almost all uses, an app calls ImageInput::create() to get an II*, then
>> immediately calls in->open() to open the file, which, if you think carefully
>> about the fact that create() does an open to verify that the II is capable
>> of opening the file, means that open() ends up getting called twice. Very
>> wasteful. So the first change is that we change the ImageInput::create()
>> function prototype to include a do_open flag -- if true, it returns the file
>> already opened, not needing a separate call to open(). If false (and this
>> is sometimes useful), it behaves as before, returning an ImageInput* that
>> can be opened, but is not presently. This also simplifies the source of
>> apps just a bit, since the common "create & open" sequence can now be
>> accomplished with just a call to create.
>>
>> 2. To further streamline, we add a new optional method,
>> ImageInput::valid_file(filename), which returns true if the named file
>> appears to be a valid file of that format (in a way that's less expensive
>> than doing a full open and header read -- for example, just checking the
>> first few bytes that contain a "magic number" or whatever). Not all plugins
>> supply this function, and it's not required; the ones that do must return
>> true for supports("valid_file"). I've included implementations for OpenEXR
>> and TIFF that are considerably less expensive than a full header read.
>>
>> The combination of these should reduce a lot of the overhead for identifying
>> which type of ImageInput is appropriate for a given file and creating it,
>> generally avoiding at least one redundant open and header read for exr and
>> tif files.
>>
>> Note that this is a break in ABI compatibility. It will not be merged into
>> 1.0, only master, and so will be a 1.1 feature. I believe that it should be
>> source-back-compatible, however.
>>
>>
>>
>> You can merge this Pull Request by running:
>>
>> git pull https://github.com/lgritz/oiio lg-validfile
>>
>> Or you can view, comment on it, or merge it online at:
>>
>> https://github.com/OpenImageIO/oiio/pull/265
>>
>> -- Commit Summary --
>>
>> * Change ImageInput::create() to allow the caller to request the file to be
>> returned already opened.
>> * Make OpenImageIO::geterror() return a thread-specific error, so multiple
>> threads calling ImageInput::create() can't clobber each other's error
>> messages.
>> * Add ImageInput::valid_file() and supports("valid_file") -- test whether a
>> file is a valid file of that format, cheaper than a full open.
>>
>> -- File Changes --
>>
>> M src/doc/imageinput.tex (162)
>> M src/doc/imageioapi.tex (3)
>> M src/doc/writingplugins.tex (17)
>> M src/iconvert/iconvert.cpp (2)
>> M src/igrep/igrep.cpp (13)
>> M src/iinfo/iinfo.cpp (16)
>> M src/include/imageio.h (52)
>> M src/libOpenImageIO/imageio.cpp (25)
>> M src/libOpenImageIO/imageioplugin.cpp (51)
>> M src/libtexture/imagecache.cpp (2)
>> M src/oiiotool/printinfo.cpp (13)
>> M src/openexr.imageio/exrinput.cpp (20)
>> M src/python/py_imageinput.cpp (4)
>> M src/tiff.imageio/tiffinput.cpp (34)
>>
>> -- Patch Links --
>>
>> https://github.com/OpenImageIO/oiio/pull/265.patch
>> https://github.com/OpenImageIO/oiio/pull/265.diff
>>
>> ---
>> Reply to this email directly or view it on GitHub:
>> https://github.com/OpenImageIO/oiio/pull/265
>>
>> --
>> Larry Gritz
>> [email protected]
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected]
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> [email protected]
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
