Today (revision 10655) I implemented native gradient support for -dev svgqtas well as all qt raster devices (e.g., -dev pngqt). I also changed examples/c/x30c.c to use plgradient. I have attached the -dev pngqt result
for example 30 page 2 which shows that native driver support for gradients can produce beautiful transparency gradients compared with all the artifacts you see (due to slight transparency overlaps) for anything (such as our plgradient software fallback or the old example 30 code) which depends on plshades to produce transparency gradients. This attachment illustrates one of my goals for the plgradient project has been realized, but example 25 shows there is still more work to do.
For example 25, the native results for -dev pngqt and -dev svgqt agree with the native gradient results for -dev svg that I implemented previously. However, those results strongly disagree with the gradient software fallback results I obtain with other devices, and this disagreement appears to be the result of the following general issues with native gradients that I need to address (although from the attachment these issues obviously do not affect example 30): * Gradient clipping issue I am currently representing the native gradient vector with the x,y coordinates of the tail and head of that vector corresponding to the cmap1 independent variable range of 0. to 1. However, example 25 shows some errors with that approach; as the viewport is changed to clip the polygon in 9 different ways per page, the gradient results are inconsistent. I believe what is going on is the devices cannot handle off-scale x,y coordinates for the gradient so I need to clip the gradient vector and its associated cmap1 independent variable range at the viewport boundary. * Gradient skew issue Example 25 shows unclipped results (the first sub-page for each page) that are in agreement with those from the software fallback approach if the aspect ratio is unity (for this example where x and y world coordinate ranges are identical). However,the agreement disappears for non-unity aspect ratio. I believe the software fallback approach is correct here which means the angle between the gradient vector and lines of constant colour must differ from 90 degrees if the aspect ratio does not agree with the ratio between x and y world-coordinate ranges. IOW, the constant colour lines must be skewed relative to the perpendicular to the gradient vector. I hope to deal with these native gradient issues and also add support for native gradients for additional devices (both qt and cairo) in the near future. More later. 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 __________________________
<<attachment: test02.png>>
------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
