matplotlib-devel Mailing List for matplotlib

>> The discussion about what to do with my patch fizzled. I created a
>> decorator that made mixed-mode switching a one-line change per artist
>> type. I also added get/set_rasterized and an _rasterized attribute to
>> the Artist base class. I've used it on and off for a few months now
>> with no noted bugs.
>>
>> If we don't like the decorator, we can just make a helper function
>> that is called at the beginning of every artist.draw() method. It's
>> not a very complicated modification.
>>
> Would there be a case that draw methods of some Artists do not need to
> be decorated?
Not that I can think of, if rasterization defaults to off and it's a
user setting to turn it on (except perhaps some future modification
where we auto-detect egregious poly counts in a mesh, for instance).
> If not, I guess some metaclass black magic might be not harmful. What
> do you think? I'm attaching modified version of your patch which
> utilize metaclass for decoration.
I like that this solution doesn't litter every call to draw with
rasterize checks. But it means that the rasterization support had
better be robust, since Artist authors might not know they're
interacting with the rasterization code. It has the downside of being
implicit rather than explicit.
>
> I personally want that rasterization is also supported in the ps
> backend. I guess the missing support of alpha composition would be a
> problem. But, in most of the my use case, I want rasterization for
> artist with z lower than some specified value (i.e., background images
> using pcolormesh), so it is not a problem for me.
I'm not too familiar with the PS backend, but I think that's separate
from the issue of how to tell the renderer when to rasterize.
Thanks,
Eric
>>>
>>> Are you planning to commit your patch to the trunk? I'll be glad to
>>> help you if there are any issues.
>>
>>
>> I'd love to get the patch in trunk, if only so that more people can
>> try it out and find things to improve (or re-implement).
>>
>> Thanks,
>> Eric
>>
>