Re: A handle graphics project has started.

 Hi, Nick and everyone.

 My brother has a native implementation of handle graphics to Octave, he is now rewriting it.
 I've got a copy of it....though.... 
 And this implementation are inside Octave.  

 We are in the re-thinking box for the moment, since there are some issues that has to be worked out. 
 There should be an iterative way, so the solution how to use and implement h-g objects will suit all parties that are involved (developers and users).

 They are whether to make a generic handle graphics within Octave, which is a base for all visualisation applications out there, 
 or make 100 implementations of handle graphics support within 100 visualisation applications.  
 Of course there will be a common way to make these 100 implementations, but what a waste of work? 

 We are actually facing one problem here, if alll handle graphic support should be a part of any visualisation application. 
 This would lead to the fact that gnuplot, oplot, kv, knewplot, qmatplot will actually consists of the same handle graphics library. 
 I believe that this a waste of time...It can be done, but this is pretty much like shooting yourself on the foot, I guess.

 Handle graphics objects are not created until you are using gca, figure, plot (line), surf (surface).
 plot command are actually calling a line-command, and surf are calling the surface-command. 
 Remember that line, surface and patch are h-g commands, which creates h-g objects with the same name.
 
 If you are using surface, patch or line without any arguments, a plot will appear with default values.  

 Maybe Octave should have builtin handle graphics objects, with default values? 
 H-G objects will not occupy any memory until handle graphic system has been "initialised" by running gca, figure, or other h-g related commands. 
 
 We can divide handle graphics into two groups; read/writeable and read only. 
 There are three properties in handle graphics, that can use a lot of memory, and these are: 

 1. line-object:  XData, YData and ZData : vectors
 2. patch object: XData, YData and  ZData : matrices 
 3. surface object: XData, YData and  ZData : matrices

 Imagine we are making this plot with large datasets: 
 subplot(311); lh = plot3(x,y,z); subplot(312); ph=patch(xp,yp, zp); subplot(313); sh = surface(xs,ys,zs);
 The values of their XData, YData and ZData are not inside Octave now. 
 But they will be if you decide to run: plot3_struct = get(lh); patch_struct = get(ph); surf_struct = get(sh). 
 These functions will in fact cause multiple copies of each of the datasets anyway, regardless of an internal or external  handle graphics implementation. 
 
 This will mean that we'll have wrapper functions, that will utilize all of the powerful tools that each visualisation application have. 
 These wrapper functions is the "interface" between octave handle graphics and property values of  visualisation applications.
  
 Remember that the visualisation application doesn't need the (REAL THING of) handle graphics inside. 
 Handle graphics is an abstraction of all properties that a visualisation application are using.  
 Therefore, will this strategy also be usable with Gnuplot. I guess the gnuplotters liked that sentence....;-) 

 Design of handle graphics support to Octave, should satisfy these conditions:

 1. Be generic, and therefore be a base for all handle graphics objects to come.
 2. Consider performance vs. memory usage.
 3. Ease to maintain this "package". 
 4. If Visualisation applications support handle graphics at all, it should be possible to modify values of handle graphics objects. 
 5. Point 4, should also be possible if you make a pretend-to-be-a-hg-editor inside visualisation application. 

 My brother will be online during midnight and he will tell you more about his strategy, since he is doing a (thesis) dissertion at bachelors level on the subject. 
 
 Cheers, 

 Ole J.