From: Alan W. I. <ir...@be...> - 2008-11-19 02:38:06
|
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 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 __________________________ |
From: Jerry <lan...@qw...> - 2008-11-19 05:05:46
|
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. Also, I notice that in the SVG file, all of the tick marks are drawn twice. Jerry |
From: Alan W. I. <ir...@be...> - 2008-11-19 07:19:33
|
Hi Jerry: I changed the subject line again since this is a separate issue from antialiasing. On 2008-11-18 22:05-0700 Jerry wrote: > [...]I notice that in the SVG file, all of the tick marks are drawn > twice. I tried the following python test code in the installed examples/python directory to confirm this issue. #!/usr/bin/env python # Append to effective python path so that can find plplot modules. from plplot_python_start import * import sys from plplot import * # Parse and process command line arguments plparseopts(sys.argv, PL_PARSE_FULL) # Initialize plplot plinit() pladv(0) plvpor(0.1, 0.9, 0.1, 0.9) plwind(0.1, 0.9, 0.1, 0.9) plbox("bct", 0.7, 0, "bc", 0.7, 0) # Terminate plplot plend() The resulting fragment of the svg file that draws one of the tick marks is <polyline stroke-width="1" stroke="#FF0000" stroke-opacity="1.000000" fill="none" points="503.98,54.01 503.98,63.46" /> <polyline stroke-width="1" stroke="#FF0000" stroke-opacity="1.000000" fill="none" points="503.98,63.46 503.98,54.01" /> So it is clear the tick marks are drawn in one direction than redundantly in the reverse direction confirming Jerry's remark. But if you look at the svg.c code, there is no code to reverse the stroke or anything like that. So the above redundant reverse stroke must be generated by the PLplot core using a redundant call to plD_polyline_svg with just two points (more than two points would generate a "points=" command with more than two points) or else the equivalent redundant call to plD_line_svg (which always draws a line between the two specified points). In sum, these redundant reverse ticks appear to be generated in the PLplot core and not the device code. Could somebody with more knowledge of the PLplot core library than I have look further at this issue? Also, notice how the XML format of the SVG results lends itself to diagnosing Plplot core issues like this. 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 __________________________ |
From: Andrew R. <and...@us...> - 2008-11-19 09:02:03
|
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 |
From: Andrew R. <and...@us...> - 2008-11-19 09:33:51
|
On Tue, Nov 18, 2008 at 11:19:23PM -0800, Alan Irwin wrote: > Hi Jerry: > > I changed the subject line again since this is a separate issue from > antialiasing. > > On 2008-11-18 22:05-0700 Jerry wrote: > > > [...]I notice that in the SVG file, all of the tick marks are drawn > > twice. > > I tried the following python test code in the installed examples/python > directory to confirm this issue. > > #!/usr/bin/env python > > # Append to effective python path so that can find plplot modules. > from plplot_python_start import * > > import sys > from plplot import * > > # Parse and process command line arguments > plparseopts(sys.argv, PL_PARSE_FULL) > > # Initialize plplot > plinit() > > pladv(0) > plvpor(0.1, 0.9, 0.1, 0.9) > plwind(0.1, 0.9, 0.1, 0.9) > plbox("bct", 0.7, 0, "bc", 0.7, 0) > > # Terminate plplot > plend() > > The resulting fragment of the svg file that draws one of the tick marks is > > <polyline > stroke-width="1" > stroke="#FF0000" > stroke-opacity="1.000000" > fill="none" > points="503.98,54.01 503.98,63.46" > /> > <polyline > stroke-width="1" > stroke="#FF0000" > stroke-opacity="1.000000" > fill="none" > points="503.98,63.46 503.98,54.01" > /> > > So it is clear the tick marks are drawn in one direction than redundantly in > the reverse direction confirming Jerry's remark. But if you look at the > svg.c code, there is no code to reverse the stroke or anything like that. So > the above redundant reverse stroke must be generated by the PLplot core > using a redundant call to plD_polyline_svg with just two points (more than > two points would generate a "points=" command with more than two points) or > else the equivalent redundant call to plD_line_svg (which always draws a > line between the two specified points). > > In sum, these redundant reverse ticks appear to be generated in the PLplot > core and not the device code. Could somebody with more knowledge of the > PLplot core library than I have look further at this issue? > > Also, notice how the XML format of the SVG results lends itself to > diagnosing Plplot core issues like this. If you look in plbox.c and at pl(xys)tik in pltick.c then it appears that the axes and ticks are drawn as one line. For example, for the bottom of the box you start in the bottom left corner, draw along to the first tick mark then draw a line up/down and back, ending up on the axis, draw the next segement of the line bounding the box and so on. To me this seems a slightly perverse way of doing it. Much cleaner would be to draw the box and then mark on each tick separately. I assume there was some logic behind this originally, perhaps it worked better for some of the early drivers? It is hard to see how. Anyway, I have changed plbox.c / pltick.c to implement my "more logical" way of doing things. This removes the duplicate lines. Results look visually identical to before, but with slightly smaller file sizes for postscript (and presumable svg). Andrew |
From: Jerry <lan...@qw...> - 2008-11-19 21:55:59
|
On Nov 19, 2008, at 2:33 AM, Andrew Ross wrote: > On Tue, Nov 18, 2008 at 11:19:23PM -0800, Alan Irwin wrote: >> Hi Jerry: >> >> I changed the subject line again since this is a separate issue from >> antialiasing. >> >> On 2008-11-18 22:05-0700 Jerry wrote: >> >>> [...]I notice that in the SVG file, all of the tick marks are drawn >>> twice. >> >> I tried the following python test code in the installed examples/ >> python >> directory to confirm this issue. >> >> #!/usr/bin/env python >> >> # Append to effective python path so that can find plplot modules. >> from plplot_python_start import * >> >> import sys >> from plplot import * >> >> # Parse and process command line arguments >> plparseopts(sys.argv, PL_PARSE_FULL) >> >> # Initialize plplot >> plinit() >> >> pladv(0) >> plvpor(0.1, 0.9, 0.1, 0.9) >> plwind(0.1, 0.9, 0.1, 0.9) >> plbox("bct", 0.7, 0, "bc", 0.7, 0) >> >> # Terminate plplot >> plend() >> >> The resulting fragment of the svg file that draws one of the tick >> marks is >> >> <polyline >> stroke-width="1" >> stroke="#FF0000" >> stroke-opacity="1.000000" >> fill="none" >> points="503.98,54.01 503.98,63.46" >> /> >> <polyline >> stroke-width="1" >> stroke="#FF0000" >> stroke-opacity="1.000000" >> fill="none" >> points="503.98,63.46 503.98,54.01" >> /> >> >> So it is clear the tick marks are drawn in one direction than >> redundantly in >> the reverse direction confirming Jerry's remark. But if you look >> at the >> svg.c code, there is no code to reverse the stroke or anything >> like that. So >> the above redundant reverse stroke must be generated by the PLplot >> core >> using a redundant call to plD_polyline_svg with just two points >> (more than >> two points would generate a "points=" command with more than two >> points) or >> else the equivalent redundant call to plD_line_svg (which always >> draws a >> line between the two specified points). >> >> In sum, these redundant reverse ticks appear to be generated in >> the PLplot >> core and not the device code. Could somebody with more knowledge >> of the >> PLplot core library than I have look further at this issue? >> >> Also, notice how the XML format of the SVG results lends itself to >> diagnosing Plplot core issues like this. > > If you look in plbox.c and at pl(xys)tik in pltick.c then it > appears that > the axes and ticks are drawn as one line. For example, for the > bottom of > the box you start in the bottom left corner, draw along to the first > tick mark then draw a line up/down and back, ending up on the axis, > draw > the next segement of the line bounding the box and so on. I forgot to mention that the axes themselves seemed to be drawn in many pieces, with each piece drawn between consecutive tick marks. It looks like you discovered where this is happening. > > To me this seems a slightly perverse way of doing it. Much cleaner > would > be to draw the box and then mark on each tick separately. I assume > there > was some logic behind this originally, perhaps it worked better for > some > of the early drivers? It is hard to see how. > > Anyway, I have changed plbox.c / pltick.c to implement my "more > logical" > way of doing things. This removes the duplicate lines. Results look > visually identical to before, but with slightly smaller file sizes for > postscript (and presumable svg). > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Werner S. <sm...@ia...> - 2008-11-19 09:48:04
|
Hi Andrew, > 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. Actually example 30 is always a mess. If you don't have a stroke around your filled area, it doesn't look good since there is something missing between the areas. http://www.miscdebris.net/stuff/ex30_nostroke.pdf If you have a stroke around, strokes will overlap and again it doesn't look good http://www.miscdebris.net/stuff/ex30_stroke.pdf (both plots were created with pdfcairo). Maybe as Alan suggested we can deal with this problem playing around with the width of the stroke, but I'm not sure about that. Non-transparent shade plots look good though. Regards, Werner > > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2008-11-19 10:00:07
|
On Wed, Nov 19, 2008 at 10:47:45AM +0100, Werner Smekal wrote: > Hi Andrew, > > > > 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. > > Actually example 30 is always a mess. If you don't have a stroke around > your filled area, it doesn't look good since there is something missing > between the areas. > > http://www.miscdebris.net/stuff/ex30_nostroke.pdf > > If you have a stroke around, strokes will overlap and again it doesn't > look good > > http://www.miscdebris.net/stuff/ex30_stroke.pdf > > (both plots were created with pdfcairo). > > Maybe as Alan suggested we can deal with this problem playing around > with the width of the stroke, but I'm not sure about that. > Non-transparent shade plots look good though. > Of course the real solution for example 30 is probably driver gradient fills as recently suggested by Alan on the list. In the meantime I think fixing the "common" case without transparency to work correctly is the priority. Would it be possible to turn strokes on/off with an option so users can revert to the old behaviour if they need it? Andrew |
From: Werner S. <sm...@ia...> - 2008-11-19 11:23:19
|
Hi all, > Of course the real solution for example 30 is probably driver gradient > fills as recently suggested by Alan on the list. In the meantime I think > fixing the "common" case without transparency to work correctly is the > priority. Would it be possible to turn strokes on/off with an option so > users can revert to the old behaviour if they need it? > > Andrew Scanning the internet for "cairo fill and stroke" one can see, that this is not an uncommon question and I also found a mail where a solution is proposed by using intermediate surfaces. So you plot an opaque filled and stroked polygon and then set the transparency later. I'll see if this is easy to implement. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2008-11-19 11:24:17
|
I forgot the link ;) http://osdir.com/ml/lib.cairo/2004-09/msg00004.html Hi all, > Of course the real solution for example 30 is probably driver gradient > fills as recently suggested by Alan on the list. In the meantime I think > fixing the "common" case without transparency to work correctly is the > priority. Would it be possible to turn strokes on/off with an option so > users can revert to the old behaviour if they need it? > > Andrew Scanning the internet for "cairo fill and stroke" one can see, that this is not an uncommon question and I also found a mail where a solution is proposed by using intermediate surfaces. So you plot an opaque filled and stroked polygon and then set the transparency later. I'll see if this is easy to implement. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2008-11-19 14:38:46
|
Hi all, so I commited the change to the cairo driver by adding a new function filled_polygon(). You can play around with the width of the stroke by changing this line: cairo_set_line_width(aStream->cairoContext, 1.0); A width of 1.0 is good for shade plots without transparency. Example 30 doesn't look that good (but not worse than before). I couldn't find a good width for example 30. Actually the solution to this problem should be http://www.cairographics.org/manual/cairo-context.html#cairo-push-group where our case is described. Here we draw the fill and the stroke opaque in the same color in an intermediate buffer and then draw this buffer with a transparency into the image. Sounds nice, but has some disadvantages: 1) the driver gets unbearable slow 2) example 30 doesn't look better because of this :) 3) the pdf file size of example 30 increases from 8 to 200kB. I commited the code, but commented it. In order to test it in cairo.c you would need to comment line 795 and uncomment line 796. Also uncomment line 798, 801, 802. So in theory this should solve our problem but actually it does not. Now we need to discuss if we keep this stroke around the polygons or revert to the old code. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2008-11-19 15:10:59
|
On Wed, Nov 19, 2008 at 03:38:37PM +0100, Werner Smekal wrote: > Hi all, > > so I commited the change to the cairo driver by adding a new function > filled_polygon(). You can play around with the width of the stroke by > changing this line: > > cairo_set_line_width(aStream->cairoContext, 1.0); > > A width of 1.0 is good for shade plots without transparency. Example 30 > doesn't look that good (but not worse than before). I couldn't find a > good width for example 30. > > Actually the solution to this problem should be > > http://www.cairographics.org/manual/cairo-context.html#cairo-push-group > > where our case is described. Here we draw the fill and the stroke opaque > in the same color in an intermediate buffer and then draw this buffer > with a transparency into the image. Sounds nice, but has some > disadvantages: > > 1) the driver gets unbearable slow > 2) example 30 doesn't look better because of this :) > 3) the pdf file size of example 30 increases from 8 to 200kB. > > I commited the code, but commented it. In order to test it in cairo.c > you would need to comment line 795 and uncomment line 796. Also > uncomment line 798, 801, 802. So in theory this should solve our problem > but actually it does not. Now we need to discuss if we keep this stroke > around the polygons or revert to the old code. Werner, I've tested your fix, which works fine and solves all the problems for the examples I've looked at, except example 30 which suffers from the transparency problem. The only downside is that is seems to roughly double the size of the postscript files. This seems an awful lot, but is probably a price worth paying for better results. Andrew |
From: Andrew R. <and...@us...> - 2008-11-19 15:51:02
|
On Wed, Nov 19, 2008 at 03:10:52PM +0000, Andrew Ross wrote: > On Wed, Nov 19, 2008 at 03:38:37PM +0100, Werner Smekal wrote: > > Hi all, > > > > so I commited the change to the cairo driver by adding a new function > > filled_polygon(). You can play around with the width of the stroke by > > changing this line: > > > > cairo_set_line_width(aStream->cairoContext, 1.0); > > > > A width of 1.0 is good for shade plots without transparency. Example 30 > > doesn't look that good (but not worse than before). I couldn't find a > > good width for example 30. > > > > Actually the solution to this problem should be > > > > http://www.cairographics.org/manual/cairo-context.html#cairo-push-group > > > > where our case is described. Here we draw the fill and the stroke opaque > > in the same color in an intermediate buffer and then draw this buffer > > with a transparency into the image. Sounds nice, but has some > > disadvantages: > > > > 1) the driver gets unbearable slow > > 2) example 30 doesn't look better because of this :) > > 3) the pdf file size of example 30 increases from 8 to 200kB. > > > > I commited the code, but commented it. In order to test it in cairo.c > > you would need to comment line 795 and uncomment line 796. Also > > uncomment line 798, 801, 802. So in theory this should solve our problem > > but actually it does not. Now we need to discuss if we keep this stroke > > around the polygons or revert to the old code. > > Werner, > > I've tested your fix, which works fine and solves all the problems for > the examples I've looked at, except example 30 which suffers from the > transparency problem. The only downside is that is seems to roughly > double the size of the postscript files. This seems an awful lot, but is > probably a price worth paying for better results. I've also committed a similar fix for the postscript driver. This makes only a small difference to the file size, which suggests cairo is not doing things in an optimal way. There is probably little we can do about that though. Andrew |
From: trc <kea...@ya...> - 2008-11-19 23:32:12
|
Hi, Andrew Ross wrote: <... snipped ...> > If you look in plbox.c and at pl(xys)tik in pltick.c then it appears that > the axes and ticks are drawn as one line. For example, for the bottom of > the box you start in the bottom left corner, draw along to the first > tick mark then draw a line up/down and back, ending up on the axis, draw > the next segement of the line bounding the box and so on. > > To me this seems a slightly perverse way of doing it. Much cleaner would > be to draw the box and then mark on each tick separately. I assume there > was some logic behind this originally, perhaps it worked better for some > of the early drivers? It is hard to see how. I'm guessing it was written for pen plotters to save time raising and lowering the pen, and the extra pen movements to draw the ticks separately. Kind regards Terrence |
From: Andrew R. <and...@us...> - 2008-11-20 20:02:08
|
On Wed, Nov 19, 2008 at 11:32:04PM +0000, trc wrote: > Hi, > > Andrew Ross wrote: > <... snipped ...> > > If you look in plbox.c and at pl(xys)tik in pltick.c then it appears that > > the axes and ticks are drawn as one line. For example, for the bottom of > > the box you start in the bottom left corner, draw along to the first > > tick mark then draw a line up/down and back, ending up on the axis, draw > > the next segement of the line bounding the box and so on. > > > > To me this seems a slightly perverse way of doing it. Much cleaner would > > be to draw the box and then mark on each tick separately. I assume there > > was some logic behind this originally, perhaps it worked better for some > > of the early drivers? It is hard to see how. > > I'm guessing it was written for pen plotters to save time raising and lowering the pen, and the extra pen movements to draw the ticks separately. Sounds entirely plausible. Probably not a big motivation these days though. Andrew |
From: Alan W. I. <ir...@be...> - 2008-11-20 21:53:18
|
On 2008-11-20 20:01-0000 Andrew Ross wrote: > On Wed, Nov 19, 2008 at 11:32:04PM +0000, trc wrote: >> Hi, >> >> Andrew Ross wrote: >> <... snipped ...> >>> If you look in plbox.c and at pl(xys)tik in pltick.c then it appears that >>> the axes and ticks are drawn as one line. For example, for the bottom of >>> the box you start in the bottom left corner, draw along to the first >>> tick mark then draw a line up/down and back, ending up on the axis, draw >>> the next segement of the line bounding the box and so on. >>> >>> To me this seems a slightly perverse way of doing it. Much cleaner would >>> be to draw the box and then mark on each tick separately. I assume there >>> was some logic behind this originally, perhaps it worked better for some >>> of the early drivers? It is hard to see how. >> >> I'm guessing it was written for pen plotters to save time raising and lowering the pen, and the extra pen movements to draw the ticks separately. > > Sounds entirely plausible. Probably not a big motivation these days > though. I agree. I have a lot of bad experiences with pen plotters in my memory banks (such as having to put special commands in to agitate the pen to get the india ink to start flowing and also putting in special delay loops to let the ink dry before rolling on to the next plot so your plot wouldn't smear). Therefore, I am really glad pen plotters have long since passed into history. 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 __________________________ |
From: Werner S. <sm...@ia...> - 2008-11-19 09:27:03
|
Hi Alan, > 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. That's actually a good point. So far (for the AGG driver) I only plotted into an image, so there was no file operations involved. I just made the corresponding changes to the cairo driver and as you say, the size of the pdf file nearly doubles. And I also never took care about the width of the pen, I just used what was set. Using vector graphics you have always the possibility to fill, stroke or fill and stroke a path. The fill and stroke way leads to larger files, but you want your plot look good, don't you? > > 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? I'll commit the changes in a minute. If it's not agreed that these changes are more positive (good looking) than negative (bigger filesizes) then we revert them, they are only minor (so far). Regards, Werner > > 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 > __________________________ -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |