[vtkusers] java's vtkPanel does too much

[Jeff Lee]

Steve M. Robbins wrote:

>Hi Jeff,
>
>On Sat, Feb 26, 2005 at 07:12:34AM -0500, Jeff Lee wrote:
>
>  
>
>>>>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
>>    
>>
>
>Does this derive from AWT Canvas?  Arguably, it doesn't have to; 
>you could have vtkPanel derive from Canvas and have a vtkNativePanel
>as an instance variable.
>  
>
It has to be an AWT Canvas because it does low-level locking on the 
canvas's drawingSurface, among other things.  See vtkJavaAWT.h

> 
>  
>
>>   * 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.  
>>    
>>
>
>I don't understand what "multithreading issue" you're driving at.
>The vtkPanel.Render() method surrounds the actual rendering (rw.Render())
>inside Lock()/UnLock() calls.  Isn't that enough to allow calling
>vtkPanel.Render() from any thread?
>  
>
No.  Vtk is not thread safe.
Regards,
Jeff

>
>
> 
>  
>
>>BTW, how you are breaking vtkCanvas?
>>    
>>
>
>I simply compiled and ran some of the example code from ij-plugins
>(http://ij-plugins.sourceforge.net/vtk-examples).  I was just
>playing around and don't have detailed notes.  I was using
>VTK 4.2.  I'll try again and see if I can reproduce the problem.
>I was mainly wondering whether the interactor stuff was generally
>known to be broken with java; if not, I assume I have a bad
>set-up in some respect.
>
>-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
>
>
>  
>