[vtkusers] java's vtkPanel does too much

[Steve M. Robbins]

On Wed, Mar 02, 2005 at 07:32:39AM -0500, Jeff Lee wrote:

> >>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

Sure, the locking has to be on a Canvas.  However, the native methods
could take the Canvas as an argument, rather than operating on its
"self" object (the second native method argument).

Not that I think that would be a useful design, on reflection.

OK, so vtkNativePanel derives from Canvas and has 3 native methods.
To make it functional, it could also implement paint().  This would
satisfy anyone who just wanted to set up a VTK pipeline and have it
render in java.  

> >>  * 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

I suppose, though I don't see the need for this middle layer: any
reasonable Canvas subclass should implement a useable paint(),
shouldn't it?  The vtkNativePanel already has Lock and Unlock.



> >>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.

Yes, of course.  Any threaded VTK program has to deal with that
fact.

However, I still don't understand what you mean by "we'll never be
able to write a generic Render() method, because of the multithreading
issue".  It seems to me that all that's required is that paint() invoke 
rw.Render().  What else is there?

-Steve