Bryan Cole wrote:
Very nice! This could be just what we're looking for! Have you contributed that code to the pyCairo project?
No, but this would indeed be the best home for it.
I agree -- I encourage you to contribute.
I'm kinda rusty on the
full details of defining python types in C.
I don't know how the Cairo bindings are developed, bu the types are defined, you'd just need to add a method or two.
It should be doable without requiring any numpy headers (like was done for PIL, for instance). Using the array interface for transferring bitmaps to/from Cairo would be nice, too.
What interface does PIL use? buffer or array?
It uses the new array interface (I think)
I just used the numpy API
directly. I hope to maintain compatibility with py-2.4.
The goal is to avoid using the numpy API, 'cause then you need to include the numpy headers to built it, and then it only works with numpy. the goal of the new nd-array interface is that multiple packages can all provide the same interface, and therefor exchange data.
It's really an extension of the buffer interface -- it's a buffer with some description of the what the data represents -- i.e. a NX100 array of doubles, rather than just 1600 bytes of who knows what.
You can get all the details, and help, from the numpy list.
* Is there a way to manipulate just part of a path once it is constructed? i.e. you make a path for a 1000pt polygon, and you want to change the location of the 564th point -- can you do that, or do you need to create a whole new path?
This is a bit tricky. The path data structure is a "ragged" C-array.
Adding extra points in would require recreating the array. Editing
existing points would be possible (probably) but accessing a point in
the middle of the array requires iteration over each item to get there
(because elements may have different lengths). Pycairo doesn't provide
any sort of access to the internal data, so this would need a new API.
It doesn't sound like this is what Cairo is designed for at all. Particularly in the special case of a simple polygon, you could do it, but it's probably not worth it.
In any case, I think the overhead of recreating each path
from a python data structure is dwarfed by the cost of antialiased
rendering, so there's not too much value in attempting to maintain
direct access to the path internal data.
well, with wxGraphicsContext, it take a long time to create a path - longer than rendering it, I think. I thought that was because of python overhead in the LineTo function calls, but I think wxGCDC is pretty slow at drawing polygons too, so maybe not.
Everything in cairo is specified in floating point "user units" and is
designed to by fully scalable.
nice.
This should also be true for wxGraphics*, for that matter.
Should be, but it's not. I think mostly due to the legacy of wx -- wx.Pen, and wxFont are specified in integers, and pre-date GraphicsContext.
Robins "Tease" is a recent post suggests there's cross-platform
cairo-integration coming in a future wxPython release. I'd like know
what new features this will include.
Me too -- we'll see!
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov