On Tue, Nov 18, 2008 at 10:05:39PM -0700, Jerry wrote: > On Nov 18, 2008, at 7:38 PM, Alan W. Irwin wrote: > > > This thread has morphed into something that should be on plplot- > > devel so > > I have moved it there under a new subject. > > > > On 2008-11-19 00:02+0100 Werner Smekal wrote: > > > >> Hi Jerry and David, > >> > >> actually such "hairlines" showed up when I worked on the AGG > >> backend of > >> the wxWidgets drivers (which produces antialiased plots as well) > >> when I > >> only filled a "filled polygon" and didn't add a stroke around it, > >> i.e. > >> draw a line around it. > >> > >> Actually I believe that our cairo device shows this behaviour no > >> matter > >> which driver you use (pdf, xcairo, ...) because it uses only > >> cairo_fill > >> and not cairo_stroke in addition to draw filled polygons. I can't > >> check > >> that at the moment but will do that tomorrow (need sleep). > >> > >> Also the pdf driver which is based on haru pdf library, doesn't show > >> this hairlines (if I'm not wrong) and this driver also fills and > >> strokes > >> filled polygons. > > > > Those are most interesting comments, Werner. One of our users once > > sent a > > patch to solve the same problem for the ps device by essentially > > repeating > > the filled areas with slight x,y shifts to suppress the background > > leak-through you get with antialiasing. That patch worked, but we > > didn't > > accept it because it made the plots too large/too slow to render. > > Your idea > > of adding a boundary stroke for the filled area to keep the > > background from > > leaking through when antialiasing does essentially the same thing but > > without the too large/too slow baggage. Of course, you should save > > and > > restore the user stroke width and find the optimal stroke width for > > your > > boundary stroke, and I am positive this idea will work if you do that. > > > > I am looking forward to seeing what your cairo results look like. > > This > > antialiasing issue is the number one issue for the cairo devices > > (and the > > reason the svg results look so much better than cairo results at the > > moment). > > > > Once we are happy with the cairo antialiased results, then we > > should propagate the boundary stroke idea to the other devices > > (e.g., ps and > > psttf) as well that show this same issue. > > > > Personally, I think it is worth (slightly) delaying the release to > > get this > > long-standing important issue fixed. Hazen, if you agree, then > > does the > > weekend of December 6th seem like a good time to release? > > > > Alan > > __________________________ > > Alan W. Irwin > > > > > I was just dissecting the first page of Example 8, Postscript > (converted to PDF) and SVG, in a graphics program (Intaglio, Mac). > First, the SVG version has no antialiasing "cracks" even though it is > antialiased, while the PS version does have the cracks (it, too, is > antialiased). > > Under high (or any) magnification, the triangles of the surface in > the PS version fit together almost exactly, with the crack remaining > a hairline at any magnification, and with the background "showing > through". But curiously, the triangles of the SVG version are all > oversized by a few per cent so that they don't fit together but > rather overlap one another. This is easy to see by selecting one > triangle and moving it aside a little--the hole that is left is > smaller than the triangle that was just covering it. That is why the > cracks are not (as) visible on the SVG version--the "antialiasing > crack" is the average color of the two (nearly) adjoining triangles; > since they are almost always nearly the same color, it makes it the > cracks nearly invisible. > > The down side of this overdrawing in SVG is that when zoomed a lot, > it is obvious that the triangles just don't fit together correctly-- > it looks like sloppy work (but very effective). It also looks like > what one would do if one were given the task of cutting out a bunch > of colored pieces of paper and told to lay them out on the floor, but > don't let the floor show through. > > Just my two cents worth--I suppose some of you already know all about > this.
This is interesting and shows some driver differences. The other problem with the overlapping approach is that it will mess up transparency for those drivers which use it. We've already seen the overlap problem with early versions of example 30. Not sure there is any easy way around this without a more sophisticated, and possibly driver specific, way of filling in an arbitrary area. Andrew ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
