John Hunter wrote: > > > On Mon, Mar 23, 2009 at 3:24 PM, Jae-Joon Lee <lee.j.j...@gmail.com > <mailto:lee.j.j...@gmail.com>> wrote: > > The example (e) in my previous script have a code and a text label > mismatched. > I'm attaching the corrected one. > > I took a more look on how a patch is drawn. > the draw() method of a patch calls draw_path method of the renderer, > which seems to be responsible for both "fill", and "stroke". But there > is only one alpha value (gc.alpha). The rgbFace is a tuple of r,g,b > and does not have a alpha value. > > renderer.draw_path(gc, tpath, affine, rgbFace) > > Thus, it seems that is is not possible to have different alpha for > "fill" and "stroke". > One of the easiest solution would be call the draw_path twice, each > for fill and stroke. > > > I think we would pay a significant performance hit in some cases to make > the call twice. Perhaps this is a good time to rethink the draw_path > and gc signature, since as Eric notes these have evolved over time from > the early days when mpl didn't have alpha at all. One possibility would > be to have a facecolor/edgecolor property on the gc itself, which would > be rgba tuples. Since the gc is almost entirely internal, we can revamp > it w/o affecting userland code, though it would be nice to support > legacy methods (eg gc.set_alpha could warn and then proceed to set the > edge and face alpha channel). Then we would drop the rgbFace argument > entirely. Obviously this would require hacking through a bunch of > backend code to fix, but the changes would be fairly straightforward and > of the busy-work variety. > > JDH
It may be nearly orthogonal to the lower-level changes you are suggesting, John, but before I completely forget about it I would like to toss out a very vague idea about reform at a higher level, with apologies that I have not thought it through: Maybe we need an MplColorSpec class. At present, functions and methods typically accept colors and/or color arrays in a wide variety of forms. This is good. My thought is that these should then be converted by the accepting function or method to instances of the new class, and that instances of the new class should be accepted as color inputs along with all the old forms. I suspect that this refactoring might, without loss of backwards compatibility, make it possible to considerably simplify, clarify, and generalize the handling of colors (again, both single values and arrays), and provide a less-confusing framework for setting and overriding defaults. I think that as things are now, color spec checking and/or conversion are often done repeatedly in a single pipeline. With the class, all this would happen only the first time a color spec is encountered. The class might include mapping, or the present color mapping might yield an instance of the class; I have not thought about this aspect. Eric ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
