On Wed, Aug 18, 2010 at 2:08 PM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote:
> 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. > > Neat! I have been sticking mainly to the front-end parts of matplotlib with only a vague understanding of the backend/core pieces. I am learning more all the time. > > 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. > > Might be a good idea to try and make a flowchart of some sort and codify where and when certain things should be done and strive for that organization. > > 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 :-) > > I hope it isn't the blind leading the blind here. I tend to get lots of crazy design ideas, especially when dealing with overall architecture, even without fully understanding exactly how things work. > 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 > Do you have a github account? Maybe we can fork Andrew Straw's repo and bang on this for a on a separate branch. I have about a week and a half left before I have to divert my full attention to a month-long project. Maybe we should also start up another thread summarizing some of the ideas that has been passed around in this thread and make a prioritized ToDo list with milestones? Ben Root
------------------------------------------------------------------------------ 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
