How to extend the Java wrapper API?

Development
1

Hello,

I have realized that VTK Java wrapper API is a subset of the full VTK API. How is the wrapper generated and how is the selection of what will be available in the Java wrapper done?

Is it possible to add a particular method that is missing?

What I need is the vtkHardwareSelector::GetPixelInformation() method(s). I understand that there is probably an issue with returning the inner class PixelInformation instance by a value. So I tried to add a method returning just the vtkProp* which is sufficient for me. But still not able to get it into the Java wrapper API. How can I do it?

Petr

2

The Java wrappers “see” that they don’t know how to generate code for some function signatures and skip them silently. I’d look at the Wrapping/Tools/vtk*Java.* files for how Java and JNI code get generated and see if the skipped method patterns can’t be implemented.

Cc: @dgobbi

3

Hi Petr, you are correct that structs like PixelInformation aren’t wrapped. My best guess is that the GetPixelInformation() method was only meant for internal use (i.e. for use by other VTK classes, not by application code). Are you sure that you can’t solve your problem by using vtkScenePicker instead of vtkHardwareSelector?

For extending the wrappers, adding a method that returns a vtkProp* should work, as long as you re-compile the wrappers afterwards.

4

Hello Ben and David,

thank you both very much for your answers.

I have already tried the vtkScenePicker but with no success. The problem is that its API does not allow to control the cached pixel information invalidation and update. In my case after opening the window containing the vtkRenderWindowPanel the vtkScenePicker starts to periodically call the vtkScenePicker::PickRender even there is no interaction or renders happening. The whole application is stuck and no responding to any user interaction. As the purpose of using the vtkScenePicker was optimization this result in unacceptable.

That is why I decided to build a custom picker around the vtkHardwareSelector with respect to my custom interactor style. So I added a public method declaration:

vtkProp* GetPixelProp(const unsigned int display_position[2]);

into the vtkHardwareSelector.h file and its implementation into the vtkHardwareSelector.cxx. Then cmake on a fresh empty build directory and make but the introduced method did not appear in the generated vtkHardwareSelectorJava.cxx. So its also missing in the resulting vtk.jar. What could by wrong here?

Petr

5

To answer my own question myself if someone is interested:

The problem was the int array parameter. Changing the method signature to:

vtkProp* GetPixelProp(unsigned int display_x, unsigned int display_y);

solved the problem and such method appeared in the Java wrapper API.

As far as I know floating point arrays as method parameters are allowed. I did not try it yet but at least I know about several methods presented in the Java wrapper having such kind of parameters. Maybe because they are used for returning values from the method.

6

This is likely the reason here.

@ken-martin?

7

Interestingly enough, if the “unsigned” is removed, this will wrap. I’ll have to check the wrappers to see if there is a valid reason why arrays of “int” are wrapped but not arrays of “unsigned int”.

8

Java doesn’t have unsigned integer types, and after inspecting the VTK Java wrappers, I found:

  • they silently do bitwise casting between C “unsigned int” and Java “int”
  • they ignore any methods that use C “unsigned int[]”

So the behavior is inconsistent, and there is a trade off between functionality and safety. I’ll leave it to the Java experts to decide what behavior is most desirable.