Re: [matplotlib-devel] Cairo backend prospects
On Sat, 2007-01-06 at 09:23 -1000, Eric Firing wrote: > Steve, > > Darren Dale raised a question offline that I think will be of general > interest to mpl devels, and that you are the person to answer: > > How do you see the future of a cairo backend as a prospective > replacement for most or all of the primary mpl backends? I think cairo could potentially be used to replace the pdf, ps, svg and gdk/gtk backends which would unify most of the backends and simplify a lot of the code. > What would need to be completed in cairo? Based on the cairo web page, I > get the impression that quite a bit is still missing, including eps > generation and genuine vector ps. But maybe the web page is just out of > date. Which web page is out of date? Where does it mention eps and ps, I couldn't find it. My general impression of the cairo "surfaces" is: ImageSurface/png - support is very good gtk/xlib - support is very good ps/pdf/svg are usable but less mature and still developing so there may be occasional problems drawing specific items ps - it used to embed bitmap images but now most output is vector based eps - is not supported yet, but may be in a future version > What would need to be done in mpl, and how hard would it be? The cairo backend can already be used for png, ps, pdf and gtk output so I don't think there would be much to do. Mostly, it needs testing - running all the mpl examples and checking the output looks OK. > Would mpl get slower if everything went through cairo? Not sure, you would need to run cairo and test it. It used to be much slower than Agg but more recent versions have had many optimisations applied and the difference is much smaller now. > Any other considerations? Some parts of mpl are Agg-specific and other parts (the whole drawing model) are designed around the gdk drawing style - this makes things harder and inefficient when using cairo. On Sat, 2007-01-06 at 09:36 -1000, Eric Firing wrote: > One more question: how does the image quality of cairo compare to > Agg? > Is the antialiasing as good? Image quality looks OK to me, but I'm no expert. The web browser Firefox 3.0 (due to be released early in 2007) will use cairo for all rendering. Firefox requires a high level of graphics performance and the upcoming cairo 1.4 release is expected to provide that. Steve Send instant messages to your online friends http://au.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
On Mon, 2007-01-08 at 10:09 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <[EMAIL PROTECTED]> writes: > Steve> My general impression of the cairo "surfaces" is: > Steve> ImageSurface/png - support is very good gtk/xlib - support > Steve> is very good ps/pdf/svg are usable but less mature and > Steve> still developing so there may be occasional problems > Steve> drawing specific items ps - it used to embed bitmap images > Steve> but now most output is vector based eps - is not supported > Steve> yet, but may be in a future version > > This was my impression too - that it used to be raster PS but now uses > vector, but the web page seems to be claiming otherwise. Which specific web page says otherwise? Steve Send instant messages to your online friends http://au.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > > > What would need to be done in mpl, and how hard would it be? > > > > The cairo backend can already be used for png, ps, pdf and gtk output so > > I don't think there would be much to do. Mostly, it needs testing - > > running all the mpl examples and checking the output looks OK. > > I had to alter the following lines from backend_gtkcairo, from > > import matplotlib.backends.backend_cairo as be_cairo > from matplotlib.backends.backend_gtk import * > > to > > import backend_cairo as be_cairo > from backend_gtk import * > > in order to prevent the following traceback: > > Traceback (most recent call last): > File "/usr/bin/ipython", line 27, in ? > IPython.Shell.start().mainloop() > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, in > start > return shell(user_ns = user_ns) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in > __init__ > shell_class=MatplotlibMTShell) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in > __init__ > on_kill=[mainquit]) > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, in > make_IPython > embedded=embedded,**kw) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in > __init__ > user_ns,b2 = self._matplotlib_config(name,user_ns) > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in > _matplotlib_config > from matplotlib import backends > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > line 55, in ? > new_figure_manager, draw_if_interactive, show = pylab_setup() > File "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > line 23, in pylab_setup > globals(),locals(),[backend_name]) > > File > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", > line 11, in ? > import matplotlib.backends.backend_cairo as be_cairo > AttributeError: 'module' object has no attribute 'backends' The original matplotlib code is correct, you should be editing IPython and correcting their bug! Matplotlib does use a lot of relative imports which I think is bad style. See PEP 8 "Style Guide for Python Code" http://www.python.org/dev/peps/pep-0008/ - Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. Even now that PEP 328 [7] is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable. There was a recent "Coding Guide" thread on this list (which I admit I just skimmed through). Instead of reinventing the wheel, how about stating at the top of CODING_GUIDE that PEP 8 is the default style for matplotlib, and the following notes give in-depth matplotlib examples (or possibly override PEP 8 if necessary). Steve Send instant messages to your online friends http://au.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
On Wed, 2007-01-10 at 11:55 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <[EMAIL PROTECTED]> writes: > > Steve> Matplotlib does use a lot of relative imports which I think > Steve> is bad style. > > Steve> See PEP 8 "Style Guide for Python Code" > Steve> http://www.python.org/dev/peps/pep-0008/ > > Steve> - Relative imports for intra-package imports are highly > Steve> discouraged. Always use the absolute package path for all > Steve> imports. Even now that PEP 328 [7] is fully implemented in > Steve> Python 2.5, its style of explicit relative imports is > Steve> actively discouraged; absolute imports are more portable > Steve> and usually more readable. > > I have never run into a problem with relative imports, though I don't > object to removing them. Why are they bad style and what is the danger? Its because you can unwittingly end up with module name clashes. There can be two different modules in two different directories with the same name and you import the wrong module by mistake. It happened to me once when I created a 'calendar.py' module and didn't realize that Python already has a calendar module. Its hard to debug because you get a traceback which makes no sense. >From PEP328 http://www.python.org/dev/peps/pep-0328/ Rationale for Absolute Imports In Python 2.4 and earlier, if you're reading a module located inside a package, it is not clear whether import foo refers to a top-level module or to another module inside the package. As Python's library expands, more and more existing package internal modules suddenly shadow standard library modules by accident. It's a particularly difficult problem inside packages because there's no way to specify which module is meant. To resolve the ambiguity, it is proposed that foo will always be a module or package reachable from sys.path. This is called an absolute import. Steve Send instant messages to your online friends http://au.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > I only had a short time to work with backend_gtkcairo, but a couple of things > caught my attention. mathtext support seemed to need some improvement, it > looked like it was rendered as an image rather than as text. Also, > imshow(rand(100,100)) looked very different with gtkcairo and gtkagg, (maybe > because the rgba ordering is different in agg and cairo? I'm not sure this is > even the case, I'm taking a stab in the dark.) cairo mathtext uses a method copied from gdk/gtk and does render an image. It needs updating to render text. imshow does look different on cairo and agg, and yes, It looks like an image format problem. cairo uses ARGB32 with pre-multiplied alpha, and the ARGB order depends on whether the machine is little- of big-endian. Steve Send instant messages to your online friends http://au.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
On Thu, 2007-01-11 at 08:50 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <[EMAIL PROTECTED]> writes: > > Steve> On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > >> I only had a short time to work with backend_gtkcairo, but a > >> couple of things caught my attention. mathtext support seemed > >> to need some improvement, it looked like it was rendered as an > >> image rather than as text. Also, imshow(rand(100,100)) looked > >> very different with gtkcairo and gtkagg, (maybe because the > >> rgba ordering is different in agg and cairo? I'm not sure this > >> is even the case, I'm taking a stab in the dark.) > > Steve> cairo mathtext uses a method copied from gdk/gtk and does > Steve> render an image. It needs updating to render text. > > Steve> imshow does look different on cairo and agg, and yes, It > Steve> looks like an image format problem. cairo uses ARGB32 with > Steve> pre-multiplied alpha, and the ARGB order depends on whether > Steve> the machine is little- of big-endian. > > I am confused by what you mean about the ARGB order depending on > endianess. ARGB defines the order, and each color is one byte, so > where is the ambiguity? Do you mean that depending on endianness, > cairo will use other orderings than ARGB? > > In _image.cpp we provide a few buffer methods for various pixel > orderings, eg buffer_argb32. We may need to provide additional > orderings for cairo, and call the right one depending on the platform. This is the official definition from the manual: CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with alpha in the upper 8 bits, then red, then green, then blue. The 32-bit quantities are stored native-endian. Pre-multiplied alpha is used. (That is, 50% transparent red is 0x8080, not 0x80ff.) What I think this means is: cairo ARGB32 is stored not as 4 8-bit quantities, but as one 32-bit int. On big-endian systems the byte order is ARGB, as you would expect, but on little-endian systems (like a PC) the byte order is BGRA. I imagine the reason is that its easier/faster to read/write one 32-bit int than it is to read/write four bytes. Steve Send instant messages to your online friends http://au.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
On Thu, 2007-01-11 at 09:56 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <[EMAIL PROTECTED]> writes:
> Steve> This is the official definition from the manual:
> Steve> CAIRO_FORMAT_ARGB32 each pixel is a 32-bit quantity, with
> Steve> alpha in the upper 8 bits, then red, then green, then
> Steve> blue. The 32-bit quantities are stored
> Steve> native-endian. Pre-multiplied alpha is used. (That is, 50%
> Steve> transparent red is 0x8080, not 0x80ff.)
>
> Steve> What I think this means is: cairo ARGB32 is stored not as 4
> Steve> 8-bit quantities, but as one 32-bit int. On big-endian
> Steve> systems the byte order is ARGB, as you would expect, but on
> Steve> little-endian systems (like a PC) the byte order is BGRA.
>
> Steve> I imagine the reason is that its easier/faster to
> Steve> read/write one 32-bit int than it is to read/write four
> Steve> bytes.
>
> OK, I see the source of my confusion. argb determines the order but
> it doesn't determine whether the most significant bit is first or
> last
>
> I added a method buffer_bgra32 to the image backend. I'm not sure
> this is the right way to deal with the endianness bit it's easy and
> will probably work. I'll leave it to you guys to fix the cairo
> backend to selectively call the right method and test it across
> platforms, or propose a better solution if you don't like this one...
Thanks, I used the new buffer_bgra32 and now examples/image_demo.py
looks correct (except that sometimes it looks like the pixels right at
the edge of the image might be corrupted).
The backend_cairo.py code does look a little strange, it calls
rows, cols, str_ = im.buffer_bgra32()
and then
X = numx.fromstring (str_, numx.UInt8)
which is used merely to convert the (readonly) string returned from
buffer_bgra32 into a read-write buffer for cairo. If buffer_bgra32
returned a buffer (as its name suggests!) instead of a string this would
not be needed, and it would save copying the image around in memory.
I propose this new version of buffer_bgra32 (and buffer_argb32). I
tested it with cairo and it seems to work OK.
Py::Object
Image::buffer_bgra32(const Py::Tuple& args) {
//"Return the image object as bgra32";
_VERBOSE("RendererAgg::buffer_bgra32");
args.verify_length(0);
int row_len = colsOut * 4;
PyObject* py_buffer = PyBuffer_New(row_len * rowsOut);
if (py_buffer ==NULL)
throw Py::MemoryError("RendererAgg::buffer_bgra32 could not allocate
memory");
unsigned char* buf;
int buffer_len;
int ret = PyObject_AsWriteBuffer(py_buffer, (void **)&buf,
&buffer_len);
if (ret !=0)
throw Py::MemoryError("RendererAgg::buffer_bgra32 could not allocate
memory");
agg::rendering_buffer rtmp;
rtmp.attach(buf, colsOut, rowsOut, row_len);
agg::color_conv(&rtmp, rbufOut, agg::color_conv_rgba32_to_bgra32());
PyObject* o = Py_BuildValue("llN", rowsOut, colsOut, py_buffer);
return Py::asObject(o);
}
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
On Thu, 2007-01-11 at 00:01 -0700, Fernando Perez wrote: > On 1/10/07, Steve Chaplin <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-01-08 at 11:24 -0500, Darren Dale wrote: > > > > I had to alter the following lines from backend_gtkcairo, from > > > > > > import matplotlib.backends.backend_cairo as be_cairo > > > from matplotlib.backends.backend_gtk import * > > > > > > to > > > > > > import backend_cairo as be_cairo > > > from backend_gtk import * > > > > > > in order to prevent the following traceback: > > > > > > Traceback (most recent call last): > > > File "/usr/bin/ipython", line 27, in ? > > > IPython.Shell.start().mainloop() > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 1034, > > > in > > > start > > > return shell(user_ns = user_ns) > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 945, in > > > __init__ > > > shell_class=MatplotlibMTShell) > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 622, in > > > __init__ > > > on_kill=[mainquit]) > > > File "/usr/lib64/python2.4/site-packages/IPython/ipmaker.py", line 90, > > > in > > > make_IPython > > > embedded=embedded,**kw) > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 506, in > > > __init__ > > > user_ns,b2 = self._matplotlib_config(name,user_ns) > > > File "/usr/lib64/python2.4/site-packages/IPython/Shell.py", line 397, in > > > _matplotlib_config > > > from matplotlib import backends > > > File > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > > > line 55, in ? > > > new_figure_manager, draw_if_interactive, show = pylab_setup() > > > File > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/__init__.py", > > > line 23, in pylab_setup > > > globals(),locals(),[backend_name]) > > > > > > File > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py", > > > line 11, in ? > > > import matplotlib.backends.backend_cairo as be_cairo > > > AttributeError: 'module' object has no attribute 'backends' > > > > The original matplotlib code is correct, you should be editing IPython > > and correcting their bug! > > Well, I'd be delighted to correct the ipython bug, if only I > understood exactly what the problem was... As far as I can see, that > code in ipython is simply calling > > # Initialize matplotlib to interactive mode always > import matplotlib > from matplotlib import backends > > inside a function (the _matplotlib_config method). I don't see a bug > in that, but if you provide some pointers, I'll be happy to fix any > issues that are on ipython's side of the fence. Darren reported a "bug" in backend_gtkcairo.py which he has "fixed". My view is that the lines from matplotlib.backends import backend_cairo from matplotlib.backends.backend_gtk import * work fine when called from the Python prompt. They are using the absolute package path and are correct and should not be "fixed" to use relative imports (which is bad style). So if there is a bug it is elsewhere and from the traceback it looked like ipython is involved. The traceback shows that this code is being executed # a hack to keep old versions of ipython working with mpl if 'IPython.Shell' in sys.modules: new_figure_manager, draw_if_interactive, show = pylab_setup() which is ipython-specific code. I don't usually use IPython, but I installed it today and ran a few simple matplotlib plots with the GTKCairo backend and they worked OK! So I can't offer more info, perhaps Darren can produce a minimal test case to isolate the problem. Steve Send instant messages to your online friends http://au.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cairo backend prospects
On Fri, 2007-01-12 at 08:44 -0600, John Hunter wrote: > >>>>> "Steve" == Steve Chaplin <[EMAIL PROTECTED]> writes: > > Steve> I propose this new version of buffer_bgra32 (and > Steve> buffer_argb32). I tested it with cairo and it seems to work > Steve> OK. > > This looks good -- please test it with one of the memleak scripts, eg > a variant of units/memleak_hawaii.py to make sure everything is being > cleaned up properly. If you feel motivated, please port these over to > the other buffer methods. One way to do this cleanly would be to set > up an enum of the agg pixel formats supported by agg::color_conv and > then simply allow the user to pass in the pixel format desired. Ie, > support > > color_conv_rgba32_to_abgr32 > color_conv_rgba32_to_argb32 > color_conv_rgba32_to_bgra32 > > in a single function with a single arg. I've replaced buffer_argb32() and buffer_bgra32() with Image::color_conv(format) and tested it for memory leaks and it seems OK. I think this only affects the cairo backend, since the other backends seem to use rgba and don't need to use a color conversion method. Steve Send instant messages to your online friends http://au.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] IPython problem
On Mon, 2007-01-15 at 08:26 -0700, Fernando Perez wrote:
> Those lines also work fine from an ipython prompt:
>
> In [1]: from matplotlib.backends import backend_cairo
>
> In [2]: from matplotlib.backends.backend_gtk import *
They work, but they are not relevant to this problem. Darren has
confused the issue by applying a fix to backend_gtkcairo.py (with no
CHANGELOG comment) while you and I are investigating the problem. So we
are executing the workaround command and are unable to reproduce the
bug.
However, if I put the line
import matplotlib.backends.backend_cairo as be_cairo
back into backend_gtkcairo.py I can now see the problem.
$ python
Python 2.4.3 (#1, Oct 1 2006, 18:00:19)
[GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.backends.backend_gtkcairo
$ ipython
Python 2.4.3 (#1, Oct 1 2006, 18:00:19)
Type "copyright", "credits" or "license" for more information.
IPython 0.7.2 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help-> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: import matplotlib.backends.backend_gtkcairo.py
---
exceptions.AttributeErrorTraceback (most
recent call last)
/home/iuser/
/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py
52
53 # a hack to keep old versions of ipython working with mpl
54 if 'IPython.Shell' in sys.modules:
---> 55 new_figure_manager, draw_if_interactive, show =
pylab_setup()
56
/usr/lib/python2.4/site-packages/matplotlib/backends/__init__.py in
pylab_setup()
22 backend_name = 'backend_'+backend.lower()
23 backend_mod =
__import__('matplotlib.backends.'+backend_name,
---> 24 globals(),locals(),[backend_name])
25
26 # Things we pull in from all backends
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkcairo.py
8
9 #from matplotlib.backends import backend_cairo
---> 10 import matplotlib.backends.backend_cairo as be_cairo
11 from matplotlib.backends.backend_gtk import *
12
AttributeError: 'module' object has no attribute 'backends'
Send instant messages to your online friends http://au.messenger.yahoo.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] cairo patch #4: Fix draw_arc
Carl, I've not been following the matplotlib mailing lists recently, but I came across your blog and had a look at the cairo patches. It looks like all the cairo patches are against some old version of matplotlib. patch #2 enable clipping I enabled clipping in Jan-2007. patch #1 for 'snapping' The patch did not reach the mailing list (?). But in a later mail you mention that snapping smooth, curved user data is a really bad idea. So the patch should probably not be applied. patch #3 snap dash lengths, relies on patch #1. I think this patch has the problems of patch #1 - if the dashes are being used to draw axes or gridlines then snapping is OK. But if the dashes are for user data then snapping is not necessarily what you want. I think the real problem highlighted by patches #1 and #3 is that matplotlib (the frontend) does not tell the backends when it is drawing the plot axes and gridlines to enable the backends to switch on pixel aligned drawing. patch #4 for arcs Looks good, applied it today. Regards, Steve. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
