Re: DeepFrameBuffer::getSampleCountSlice()

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
>