[vtkusers] java's vtkPanel does too much
jeff at cdnorthamerica.com
Sat Feb 26 07:12:34 EST 2005
Steve M. Robbins wrote:
>On Fri, Feb 25, 2005 at 08:57:12AM -0500, Jeff Lee wrote:
>>That being said, I would recommend overriding vtkPanel.java in your
>>own build area - just make sure your package name is
>>vtk/vtkPanel.java and then you can do whatever you want (make sure
>>you retain the native methods).
>I hadn't thought about doing that, but it's an option. The
>drawback is that I would have to merge any bugfixes to the
>vtkPanel.Render() method that might come along. That's my
>main motivation to have VTK provide a bare-bones base class
>that sets up a java window for VTK rendering.
There would be no bugfixes - vtkPanel.java in the vtk distribution would
be out of the picture. You would have your own Render() method, and
basically could toss out or re-implement everything but the native
methods. A bare-bones base-class would sublcass vtkNativeHook if you
wanted to provide basic Render() and Paint() capabilities and mabey an
Interactor of some sort.
>>In the long run, we should probably provide a base class with only
>>native methods which can then be extended, without the above tinkering.
>>Probably call it vtkNativeHook or something obvious, then vtkPanel is a
>>subclass. This will require changes to the c++ code in vtkJavaAwt.h to
>>change the mangled jni method signatures, but it is trivial.
>What I had in mind is for the base class to have the three native
>methods, as well as Render() and paint(). Is that what you
>had in mind, or is vtkNativeHook just the three native methods?
Just the 3 native methods - I believe that people may have different
needs from Render() and paint(). For example, if you are updating
pipeline data from multiple threads, you need finer control over Render
and paint to mutex access to the pipeline. For the simple cases where
you set up a pipeline and Render, what is in vtkPanel now is fine. For
those who want finer control, they either go through the gymnastics
above, or we provide a base class. For example,
* vtkNativePanel.java - base class with native methods
* vtkPanel.java - sublcass of vtkNativePanel, adding paint and
render capabilities, addNotify,removeNotify,Lock,UnLock - here is
what you describe as a "bare-bones" base class
* vtkCanvas.java - layers GenericInteractor
I really think that we'll never be able to write a generic Render()
method, because of the multithreading issue. One way to make it solid
is to assume that all pipeline updates come on the main event thread -
then the event thread synchronizes everything. If a developer decides
to let values change on a thread to improve ui responsiveness, then that
model would break. Another way might be to somehow synchronize pipeline
execution and rendering at a lower level. For instance, before any
filter can execute, it must obtain a lock from the renderWindow.
BTW, how you are breaking vtkCanvas?
>This is the private VTK discussion list.
>Please keep messages on-topic. Check the FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>Follow this link to subscribe/unsubscribe:
More information about the vtkusers