You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
1
(1) |
2
(8) |
3
(3) |
4
(2) |
5
(4) |
6
(4) |
7
(15) |
8
(9) |
9
(6) |
10
(3) |
11
(1) |
12
(2) |
13
(2) |
14
(3) |
15
(7) |
16
(7) |
17
(1) |
18
|
19
(2) |
20
|
21
(2) |
22
(19) |
23
(40) |
24
(4) |
25
(7) |
26
(2) |
27
(16) |
28
(6) |
29
(29) |
30
(14) |
31
(8) |
On Sat, May 3, 2008 at 11:44 PM, Eric Bruning <eri...@gm...> 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 instance. If > so, the appropriate calls are made to start and stop rasterizing. Hi Eric, thanks for the patch. There are a couple of aspects of the design here that I am not comfortable with, but I think with a few changes this will be useful (though Michael, who implemented the mixed mode renderer, will surely have important comments). The primary thing that bothers me is that one of the core aspects of the matplotlib backend design is that the renderers know nothing about artists -- artists know about renderers, but not the other way around. So I don't like using the renderer to store the rasterized artists. It makes more sense to me for the artist to have has a property set ("set_rasterized" which could be True|False|None where None means "do the default thing for the renderer"). Then you could do: if a.get_rasterized(): renderer.start_rasterizing() a.draw(renderer) renderer.stop_rasterizing() else: a.draw(renderer) Doing this in the axes.draw method may not be the most natural place to do this since it could be done in the artist.draw method, but it may be the most expedient. This is an area where having support for before_draw and after_draw hooks might be useful. One potential problem with either of these approached is it looks like the mixed mode renderer is set up to handle multiple rasterized draws before dumping the aggregate image into the backend on a stop_renderer, so doing the start/stop in any of the approaches above would obviate this efficiency. The axes could aggregate the rasterized artists before rendering and then do them all together, but making this play properly with zorder will be tricky. It does something like this already with the "animated" artists so you may want to look at that. For animated artists in the current implementation, zorder is ignored (the animated artists are drawn on top). Chaco does something a bit more sophisticated than this, since they have separate rendering levels and buffers. Another, less critical, aspect of the patch that bothers me is tagging the renderer with the undocumented attribute "draw_raster" and then checking this with a hasattr in axes.draw. python let's you do this kind of stuff, and I've done plenty of it myself in application building, but in my experience it makes for code that is hard to maintain once the code base grows sufficiently large. Although the mpl setters and getters are not the most pythonic approach, they do make for code that is fairly readable and, importantly, easily documented. JDH
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 two modes that might drive a switch to raster for some artists: 1. User-driven specification of known complex artitsts. 2. Automatic detection of artist complexity (by type or vertex count). The first mode is what I coded up, so I'll discuss it below. A list of artists to rasterize is passed as a draw_raster kwarg to savefig, which percolates down into print_* in the backend-specific figure canvas. When the backend's canvas creates a renderer, the draw_raster list is placed as an attribute on the renderer instance. I figured that the renderer should be responsible for transporting the list of artists needing rasterization, since it's at the renderer level that pixel vs. vector matters. 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 instance. If so, the appropriate calls are made to start and stop rasterizing. Sample usage: f=pyplot.figure() ax=f.add_subplot(111) p,=ax.plot(range(10)) f.savefig('test.pdf', draw_raster=(p,)) svn diff at http://www.deeplycloudy.com/20080503-matplotlib-mixed-mode-r5110.diff Thanks, Eric Bruning Graduate Research Assistant, Meteorology, Univ. Oklahoma As of 6/1/2008, Research Assoc., Univ. Maryland/CICS and NOAA/NESDIS/STAR