Switching part types in a MultiPartInputFile

[fnordware]

I don't know if this is really an issue, but I notice you can no longer switch from one part type to another when using MultiPartInputFile. So you get an exception doing something like this:

Imf::MultiPartInputFile multi(file);
Imf::TiledInputPart tiled(multi, 0);
Imf::InputPart scanline(multi, 0);

I had been using TiledInputPart to get some information about the tiles, even though I was using InputPart to read the pixels. Maybe I should just stop doing that.

[peterhillman]

Try calling multi.flushPartCache() between the two calls. I'm curious what information you were getting from TIledInputPart. Ideally, it should be just as easy to get that from multi.header(0) without needing to use any Part classes, or from the header of your scanline part instead.

I was unaware that code ever worked properly. *Part types ar smart pointers to an underlying cache of part objects, and there's only one permitted for each part. flushPartCache() deletes all part pointers, so you can recreate them as different types. All Part objects you have will be invalidated by that call.

[fnordware]

Ahhh, there it is. Yeah, it used to work, granted I was stuck on an old version for quite a while. I was just getting the standard tile dimensions, so no need to spin up a TiledInputPart just for that.

But now I realize that there's still a possibility I might need to switch. If I have a compatible FrameBuffer I find TiledInputPart::readTiles() to be much faster than InputPart::readPixels(), but then if a later call just has a piece of the buffer I'll have to switch back. Good to know about MultiPartInputFile::flushPartCache().