2010/8/18 Benjamin Root <ben.r...@ou.edu>:
> I had a thought... and it is based on my admittedly incomplete understanding
> of matplotlib. Everything that gets drawn is derived from the artist class,
> right? So, what if there was a 'grey' boolean in that base class, and the
> .draw() function passes that bool down through all the subsequent .draw()
> calls of its child objects (it could be None by default to accept the
> parent's property, or allowed to be explicitly set by the user to override
> the parent's value.)
It's a neat idea again. I like it very much. I propose the following:
1) As you said, a gray flag in mpl.artist.Artist, which can be
automatically transmitted to the child artists *on render time*.
2) Counting the "grayishness" (single, double, ... :-) in
mpl.backends.renderer_bases.RendererBase.
3) Evaluating the grayishness in
mpl.backends.renderer_bases.RendererBase.new_gc() [i.e., new graphics
context]. Passing it on to the GraphicsContext as initialisaion
argument. mpl.backends.renderer_bases.GraphicsContextBase has ONLY
ONE COLOUR ARGUMENT, namely .set_foreground(). It seems everythings
breaks down to foreground rendering of pathes and symbols. Indeed, it
uses once again mpl.colors.colorConverter, and I think my refactoring
of this one is not useless at all, but the main point is, it stores an
rgb colour in the end, and in fact *all* rgb colours ever used in any
graphics drawing context. Also for text, etc. pp.
4) Introducing a decorator:
def draw_with_grayishness(fn):
def decorated(self, renderer):
if self.is_gray():
renderer.increase_grayishness()
fn(self, renderer)
renderer.decrease_grayishness()
else:
fn(self, renderer)
return decorated
This turns on grayishness in the renderer if it is requested by
*self*, which is an Artist.
> By the time we get to the backends, all the color data should be in a clean,
> broadcasted rgba form, so it should then be a relatively simple check of the
> grey flag before writing out the color information.
Mmmh, for some reason colorConverter is used there again, maybe historical.
> Admittedly, I would much rather have this flag check done before getting to
> the backends and through a single point of code. At first, I thought that
> ColorConverter would be it, but as I now understand it, it is treated more
> like a utility module rather than an important step in the rendering
> process. It gets used for things at different points in the matplotlib
> process.
Yes, it's not the only point, there is at least one more,
mpl.collection.Collection.update_scalaramappable(). And there may be
tons of other selfish procedures ... So I agree fully with you.
> Maybe I am just going overboard here...
Well, I come with you :-)
So, the code point would be outside of the Renderer, but in the
GraphicsContext, which is abstract enough to be shared by all
implementations of the rendering. It is passed on to the
implementation's methods as an argument, so its .foreground or
whatever is the same to all rendering implementations.
Friedrich
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
