matplotlib-devel Mailing List for matplotlib

Thanks for your work on this patch JJ, glad to see it ready to go!

On Tue, May 5, 2009 at 2:54 PM, John Hunter <jd...@gm...> wrote:
> On Tue, May 5, 2009 at 2:52 PM, John Hunter <jd...@gm...> wrote:
>> On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>> I'm attaching the revised patch (I may split the patch for commit).
>>
>> Still encountering troubles ....
>
> Oops, ignore me. Looks like I just reapplied the *old* patch that was
> laying around. Give me a few minutes to test....
OK thanks for the fixes. Looks good from my end.
JDH

On Tue, May 5, 2009 at 2:52 PM, John Hunter <jd...@gm...> wrote:
> On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
>> I'm attaching the revised patch (I may split the patch for commit).
>
> Still encountering troubles ....
Oops, ignore me. Looks like I just reapplied the *old* patch that was
laying around. Give me a few minutes to test....

On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee...@gm...> wrote:
> I'm attaching the revised patch (I may split the patch for commit).
Still encountering troubles ....
johnh@flag:misc> python rasterization_demo.py
Traceback (most recent call last):
 File "rasterization_demo.py", line 41, in ?
 ax4.set_rasterization_zorder(-10)
AttributeError: 'AxesSubplot' object has no attribute 'set_rasterization_zorder'

I'm attaching the revised patch (I may split the patch for commit).
Regards,
-JJ
On Tue, May 5, 2009 at 3:22 PM, Eric Bruning <eri...@gm...> wrote:
> To avoid confusion, how about renaming draw_wrapper._rasterized to
> draw_wrapper._supports_rasterization ?
>
> This helps to distinguish from artist._rasterized, which has a
> different purpose.
>
> The lack of consistency in decoration language for different artists
> is my fault. It reflects the different ways the base artist module is
> imported for the subclasses of artist.
>
> Thanks,
> Eric
>

To avoid confusion, how about renaming draw_wrapper._rasterized to
draw_wrapper._supports_rasterization ?
This helps to distinguish from artist._rasterized, which has a
different purpose.
The lack of consistency in decoration language for different artists
is my fault. It reflects the different ways the base artist module is
imported for the subclasses of artist.
Thanks,
Eric

Thanks John,
Sorry for the buggy patch. The error occurs when usetex=False and
ps.useafm=False, which was not my setup.
Here is a patch to fix it.
--- lib/matplotlib/backends/backend_ps.py.orig 2009年05月05日
14:44:31.000000000 -0400
+++ lib/matplotlib/backends/backend_ps.py 2009年05月05日
14:44:36.000000000 -0400
@@ -993,7 +993,7 @@
 Ndict = len(psDefs)
 print >>fh, "%%BeginProlog"
 if not rcParams['ps.useafm']:
- Ndict += len(renderer.used_characters)
+ Ndict += len(ps_renderer.used_characters)
 print >>fh, "/mpldict %d dict def"%Ndict
 print >>fh, "mpldict begin"
 for d in psDefs:
@@ -1001,7 +1001,7 @@
 for l in d.split('\n'):
 print >>fh, l.strip()
 if not rcParams['ps.useafm']:
- for font_filename, chars in renderer.used_characters.values():
+ for font_filename, chars in ps_renderer.used_characters.values():
 if len(chars):
 font = FT2Font(font_filename)
 cmap = font.get_charmap()
> If we take the time upfront to be consistent, any search replace
> things we need to do later will be easier.
>
I'll post a revised patch shortly.
Thanks,
-JJ
> Thanks,
> JDH
>

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