On Wednesday, January 6, 2010 at 22:43:44 (-0800) David MacMahon writes:
 > On Jan 6, 2010, at 17:14 , Maurice LeBrun wrote:
 > 
 > > Some centuries ago I did endow the contourer with the function  
 > > evaluator
 > > technique to deal with the issue of C vs Fortran vs whatever array  
 > > storage.
 > > Worked out nicely IMO.  Would've liked to upgrade all array- 
 > > handling functions
 > > in like fashion but so far I think it's only been done for the  
 > > plshadexx
 > > family.
 > 
 > Thanks, Maurice, I see that now in plfcont and plfshade.  I think  
 > that's just the kind of thing that would be great to have for every  
 > function that deals with >1-D data.
 > 
 > I'm willing to try my hand at adapting some other functions to use  
 > this technique.  As far as I can tell, the list of functions that  
 > could benefit from this are...
 > 
 > c_plgriddata (*)
 > c_plmesh (**)
 > c_plmeshc (**)
 > c_plot3d (**)
 > c_plot3dc (**)
 > c_plot3dcl
 > c_plimagefr (***)
 > c_plimage (***)
 > c_plsurf3d (****)
 > c_plsurf3dl
 > c_plvect (*****)
 > 
 > (*) c_plgriddata might need both a "getter" and a "setter" version of  
 > this technique.
 > (**) calls through to c_plot3dcl
 > (***) might need a "plf..." version of plMinMax2dGrid
 > (****) calls through to c_plsurf3dl
 > (*****) already has a plfvect in plvect.c, but not plplot.h!
 > 
 > My plan would be to rename the existing functions from "c_pl..." to  
 > "plf..." (or "c_plf..."?) and create new versions of the old  
 > functions that call the "plf" variant "with a particular choice for  
 > f2eval and f2eval_data" (as the c_plcont comments say).
 > 
 > The only downside to doing this, AFAICT, is that the current behavior  
 > of these functions will be somewhat slower since they will be getting  
 > data via the evaluator function and not directly from the "z[nx][ny]"  
 > array (at least for z arrays that don't need to be "pre-un- 
 > transposed" into that format).

My only suggestion is to not worry about the performance issues in function
evaluation.. after all you've got a system call somewhere down the line to
actually draw something.  In my experience that's usually where the worst (and
most intractable) bottleneck occurs.

-- 
Maurice LeBrun

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to