matplotlib-devel Mailing List for matplotlib (Page 7)

On Tue, May 5, 2009 at 1:08 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Any comment or suggestion will be welcomed.
> I'm planning to commit this change to the svn soon, unless others come
> up with some issues.
I am getting the following error when I test on svn HEAD
johnh@flag:misc> python rasterization_demo.py
Traceback (most recent call last):
 File "rasterization_demo.py", line 49, in ?
 plt.savefig("test_reasterization.eps", dpi=150)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyplot.py",
line 354, in savefig
 return fig.savefig(*args, **kwargs)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 1002, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py",
line 1467, in print_figure
 bbox_inches_restore=_bbox_inches_restore,
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py",
line 1321, in print_eps
 return ps.print_eps(*args, **kwargs)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py",
line 847, in print_eps
 return self._print_ps(outfile, 'eps', *args, **kwargs)
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py",
line 879, in _print_ps
 orientation, isLandscape, papertype,
 File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py",
line 996, in _print_figure
 Ndict += len(renderer.used_characters)
AttributeError: 'MixedModeRenderer' object has no attribute 'used_characters'
Also, a minor potential buglet. In the following,
+ if dsu[0][0] < rasterization_zorder:
+ renderer.start_rasterizing()
+ dsu_rasterized = [l for l in dsu if l[0] < rasterization_zorder]
+ dsu = [l for l in dsu if l[0] >= rasterization_zorder]
+ else:
+ dsu_rasterized = []
I think one could construct a sufficiently empty axes that len(dsu)==0
so I suggest
+ if len(dsu) and dsu[0][0] < rasterization_zorder:
It might also be worthwhile employing a consistent usage when wrapping
the draw methods. We have
+ @allow_rasterization
 def draw(self, renderer, *args, **kwargs):
+ @martist.allow_rasterization
 def draw(self, renderer):
and
+ @artist.allow_rasterization
 def draw(self, renderer):
If we take the time upfront to be consistent, any search replace
things we need to do later will be easier.
Thanks,
JDH

I'm attaching a slightly modified version of the patch, originally by
Eric Bruning.
I changed the name to "allow_rasterization", and added some code to
check if the draw method is decorated when set_rasterized is called
(I'll be glad to hear any better idea for this).
The second patch is to let you use MixedModeRenderer when saving ps
output, i.e., rasterzation for ps backend. The rasterization per
artist is not that useful for ps backend as it does not support alpha
compositions. However, I introduced *rasterization_zorder* attributes
in Axes class, and slightly modified its draw method so that all the
artists whose zorder is below *rasterization_zorder* will be
rasterized (to a single image). My main use case for this is to have
transparent (but rasterized) contour lines or texts overlayed on top
of a background image (for PS backend). Take a look at the example
script I added (examples/misc/rasterization_demo.py).
Any comment or suggestion will be welcomed.
I'm planning to commit this change to the svn soon, unless others come
up with some issues.
Regards,
-JJ
On Mon, May 4, 2009 at 10:05 AM, Eric Bruning <eri...@gm...> wrote:
> On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing <ef...@ha...> wrote:
>> Jae-Joon Lee wrote:
>>>
>>> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eri...@gm...>
>>> wrote:
>>>>
>>>> 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.
>>>
>>> Eric,
>>> I think we'd better stick to your decorator solution.
>>>
>>> Anyhow, I thought you had a svn commit permission but it seems not. Do
>>> you (and other dwevelopers) mind if I commit this patch to the trunk?
>>
>> It would be especially good for John and Mike to have a look.
>>
>> As a matter of style, I suggest a name change. "@hook_before_after_draw" is
>> too generic, and brings to mind discussions a long time ago about possibly
>> adding a general hook mechanism; even before rasterization, and before
>> decorators were available, there were thoughts that we might need this.
>> (Now I don't remember what the motivation was, but I think it had to do
>> with coordinating different elements of a plot.) In any case, the decorator
>> is actually very specific to rasterization, so maybe call it
>> "@with_rasterization" or "@allow_rasterization".
>>
>> I am very anxious to see rasterization support in place; let's just be sure
>> we have a good API and mechanism. The patch looks reasonable to me, but I
>> have no experience in writing decorators, and have not had time to really
>> think about the rasterization API problem.
>
> I like Eric's suggestion to rename the decorator if its only purpose
> is to handle rasterizing. A generic draw hook solution would be fun to
> develop, but I don't have time for that learning curve at the moment.
> So a raster-specific decorator is good by me; I like
> @allow_rasterization.
>
> It's correct that I'd need someone to commit the patch for me. In my
> view, renaming the decorator is a simple search-replace that can be
> handled by the committer, but I'm happy to help with any changes we
> agree on.
>
>>> One I thing I want to add your patch is to warn users when they set
>>> "rasterized" attribute of the artists whose draw method is not
>>> decorated. I'll think about it later but feel free to propose any.
>
> I have no experience with decorator detection. Presumably you can so
> some sort of inspection of self.draw in Artist.set_rasterized.
>
> Thanks,
> Eric B
>
>
>>>
>>> Thanks,
>>>
>>> -JJ
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now & Save for Velocity, the Web Performance & Operations
>>> Conference from O'Reilly Media. Velocity features a full day of expert-led,
>>> hands-on workshops and two days of sessions from industry leaders in
>>> dedicated Performance & Operations tracks. Use code vel09scf and Save an
>>> extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

On Mon, May 4, 2009 at 12:53 PM, T J <tj...@gm...> wrote:
> I've added the patch to the tracker.
>
> http://sourceforge.net/tracker/?func=detail&aid=2786759&group_id=80706&atid=560722
Thanks -- looks good. I've committed it to r7079
JDH

On Thu, Apr 30, 2009 at 3:55 PM, T J <tj...@gm...> wrote:
> On Thu, Apr 30, 2009 at 2:29 PM, John Hunter <jd...@gm...> wrote:
>>
>>
>> On Thu, Apr 30, 2009 at 4:14 PM, T J <tj...@gm...> wrote:
>>>
>>> Fill between is for filling between two y-values over a range of
>>> x-values. Is there anything which fills between to x-values over a
>>> range of y-values?
>>
>> Nothing with the ease of use of fill_between, but you can always write your
>> own PolyCollection, which is what fill_between does (see the function
>> implementation for details) or create a Polygon for a simple region. My use
>> cases are typically in the time series world where I have datetime on the
>> x-axis and some range of values on the y. If folks think it is sufficiently
>> useful to have a fill_betweenx function with a similar interface, you could
>> probably fairly easy port fill_between to fill_betweenx.
>>
>>  http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto
>>
>
> Done. Attached diff is against rev7075.
>
I've added the patch to the tracker.
http://sourceforge.net/tracker/?func=detail&aid=2786759&group_id=80706&atid=560722

On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing <ef...@ha...> wrote:
> Jae-Joon Lee wrote:
>>
>> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eri...@gm...>
>> wrote:
>>>
>>> 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.
>>
>> Eric,
>> I think we'd better stick to your decorator solution.
>>
>> Anyhow, I thought you had a svn commit permission but it seems not. Do
>> you (and other dwevelopers) mind if I commit this patch to the trunk?
>
> It would be especially good for John and Mike to have a look.
>
> As a matter of style, I suggest a name change. "@hook_before_after_draw" is
> too generic, and brings to mind discussions a long time ago about possibly
> adding a general hook mechanism; even before rasterization, and before
> decorators were available, there were thoughts that we might need this.
> (Now I don't remember what the motivation was, but I think it had to do
> with coordinating different elements of a plot.) In any case, the decorator
> is actually very specific to rasterization, so maybe call it
> "@with_rasterization" or "@allow_rasterization".
>
> I am very anxious to see rasterization support in place; let's just be sure
> we have a good API and mechanism. The patch looks reasonable to me, but I
> have no experience in writing decorators, and have not had time to really
> think about the rasterization API problem.
I like Eric's suggestion to rename the decorator if its only purpose
is to handle rasterizing. A generic draw hook solution would be fun to
develop, but I don't have time for that learning curve at the moment.
So a raster-specific decorator is good by me; I like
@allow_rasterization.
It's correct that I'd need someone to commit the patch for me. In my
view, renaming the decorator is a simple search-replace that can be
handled by the committer, but I'm happy to help with any changes we
agree on.
>> One I thing I want to add your patch is to warn users when they set
>> "rasterized" attribute of the artists whose draw method is not
>> decorated. I'll think about it later but feel free to propose any.
I have no experience with decorator detection. Presumably you can so
some sort of inspection of self.draw in Artist.set_rasterized.
Thanks,
Eric B
>>
>> Thanks,
>>
>> -JJ
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of expert-led,
>> hands-on workshops and two days of sessions from industry leaders in
>> dedicated Performance & Operations tracks. Use code vel09scf and Save an
>> extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>