Re: [Vxl-maintainers] Proposed change to vil_memory_chunk

[Ian S. <sc...@im...>]

In principle, I can't see a problem in vil itself. Are you planning to 
create a ABC and have the existing vil_memory_chunk derive from it?

vil_memory_chunk it also used by vil3d, so that would need to be updated.

I'm a little concerned with the impact on vil/io. If you send me the 
patch for your update to vil, I will look into the impact on vil/io.  I 
assume that vil/io wouldn't need to support your OpenCV-memory-managed 
image. Maintaining backwards compatibility with the vsl binary IO of 
existing image files is of paramount importance to us.

Ian.

On 06/02/2012 17:45, Matt Leotta wrote:
> All,
>
> I'd like to propose a small change to vil_memory_chunk.  I figured it
> was worth a brief discussion since vil_memory_chunk is such a primary
> and critical part of vil.  The proposed change is to make the private
> data members of vil_memory_chunk protected, and to make the following
> member functions virtual: data(), const_data(), and set_size().  The
> virtual functions should have minimal performance impact because
> vil_image_view almost always accesses memory via the top_left_pointer
> instead of through the vil_memory_chunk.
>
> This purpose of this change is to allow for the creation of classes
> derived from vil_memory_chunk that handle memory differently.  The
> specific use case I have in mind is transfer of ownership of memory from
> an outside source to vil.  Currently vil_image_view supports two types
> of memory usage:
>
> 1) vil_image_view allocates it's own memory and reference counts using a
> shared vil_memory_chunk which is deleted when all vil_image_views
> release the memory chunk.
>
> 2) vil uses a raw pointer to point to someone else's memory.  No
> reference counting or memory management is used.
>
> The proposed change will allow something in between.  Suppose I have
> image memory allocated by something else (say OpenCV, OpenCL, NumPy,
> etc) and that something has it's own reference counting scheme.  I can
> create a special vil_memory_chunk that contains this 3rd party memory
> and decrements the 3rd party reference count (instead of deleting
> memory) when the vil_memory_chunk is deleted.  This effectively allows
> the transfer of referenced counted memory ownership from a third party
> source to vil.
>
> Can anyone see a reason I should not make the proposed changes?
>
> Thanks,
> Matt
>