Re: [Plplot-devel] plimagefr coordinate transform support - complete
I forgot to CC the list... On Tue, Mar 18, 2008 at 4:32 PM, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > 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. Thanks for the feedback Alan. I am learning more and more about the PLplot internals as I go along, whether I want to or not :-) The changes I have submitted so far are important for my plotting needs, and I hope that they will be useful to others as well once they are complete. > (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. Sounds good - I will ignore that portion of the source tree for the purposes of this patch. > (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. dev_fastimg is definitely faster than the slow rendering path for the xwin driver. I tested example 20 with both 5.9.0 and plplot-svn+my patch, and (using xwin) 5.9.0 is certainly less CPU intensive. That said, from what I understand reading the xwin.c code, dev_fastimg assumes that the image is made up of homogeneously sized unrotated rectangular boxes. So while I think it could be adapted for non-transformed images, it would not work for images with most coordinate transforms. The patch I submitted does all of the drawing with plfill, which makes plimage much simpler and more flexible, and unfortunately noticeably slower. For the time being, would you accept a patch with the dev_fastimg rendering path code left in place, but unused? I would comment out the code in a few places, and leave it untouched but unused in others. The changes required to keep it in use for cases where it will be of use will take me a while as I will have to get to know the PLplot internals better. My initial move to use dev_fastimg would be for non-transformed images only. So calls to plimage would use the dev_fastimg path when available, but calling plimagefr directly would only use dev_fastimg if the pltr callback is NULL. Otherwise plfill would still be used for each transformed pixel. To sum up, I would like to submit patches in the follow steps: (1) Add coordinate transform to plimagefr and disable the dev_fastimg rendering path, but without removing the dev_fastimg code. (2) Update dev_fastimg to work with the updated plimagefr, but only use it for non-transformed images. (3) Update example 20 with some examples of what plimagefr can do, with pages to illustrate both fixed color ranges and coordinate transformations. Does this sound like a reasonable compromise? Taking this on over a few steps would be much easier for me since it
Re: [Plplot-devel] plimagefr coordinate transform support - complete
On 2008-03-19 10:59-0400 Hezekiah M. Carty wrote: > To sum up, I would like to submit patches in the follow steps: > (1) Add coordinate transform to plimagefr and disable the dev_fastimg > rendering path, but without removing the dev_fastimg code. > (2) Update dev_fastimg to work with the updated plimagefr, but only > use it for non-transformed images. > (3) Update example 20 with some examples of what plimagefr can do, > with pages to illustrate both fixed color ranges and coordinate > transformations. > > Does this sound like a reasonable compromise? Hi Hez: Actually after sleeping on it, I am leaning toward saying do (1) (with code commentary where you do the disabling in plimage.c, xwin.c, etc., about why it was necessary) and leave (2) as a would-be-nice rather than a requirement since it sounds like it might be a lot of work which you could more productively spend on the OCaml bindings, for example. However, I don't feel right making this decision alone because I haven't used -dev xwin or the plimage capability for my own PLplot needs, and somebody who has more of a vested interest in those parts of PLplot may feel a lot stronger about their speed than I do. Thus, I am going to need advice/help from the other PLplot core developers on the decision about (1) and (2) so please step forward, guys, and comment. (3) sounds good! 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/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Jerry Bauck has joined the core team of PLplot developers
On behalf of the PLplot core team of developers (see https://sourceforge.net/project/memberlist.php?group_id=2915 for a list of members of that team), I am happy to announce that Jerry Bauck has recently joined our team. Jerry is already well-known here as the long-term developer of the Ada bindings and examples for PLplot. Welcome to the core team, Jerry! 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/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plimagefr coordinate transform support - complete
On Wednesday, March 19, 2008 at 10:14:30 (-0700) Alan W. Irwin writes: > On 2008-03-19 10:59-0400 Hezekiah M. Carty wrote: > > > To sum up, I would like to submit patches in the follow steps: > > (1) Add coordinate transform to plimagefr and disable the dev_fastimg > > rendering path, but without removing the dev_fastimg code. > > (2) Update dev_fastimg to work with the updated plimagefr, but only > > use it for non-transformed images. > > (3) Update example 20 with some examples of what plimagefr can do, > > with pages to illustrate both fixed color ranges and coordinate > > transformations. > > > > Does this sound like a reasonable compromise? > > Hi Hez: > > Actually after sleeping on it, I am leaning toward saying do (1) (with code > commentary where you do the disabling in plimage.c, xwin.c, etc., about why > it was necessary) and leave (2) as a would-be-nice rather than a requirement > since it sounds like it might be a lot of work which you could more > productively spend on the OCaml bindings, for example. > > However, I don't feel right making this decision alone because I haven't > used -dev xwin or the plimage capability for my own PLplot needs, and > somebody who has more of a vested interest in those parts of PLplot may feel > a lot stronger about their speed than I do. Thus, I am going to need > advice/help from the other PLplot core developers on the decision about (1) > and (2) so please step forward, guys, and comment. I use -dev xwin extensively (and its client, plframe) but not plimage. That said, doing (1) and leaving/documenting (2) as a nice-to-have sounds fine to me, unless someone can make a case otherwise. Ideally someone would play with dev_fastimg vs !dev_fastimg and see if there's a noticeable difference on mondern hardware. I'm sure many here have seen hardware advances make irrelevant some "optimizations" done previously, or at least mitigate performance concerns. For example, the X driver was first developed on 8-bit r/w color displays and sharing a single r/w colormap was the norm. If this didn't suffice for the application, a custom colormap could be used (which I never liked very much). Seems so quaint now. :) But when I went to 16 or 24 bit r/o colormaps on a Linux box years later, the performance degradation of swapping out colors really didn't seem to matter much. One of these days I'd like to give the xwin driver a bit of housecleaning, starting with chopping out the custom colormap support that was never really used anyway. -- Maurice LeBrun - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plimagefr coordinate transform support - complete
On Wed, Mar 19, 2008 at 01:12:24PM -0500, Maurice LeBrun wrote: > On Wednesday, March 19, 2008 at 10:14:30 (-0700) Alan W. Irwin writes: > > On 2008-03-19 10:59-0400 Hezekiah M. Carty wrote: > > > > > To sum up, I would like to submit patches in the follow steps: > > > (1) Add coordinate transform to plimagefr and disable the dev_fastimg > > > rendering path, but without removing the dev_fastimg code. > > > (2) Update dev_fastimg to work with the updated plimagefr, but only > > > use it for non-transformed images. > > > (3) Update example 20 with some examples of what plimagefr can do, > > > with pages to illustrate both fixed color ranges and coordinate > > > transformations. > > > > > > Does this sound like a reasonable compromise? > > > > Hi Hez: > > > > Actually after sleeping on it, I am leaning toward saying do (1) (with code > > commentary where you do the disabling in plimage.c, xwin.c, etc., about why > > it was necessary) and leave (2) as a would-be-nice rather than a > requirement > > since it sounds like it might be a lot of work which you could more > > productively spend on the OCaml bindings, for example. > > > > However, I don't feel right making this decision alone because I haven't > > used -dev xwin or the plimage capability for my own PLplot needs, and > > somebody who has more of a vested interest in those parts of PLplot may > feel > > a lot stronger about their speed than I do. Thus, I am going to need > > advice/help from the other PLplot core developers on the decision about (1) > > and (2) so please step forward, guys, and comment. > > I use -dev xwin extensively (and its client, plframe) but not plimage. That > said, doing (1) and leaving/documenting (2) as a nice-to-have sounds fine to > me, unless someone can make a case otherwise. Ditto. > Ideally someone would play with dev_fastimg vs !dev_fastimg and see if there's > a noticeable difference on mondern hardware. I'm sure many here have seen > hardware advances make irrelevant some "optimizations" done previously, or at > least mitigate performance concerns. I agree. If it turns out that dev_fastimg really is useful then I would encourage you to think about (2), i.e. still using dev_fastimg for the no-transform case at least. Without the tests it is hard to comment though. > For example, the X driver was first developed on 8-bit r/w color displays and > sharing a single r/w colormap was the norm. If this didn't suffice for the > application, a custom colormap could be used (which I never liked very much). > Seems so quaint now. :) But when I went to 16 or 24 bit r/o colormaps on a > Linux box years later, the performance degradation of swapping out colors > really didn't seem to matter much. One of these days I'd like to give the > xwin driver a bit of housecleaning, starting with chopping out the custom > colormap support that was never really used anyway. If you can find the time, it sounds like a good idea! I still extensively use the xwin driver. I prefer it over the more sophisticated gnome driver for example for many purposes because it is quick and clean. Andrew P.S. Hez, is the bug fix easy to tease out from the rest of your patch? We should at least apply that as we think about the rest it. Committing this separately also makes it clear what is bug fix and what is new feature. This can be useful when looking back through the commits. If the bug is only fixed because the broken code is replaced, then don't worry about it. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Migrating the OCaml bindings to the official PLplot repository
On Tue, Mar 11, 2008 at 04:02:01PM -0400, Hezekiah M. Carty wrote: > On Tue, Mar 11, 2008 at 5:32 AM, Andrew Ross > <[EMAIL PROTECTED]> wrote: > > I agree that swig would be good to minimise maintenance effort. I see > > that the camidl approach needs (another) modified copy of plplot.h. Swig > > would presumably use the existing plplotcapi.i file. Having said that, > > if there are convincing technical reasons for using camidl I could be > > persuaded. > > The plplot_h file (yet another modified plplot.h) is a definite > down-side to the camlidl approach to generating these bindings. > However, even with that issue I think maintenance of the OCaml > bindings will be easier with camlidl and, as you quoted from one of my > previous emails the resulting OCaml interface is much lighter weight. > > The maintainer of the swig-based OCaml bindings (found here: > http://vityok.org.ua/cgi-bin/odd.cgi/Ocaml-plplot) has said that they > are unable to dedicate the time to continuing upkeep of those > bindings. > > One of the main reasons I chose camlidl over swig as a binding aid is > that camlidl handles C -> OCaml types in a much more clean and direct > fashion than swig does. In order to make the swig-based OCaml > interface look like the C API, every function has to be wrapped in > extra OCaml code to extract or copy values from swig generated > wrappers. In the case of camlidl you end up with this interface > without the extra code. This is partly due to camlidl being very > OCaml specific and covering fewer C and C++ features out of the box > than swig does. PLplot's C api is thankfully quite simple overall, so > camlidl can handle the vast majority of the functions without much > manual intervention. The end result is a very OCaml-friendly > interface without a lot of extra hand-coding. > > The functions that camlidl does not handle on its own (functions > taking callback parameters mainly) are wrapped by hand. > > As an example, moving from a plplot_h based on 5.7.3 to one based on > 5.9.0 (admittedly not a huge change, but did include the char* -> > const char* and several new functions) took me much less than an hour, > including getting the PLplot code, installing it and updating the > OCaml parts. The steps I used to do so are indicated here if you want > a better description of the process: > http://code.google.com/p/ocaml-plplot/wiki/HowItWorks > > I hope this clarifies why I think camlidl is still the way to go for > the OCaml interface. I am quite open to further discussion though if > needed. Hi Hez, Thanks for this. None of the core developers are ocaml experts, so we will bow to your advice on the benefits of camlidl. The fact that you are willing to support the code is a big plus to us. I've got round to trying your code. It took a while as my ubuntu systems don't yet have ocaml 3.10 which is required to get ocamlbuild. This may limit the use of the bindings in the short term, but I expect serious ocaml users will upgrade. The next round of distribution releases will fix this I'm sure. A few points: Can you remove plarrows from the bindings? This is in line with recent svn changes. The function has been deprecated for several years and no longer appears in the examples. It is still available under C for now, but we certainly don't want to propagate it to new bindings. Ocamlbuild looks like a good way of building the bindings and handling dependencies. Is it possible to use some other way of installing though? For plplot the bindings should be installed in the specified install location. This makes it easier to keep the install in a specific place for testing etc and also makes it possible to install without root privileges. Ideally we would have some more examples implemented. It is always good to have a full set of examples. Firstly this shows users how to use plplot with the language. Secondly it provides a thorough test of the bindings and helps to detect problems. If you can sort out these issues I'm happy to help you integrate the bindings in with the cmake build system. From the look of the Makefile this should be (relatively) simple. Andrew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Checked in bug fix to memcairo
Hi all: I've checked in a change to drivers/cairo.c that fixes a bug in my earlier fix to memcairo. Now the memcairo driver should work for both little- and big-endian machines. Grepping though the code, I could not see that there was any standard way of determining the byte order of the machine or any pre-processor symbols set, so I put a simple test in the cairo driver code to check the endian-ness of the machine. If there is a more standard way of handling this, please let me know. 'ctest' passes with this change in place. Regards, Doug Hunt [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Mar 13, 2008, at 2:42 AM, Alan W. Irwin wrote: > The other point I want to make concerns segfaults which are defined as > follows (by wikipedia): "A segmentation fault occurs when a program > attempts > to access a memory location that it is not allowed to access, or > attempts to > access a memory location in a way that is not allowed". > http://en.wikipedia.org/wiki/Access_violation gives several > straightforward > ways you can get those from C, but they miss the big one which is > memory > management issues (i.e., reading or writing beyond the alloc'd memory) > causing an indirect segfault. As I understand it such memory > management > issues do not directly cause a segfault, but they do cause you to > overwrite > neighbouring alloc'd areas, and when you attempt to use pointers > from those > overwritten areas, you end up accessing the wrong memory which > often, _but > not always_ causes a segfault. Agreed, but the segfault occurs because I did not think to check the return value of the function pango_cairo_create_layout(). It should return a pointer to a PangoLayout, but when it fails, as it does in our test case, it returns NULL. The program crashes when this null pointer is passed to the next function which expects a valid PangoLayout pointer. I can add a test for this and the program will no longer segfault, but this does not solve the problem of why pango_cairo_create_layout() is failing in the first place. Presumably it is trying to tell us something with the message: (process:10860): GLib-GObject-WARNING **: cannot register existing type `PangoCairoFcFontMap' Or maybe this could just mean that at some other point we are overwriting some crucial bit of memory? Unfortunately I have not been able to trigger this bug using a simple cairo/pango program that contains just the apparently problematic function calls. -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
