On 2008-03-18 14:18-0400 Hezekiah M. Carty wrote: > Attached is a patch which adds coordinate transform support to > plimagefr, similar to what is available in the plshade*, plcont, plmap > and plmeridians functions. > > This patch is rather large, mainly because it removes a lot of code. > > - The dev_fastimg rendering path has been removed. This was only used > [1] in the xwin driver, and does not work well with the custom > coordinate transform support added to plimagefr. > - The plimage functions have been restructured and hopefully > simplified in this process. > - An off-by-one bug was fixed during the code restructuring, which > would sometimes lead to a missing row and/or column of (scaled) pixels > in the plotted image. > - api.xml has been updated (hopefully correctly) to include the > addition of pltr and pltr_data parameters to plimagefr > - The interface to plimage has remained the same, only plimagefr and > related internal functions have been altered > > [1] - There one file which I have found which references dev_fastimg > still: sys/win32/msdev/src/win3.cpp - I have not changed this as I > have no way to test the result. It should just be a matter of > removing the appropriate line. Similarly, examples/python/qplplot.py > calls plplot.plNoBufferNoPixmap() which looks like it calls one of the > removed functions from src/plimage.c. This function was removed as > its only purpose, as far as I can tell, was part of the fastimg > rendering path. > > This patch should apply cleanly against the latest PLplot SVN. It > builds cleanly on my Debian Sid system building the C library and the > Cairo rendering devices. C example 20 works as expected for xwin, > xcairo and pngcairo. > > I realize that this is a large patch. I can break it down in to > pieces if needed, but this is a complete patch as-is for the C portion > of PLplot. None of the included language bindings have been altered. >
Thanks Hez. I am not competent enough with driver/core C code to comment on the specifics of your patch, but I would like to make some general comments. (1) sys/win32/msdev/src/win3.cpp is no longer maintained or used so you don't have to worry about it. To give you the historical background, it is part of svn for now so that people can study that historical windows driver code, but we no longer use it. In fact all of sys/win32 is excluded from our release tarballs since the new CMake build system (which works well on Windows) supersedes that old hand-crafted Windows-only build system, and there are a number of devices that work on Windows now, including the windows-only drivers/wingcc.c device driver which supersedes sys/win32/msdev/src/win3.cpp. (2) It's a fact (and not criticism) that your patch hits a substantial fraction of the areas of PLplot (e.g., drivers/xwin.c, src/plimage.c, examples/python/qplplot.py) which currently do not have much core developer support for a variety of reasons. Developers have lost some interest in drivers/xwin.c because the fonts currently look bad, and nobody has cared enough to fix that so far. src/plimage.c was donated by core developer Joao Cardoso who has not been heard from for several years now. examples/python/qplplot.py was donated by an external developer who did not maintain it afterwards. So I think we all appreciate your interest in plimage.c and want to encourage it. That said, I think you should not remove the dev_fastimg rendering path unless we find that rendering path really does not provide much of a speed increase. The reason I am concerned is Joao Cardoso introduced that rendering path (IIRC) because he was not satisfied with the speed of the example 20 results for our premier device at that time (early 2000's), xwin.c. Now, computers are much more powerful so speed is not as important an issue, but nevertheless, fast results are probably something we should not give up lightly and which we should positively encourage for the new devices which in other respects (such as font handling) are superseding xwin.c. Currently, you have stated above that that the dev_fastimg rendering path does not work well with the custom coordinate transform support added to plimagefr. I encourage you to fix that issue (assuming dev_fastimg rendering really is faster for xwin.c). I realize that is probably a lot of work, but it does make your patch much less obtrusive and prepares necessary infrastructure to propagate the dev_fastimg rendering to other devices. (3) I suggest you add a page or more to x20c.c to show an example (or examples) of how to use the new features you have added for plimagefr. The reason I suggest that change is new PLplot API that is not illustrated with one of the examples tends to go unused and untested by our developers and users. Of course, keep the old x20c.c pages as well which show plimage examples. Thanks again for your interest in improving PLplot. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
