On May 3, 2012, at 12:00 AM, Jeremy Selan wrote:
> That's really exciting to hear! Such a wrapper will make all the existing
> ImageBufAlgorithms more useful as well.
>
> If it's easy to add generically in the future, there's really no rush to add
> it now. We can certainly wait until later in the summer. It's just great to
> know it's possible to extend it in this manner.
I'm already half way done, I think.
The only thing I haven't figured is what happens when you have
ImageBuf src; // this one wraps a client buffer
ImageBuf dst;
dst = src;
What does that do? (a) Does dst allocate local (dst-owned) memory and copy
pixels from src? Or (b) does dst simply become a second identical wrapper of
the same client-owned buffer?
And what if dst was already a wrapper of a client buffer? Should it copy src's
pixels into dst's (client-owned) pixels? Or allocate fresh space? Or just
copy the wrapper?
This would probably be a good time to fully elaborate the behavior we expect
for dst=src for the full cross-product of choices where each of src and dst
could be { uninitialized/empty, ImageCache-backed, local IB-owned pixels,
wrapped client-owned pixels }. It's a bit ad-hoc now, but we should fully
specify it and I am open to suggestions.
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
