matplotlib-devel Mailing List for matplotlib

Hey, it's getting vivid!  Nice!

2010/8/19 Benjamin Root <ben...@ou...>:
> 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.

I'm diving sometimes into matplotlib code, but this is the deepest
glimpse I have reached so far ...

>> > 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.

Maybe it would be good contribution to the developer's documentation
of *how matplotlib works*.

> 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.

haha!  Seems that we are similar in this respect.  But in this case, I
really tried to tell only ideas which are verified to work from
inspection of the code afaict.

> 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.

It's a good idea, my account is friedrichromstedt, maybe you can fork
and add me as an collaborator?

> 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?

How long do you think will this gray thingy take?  My plan was to
finish next week by Friday.

I hope I will get a whole picture today night.

Friedrich

On Wed, Aug 18, 2010 at 2:08 PM, Friedrich Romstedt <
fri...@gm...> wrote:

> 2010/8/18 Benjamin Root <ben...@ou...>:
> > 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