Personally, I like the use of decorators for this -- it seems to be a nice
clean tool for the job -- but it could be controversial. Fortunately, this
is a nice self-contained usage that could be considered an experimental
foray into decorators, and it doesn't affect outward-facing code.
As for a
I've added get/set_rasterized in Artist.
The decorator is called @hook_before_after_draw. I wanted to put in a
mechanism that allowed for registration of before/after draw
callbacks, but couldn't figure out how. Might still be possible with
some decorator magic that I don't understand. Each ar
John and Michael,
Thanks for your detailed feedback about the mpl design philosophy. I'm
not attached to my implementation details. I will scrap the
draw_raster list and move to implement get/set_rasterized on the
artists.
> > Doing this in the axes.draw method may not be the most natural p
Thanks for having a second look at this, Eric. I consider mixed-mode
drawing somewhat of an experiment at this point -- it's still an open
question whether it should be included in the next release, and
definitely needs more use cases. It is currently only used in the trunk
by quad meshes. I
On Sat, May 3, 2008 at 11:44 PM, Eric Bruning <[EMAIL PROTECTED]> wrote:
> The switch to/from raster mode was made in Axes.draw, where the artists for
> each axes are looped over. In the artist loop, I check if the artist to be
> rendered is listed in the draw_raster attribute on the renderer inst
Hi,
On trunk, there is mixed-mode rendering support built in to (at least) the
SVG and PDF backends, though there are no calls to start/stop_rasterizing()
that utilize the raster mode. I've implemented mode switching for
those backends,
and would appreciate feedback on what I've done.
There are t
