Since it is neither particularly inefficient, nor complex, to do this:
Slice s = buffer.getSampleCountSlice();
s.base = mynewbase;
buffer.insertSampleCountSlice(s);
I'd vote for keeping it the current way. That would allow
insertSampleCountSlice to do more complex things than it currently does
in the future without breaking the API.
On 09/10/13 03:58, Richard Hadsell wrote:
Thanks. That seems like a reasonable workaround. If it is okay to
modify the _sampleCounts Slice that way, I guess it would be safe to
expose a non-const pointer or reference to it. Is there any chance
this could get into future release? It would be more efficient than
saving a copy of the Slice or constructing a new one for each change.
On 10/07/2013 06:29 PM, Peter Hillman wrote:
There's no harm in calling insertSampleCountSlice multiple times - it
should be efficient, as it doesn't search a map to find the channel
you are inserting, as regular channels do.
You should be able to do this:
Slice sampleCountSlice( UINT , mybase , ... );
buffer.insertSampleCountSlice( sampleCountSlice );
sampleCountSlice.base = mynewbase;
buffer.insertSampleCountSlice( sampleCountSlice );
On 08/10/13 10:33, Richard Hadsell wrote:
Why is there only a const function
DeepFrameBuffer::getSampleCountSlice() that returns a 'const Slice &'?
I want to allocate a sample count buffer that only spans a single
tile, and then modify the slice for each tile that I read one at a
time. This works fine for channel slices that I access using
findSlice. Is it safe to const_cast the return from
getSampleCountSlice, or is there a fundamental reason why I cannot
modify that slice's base?
_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel
