On Thu, Jun 21, 2012 at 5:03 PM, Larry Gritz <[email protected]> wrote:
> The "dynamic dispatch" is kind of ugly.
It doesn't have to be. You just need a new iterator type which doesn't
have the type of the underlying pixels baked into it:
class ImageBuf::DynamicIterator // Insert disclaimer about poor naming ;-)
{
/* blah blah, same interface as ImageBuf::Iterator */
DynamicDataArrayProxy& operator* () { return m_proxy; }
};
This is also convenient from a user point of view if they really don't
care about efficiency and just want a convenient interface over their
buffer. (Aside: if we want more efficiency, conversion can happen per
pixel, or even per tile, rather than per channel. However, this does
imply some allocation behind the scenes.)
> I really don't like the idea
> of the core kernel of each function needing to be expressed twice
> (once for the templated specialization, once for dynamic dispatch).
> That seems like a nightmare to maintain.
Agreed, but this should be unnecessary if you use a dynamic dispatch
based iterator as suggested above.
> This is the way I'm leaning tonight. Can I convince you? (At this
> point, I could probably also be convinced to support the "IB for
> anything, IBA for float IB's only" approach and radically simplify.)
Ok, you can definitely convince me that supporting the cross product of
float, half, uint8 and uint16 will do for Stefan's first cut. Stefan:
please do it this way so we can get something in soon (incremental
development is A Good Thing (TM)!)
I'm not convinced that supporting all types is impossible or
even that technically expensive in extra lines of code. I still think
we should do it.
~Chris
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
