I went ahead and asked on the AGG mailing list where things stand as far as Python and wxWidgets are concerned.
Thanks Kevin, I've been wondering about this for a while...I'm not up for joining another mailing list at the moment, but a couple comments about that thread:
wxart2d is a very nifty project. However, my understanding is that it makes heavy use of virtual functions, and will therefor be a lot of work to wrap for wxPython. It would still be great if someone were to do it!
"""
matplotlib has a python interface to antigrain rendering and a wxagg
canvas for drawing agg to wxpython canvases.
...
I use pycxx to write the python extension code. It only utilizes a
fraction of the power of agg, but it does give you an already existing
way of using agg to draw to a wx canvas.
...
It would be nice to do a general purpose python wrapper of agg....
"""
I'm wondering if this means writing more pycxx code, or if the architecture need re-vamping. also, it looks like pycxx has been a sleeping project for some time. I wonder if it's a good bet for this...
And a wx.AggDC would be great!
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
wxart2d is a very nifty project. However, my understanding is that it makes heavy use of virtual functions, and will therefor be a lot of work to wrap for wxPython. It would still be great if someone were to do it!
"""
matplotlib has a python interface to antigrain rendering and a wxagg
canvas for drawing agg to wxpython canvases.
...
I use pycxx to write the python extension code. It only utilizes a
fraction of the power of agg, but it does give you an already existing
way of using agg to draw to a wx canvas.
...
It would be nice to do a general purpose python wrapper of agg....
"""
I'm wondering if this means writing more pycxx code, or if the architecture need re-vamping. also, it looks like pycxx has been a sleeping project for some time. I wonder if it's a good bet for this...
Also chaco has kiva which use weave to interface AGG. There should be only one way
IMHO best interface will be to use AGG on top of Numeric. What do you think?
I use pycxx to write the python extension code. It only utilizes a
Also chaco has kiva which use weave to interface AGG.
I was wondering how they did it.
There should be only one way
That would be nice.
IMHO best interface will be to use AGG on top of Numeric. What do you think?
I'd have to look a lot deeper into AGG to know. How compatible are the native AGG image types with Numeric? I'm guessing they are, as apparently weave works.
Ideally, however, the "one way" PyAGG would not make use of any non-standard libraries. This is a problem, however, because the obvious choices (to me) are PIL, Numeric and wxPython, none of which are standard. The good news is that it's pretty easy to pass data between these three formats, so it's not too big a deal which one is used.
I think the best way would be to use a native AGG image format, and provide converters to the above three. That way we could have the same wrapper used by all of the above. I haven't looked into AGG much, so I have no idea what it provides by way of "native" image formats. That being said, this is the wxPython list, so maybe a wxImage based wrapper would be appropriate.
Has anyone actually said they'd like to work on this? I wish I could, but there are a whole lot of others things I'd like to do first...
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
I'd have to look a lot deeper into AGG to know. How compatible are the native AGG image types with Numeric? I'm guessing they are, as apparently weave works.
Ideally, however, the "one way" PyAGG would not make use of any non-standard libraries. This is a problem, however, because the obvious choices (to me) are PIL, Numeric and wxPython, none of which are standard. The good news is that it's pretty easy to pass data between these three formats, so it's not too big a deal which one is used.
I think the best way would be to use a native AGG image format, and provide converters to the above three. That way we could have the same wrapper used by all of the above. I haven't looked into AGG much, so I have no idea what it provides by way of "native" image formats.
AFAIK there is no native image format. AGG just renders to some rectangular surface. Python's way of representing 2D arrays (surfaces) is Numeric/numarray
being said, this is the wxPython list, so maybe a wxImage based wrapper would be appropriate.
The wxAggDrawer in wxArt2D is doing just that.
I still have some code hanging around from John Labensky, in which we tried
to wrap wxDc around a wxImage using agg.
The point is that wxDc is to simple to be usefull for me. The biggest issue
not knowing how to transform (draw relative to a matrix). Second, there is not
a wxDC::DrawImage( wxImage ). Third the text is a huge problem, since wxDc text can not be transformed properly. All those things are being taken care of in
the wxArt2D module artbase.
Still a wxImageDc might be the best for wxPython, it is just limited or does not always fit. ( DrawBitmap is a bit a problem/slow and text can not be wxDc based, freetype is fine)
I think wxDC is more pixel based, while Agg is more vector based, this is where the problems are. trying to imitate all possible wxDc features using Agg is a problem.
The whole wxArt2D does not need to be wrapped, since it is a low level module,
meaning it hardly depends on other modules.
But not using things like wxPen and wxBrush ( also to much based on old fashion drawing context classes), this is more a new way of doing things.
Just like GDI+ is not at all GDI.
I use a base class for fills and strokes and fonts, each implemented drawing context must be able to deal with those, even if not perfect. E.g not all can do
gradient fills.
I think a more advanged abstract drawing context which can wrap
more then only Agg, is the way to go. It should deal with transforms, images and text, vector paths etc.
This has bin the idea behind wxArt2D its drawing context.
The same idea is behind Java its Graphics2D.
By nature ( like wxDc ) a lot of virtual functions are involved in drawing context classes, so if this is a problem for python, to bad
I would like to keep this idea alive Does anyone have the interest and C/C++/SWIG skills necessary to get a proof-of-concept Python port of the aggdrawer module and any required dependencies? Based on what Klaas has said, this is probably the closest thing to a port of AGG that we could use to render anti-aliased graphics that would also support alpha channels (blending). Based on the description of issues above, I don't see any reason that the wxDC API needs to be followed, we just need a way of rendering to a buffer on and offscreen and probably convert to and from wx.Image/wx.Bitmap. We can worry about the actual API once there are some working samples done in Python. Any takers?
Some relevant links:
ka
···
On Aug 18, 2004, at 1:33 AM, k. holwerda wrote:
Hi Chris,
Chris Barker wrote:
That
being said, this is the wxPython list, so maybe a wxImage based wrapper would be appropriate.
The wxAggDrawer in wxArt2D is doing just that.
I still have some code hanging around from John Labensky, in which we tried
to wrap wxDc around a wxImage using agg.
The point is that wxDc is to simple to be usefull for me. The biggest issue
not knowing how to transform (draw relative to a matrix). Second, there is not
a wxDC::DrawImage( wxImage ). Third the text is a huge problem, since wxDc text can not be transformed properly. All those things are being taken care of in
the wxArt2D module artbase.
Still a wxImageDc might be the best for wxPython, it is just limited or does not always fit. ( DrawBitmap is a bit a problem/slow and text can not be wxDc based, freetype is fine)
I think wxDC is more pixel based, while Agg is more vector based, this is where the problems are. trying to imitate all possible wxDc features using Agg is a problem.
The whole wxArt2D does not need to be wrapped, since it is a low level module,
meaning it hardly depends on other modules.
But not using things like wxPen and wxBrush ( also to much based on old fashion drawing context classes), this is more a new way of doing things.
Just like GDI+ is not at all GDI.
I use a base class for fills and strokes and fonts, each implemented drawing context must be able to deal with those, even if not perfect. E.g not all can do
gradient fills.
I think a more advanged abstract drawing context which can wrap
more then only Agg, is the way to go. It should deal with transforms, images and text, vector paths etc.
This has bin the idea behind wxArt2D its drawing context.
The same idea is behind Java its Graphics2D.
By nature ( like wxDc ) a lot of virtual functions are involved in drawing context classes, so if this is a problem for python, to bad
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
Does anyone have the interest and C/C++/SWIG skills necessary to get a proof-of-concept Python port of the aggdrawer module and any required dependencies? Based on what Klaas has said, this is probably the closest thing to a port of AGG that we could use to render anti-aliased graphics that would also support alpha channels (blending). Based on the description of issues above, I don't see any reason that the wxDC API needs to be followed, we just need a way of rendering to a buffer on and offscreen and probably convert to and from wx.Image/wx.Bitmap. We can worry about the actual API once there are some working samples done in Python. Any takers?