[vtkusers] [vtk-developers] [EXTERNAL] vtk 6.3 and vtk 7.0

Wed Jul 1 10:02:38 EDT 2015

I am fairly novice in Java so I apologize if this sounds naive. Doesn't
Java do its own memory management and actually automatically move data from
one memory location to another? How does one map a Java array to a C++
array and make sure that it is not moved and of course garbage collected?

Interfacing to numpy arrays works fine because Python provides a buffer
interface where it is guaranteed that a Python object holds a buffer (an
array essentially) that does not move. The Python wrappers simply expose a
functionality that allows the C++ layer to get a pointer from a buffer
object. Then this array can simply be passed to any C++ method that takes
an array.

This is the only efficient way of sharing array between the two layers.
Doing a "zero copy" array where each array access such as GetTuple() goes
through a Java layer would be terribly inefficient and impractical.

Best,
-berk

On Wed, Jul 1, 2015 at 9:00 AM, Alexandre Dufour <adufour at pasteur.fr> wrote:

> Hi,
>
> I am not familiar with the nitty-gritty of the wrapping aspects, but as a
> Java-based user (icy.bioimageanalysis.org), I believe the issue has to do
> with the fact that transferring some Java array down to a vtk structure
> (via any setJavaArray() method) always(?) implies a copy of said structure
> down to the C++ layer, hence the issue of duplication. This typically
> happens when your data/image structure is first handled on the Java side,
> then passed over to VTK for rendering purposes.
>
> Does this make sense? Is there any way around this? I doubted that for a
> while, but then remembered the good old Unsafe class in Java that might
> help do “dirty but efficient” communication…
>
> My 2 (unexperienced) cents. Very excited about this anyhow!!
>
> Alexandre
>
> *—*
> *Alexandre Dufour, PhD*
>
> *Senior Research Fellow @ **Biological Image Analysis*
> <http://www.bioimageanalysis.org>* group*
> *Institut Pasteur* <http://www.pasteur.fr/en>*, **Dpt. of Cell Biology &
> Infection, **Paris campus (France)*
> *CNRS UMR 3691 “Pathological and Physiological Cell Dynamics” *
>
> *Meet **Icy* <http://icy.bioimageanalysis.org>*, the next-generation
> Bioimage Informatics platform*
>
> On 30 Jun 2015, at 15:46, Utkarsh Ayachit <utkarsh.ayachit at kitware.com>
> wrote:
>
> Gerrick,
>
> The *new* zero copy design literally started a week or two ago, so it is
> in its infancy, but I will write a design document soon. It doesn't however
> do anything new for access through wrapped languages. What exactly is your
> use-case. I am not sure what aspect is lacking in the current
> implementation in that regard.
>
> Utkarsh
>
> On Mon, Jun 29, 2015 at 6:04 PM Gerrick Bivins <
> Gerrick.Bivins at halliburton.com> wrote:
>
>> “* deprecate the existing zero copy array API in preparation for a
>> significant refactoring that will come in 7.0. The refactor will make zero
>> copy arrays both simpler to use and perform better.”
>>
>>
>>
>> Where can I find more information about this?
>>
>> Does the “Zero copy array refactor” expose this framework to wrapped
>> languages, Java in particular?
>>
>> Currently the duplication of data is one of the things holding up
>> adoption of VTK in our application.
>>
>>
>>
>> Gerrick
>>
>>
>>
>> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On
>> Behalf Of *David E DeMarle
>> *Sent:* Monday, June 29, 2015 9:42 AM
>> *To:* vtkdev; vtkusers at vtk.org
>> *Subject:* [EXTERNAL] [vtk-developers] vtk 6.3 and vtk 7.0
>>
>>
>>
>> Hey vtkers,
>>
>>
>>
>> We are hoping to do a vtk 6.3 release in the next couple of weeks and
>> then immediately follow that up with a 7.0 release.
>>
>>
>>
>> We'd are putting out a 6.3 out in order to:
>>
>> * deprecate the existing zero copy array API in preparation for a
>> significant refactoring that will come in 7.0. The refactor will make zero
>> copy arrays both simpler to use and perform better.
>>
>> * package up all of the progress that has been made in the master
>> branch's OpenGL2 surface and volume rendering. The vtkpython binaries will
>> switch over to using the OpenGL2 back end this release.
>>
>>
>>
>> Please let us know if you have any feedback, critical bugs especially,
>> and developers let us know if there is any work you have in a partially
>> finished state that we should be sure to get into 6.3.
>>
>>
>>
>> If all goes well we'll have a release candidate for 6.3 next week.
>>
>>
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>   This e-mail, including any attached files, may contain confidential
>> and privileged information for the sole use of the intended recipient. Any
>> review, use, distribution, or disclosure by others is strictly prohibited.
>> If you are not the intended recipient (or authorized to receive information
>> for the intended recipient), please contact the sender by reply e-mail and
>> delete all copies of this message.
>>  _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>  _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20150701/ce2a5993/attachment.html>