[vtkusers] java's vtkPanel does too much

[Jeff Lee]

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?

Regards,
Jeff

>-Steve
>_______________________________________________
>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:
>http://www.vtk.org/mailman/listinfo/vtkusers
>
>
>  
>