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/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
