Re: [matplotlib-devel] Cairo backend prospects
All, I am reviving this old thread because the topic came up in a thread with a less-apropos name, and I think we can move it forward a bit more now. Steve's message (below) is still a useful summary of the cairo status. examples/backend_driver.py can now be used for wholesale testing and comparison of the cairo backend. Example: python backend_driver.py cairo.png agg will make png files using cairo and using agg. On my machine (Thinkpad T60, ubuntu feisty) it takes 0.96 minutes for Cairo, 0.76 for Agg. There are two conspicuous bugs in the Cairo output: 1) contour_demo.py: the image part of the figure is wrong in shape and content. It looks like an array dimensions confusion or something like that. Strangely, the very similar image in image_demo.py is fine. 2) polar_demo.py: the part of the spiral outside the bounding circle is removed in the Agg version but not in the Cairo version. There are also subtle differences such as in text positioning. The colorbar in image_masked.py is an example of a case where the agg rendering is much better than the Cairo rendering, which has some sort of aliasing that causes stripes. There are probably other such things worth pointing out. For pdf output I have not tried to look at all the images, but the timing is Cairo 0.71 minutes, pdf backend 1.56 minutes. I have also modified matplotlib.use() and the command-line parsing so that the cairo.pdf style of backend.output specification works in both places. (Only for cairo--it is not needed for any other backend.) I am not the right person to try to fix the bugs in the Cairo backend, but I hope it will indeed be moved forward. It looks like it is close, and it could be a big asset for matplotlib in the longer term. Eric Steve Chaplin wrote: 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 - 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
Re: [matplotlib-devel] Cairo backend prospects
On 7/6/07, Eric Firing [EMAIL PROTECTED] wrote:
2) polar_demo.py: the part of the spiral outside the bounding circle is
removed in the Agg version but not in the Cairo version.
This is a fairly new feature I added to add -- clipping to a polygon.
I haven't ported it to postscript yet. The GraphicsContext now has a
clip_path attribute, which is an agg path storage instance. Even
though it is an agg object (not related to backend_agg actually,
separate code base and wrapping) Eg if we construct a path with
from matplotlib import agg
path = agg.path_storage()
path.move_to(10,10)
path.line_to(100,100)
path.line_to(200,200)
path.line_to(100,200)
path.close_polygon()
We can access it from python code like
In [62]: for i in range(path.total_vertices()):
: cmd, x, y = path.vertex(i)
: print cmd, x, y
:
1 10.0 10.0
2 100.0 100.0
2 200.0 200.0
2 100.0 200.0
79 0.0 0.0
Where each of the cmd is an integer given by one of the path commands
In [60]: for name in dir(agg):
: if not name.startswith('path_cmd'): continue
: print name, getattr(agg, name)
:
path_cmd_catrom 6
path_cmd_curve3 3
path_cmd_curve4 4
path_cmd_curveN 5
path_cmd_end_poly 15
path_cmd_line_to 2
path_cmd_mask 15
path_cmd_move_to 1
path_cmd_stop 0
path_cmd_ubspline 7
The final command 79 which is the result of the
path.close_polygon() function call is a mask of two flags
In [65]: agg.path_flags_close | agg.path_cmd_end_poly
Out[65]: 79
Steve had expressed some dissatisfaction in using the agg python
object for path storage, because agg is C++ whereas cairo is C, and it
just feels wrong to be using an agg path for cairo, but at the end of
the day, we faced either rolling our own backend independent path
object or reusing one, and since agg is fairly deeply ingrained into
mpl and unlikely to disappear, I decided to do a backend independent
SWIG wrapping of agg that could be used across backends to expose some
of the data structures and functionality (eg image interpolation, path
structures, whatever). The idea was to eventually get rid of backend
agg entirely and replace it with backend_agg2 which uses the SWIG
python layer and thereby exposing more of agg's general functionality
at the python/user layer. Unfortunately, this project has stalled and
we currently have the agg layer but are not using it for agg backend
rendering, which is still done in the custom CXX extension code.
The agg path structure is used very lightly currently at the python
level, so if folks fine this arrangement problematic we can
reconsider.
JDH
-
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
Re: [matplotlib-devel] Cairo backend prospects
There are two conspicuous bugs in the Cairo output: 1) contour_demo.py: the image part of the figure is wrong in shape and content. It looks like an array dimensions confusion or something like that. Strangely, the very similar image in image_demo.py is fine. I fixed this bug. There is still a bug illustrated by examples/figimage_demo.py, however, that I did not mention before. I don't plan to look for it, so I hope someone else does. Eric - 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
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.phpp=sourceforgeCID=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 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.phpp=sourceforgeCID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
