On 06/11/2010 01:54 PM, Eric Firing wrote: > On 06/11/2010 07:39 AM, Michael Droettboom wrote: > >> On 06/11/2010 01:31 PM, jason-s...@creativetrax.com wrote: >> >>> On 6/11/10 9:44 AM, Michael Droettboom wrote: >>> >>> >>>> On 06/11/2010 09:46 AM, Michael Droettboom wrote: >>>> >>>> >>>> >>>>> However, there's actually a bug in the quantizer that your example >>>>> illustrates. Since the spine lines in your example have a stroke width >>>>> of 4 pixels, they should actually be rounded to the nearest pixel edge, >>>>> not nearest center pixel. So the quantizing is causing this slight >>>>> alignment problem *and* making the straight lines look fuzzier than they >>>>> should. I'm planning on writing a patch that will take stroke width >>>>> into account to address this. By coincidence only, this will also make >>>>> your example plot look more accurate (but that's dependent on the >>>>> specific scale being used). >>>>> >>>>> >>>>> >>>>> >>>> This specific bug is fixed in r8414. >>>> >>>> Mike >>>> >>>> >>>> >>>> >>> I tested your fix, and now this example gives the same sort of problem >>> (note that in this case, the spine is 1 pixel wide; I've just changed >>> the dpi): >>> >>> >> That's exactly what I meant when I said "By coincidence only, this will >> also make your example plot look more accurate (but that's dependent on >> the specific scale being used)." This isn't a proper fix, other than to >> make even-width lines looking less fuzzy. The correct fix (to either >> make quanitizing an rcParam or to adjust the data based on it) is much >> more work. >> > I don't see how any reasonable algorithm could do such a data adjustment > in general, so if the half-pixel inaccuracy is a problem, then I think > using an rcParam to turn off quantizing is the way to go. > Yeah -- as I considered it further, I'm coming to the same conclusion. We could optimize for a single point, eg. (0, 0), but not for all ticks, gridlines etc. > It appears that the difficulty is that quantization is exposed at the > python level only for collections, via iter_segments. > Sort of. Lines (but none of the other artists) follow what is set by "set_snap" (the use of two terms for the same thing is also a problem, of course). This needs to be extended to other artists (and other relevant backend methods other than draw_path, if necessary). But I think for convenience, it should also be a global rcParam.
Mike > Eric > > > >> Mike >> >> > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
