[wxpython-users] Trying to understand GraphicsPath
Frank Millman
I am having fun learning how to draw a chart using BPMN (Business Process
Modelling Notation).
Here is a link to a poster showing all the symbols -
http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner/BPMN1_1_Poster_EN.pdf
Drawing the symbols in no real problem - some of them are quite challenging,
but that is part of the fun.
I am trying to work out how to do a HitTest, so that I can detect if the
user wants to drag a symbol. At this stage I am concentrating on a Circle.
GraphicsPath has a Contains() method - you pass it a Point, and it returns
True if the point is within the path, else False. This seems like the
obvious way to perform the test.
If you run the attached program, you will see that there are three circles.
One is a plain circle, the second has a thick transparent border, and the
third has a thick solid border.
Using gtk2, HitTest always returns None, no matter where I click. Maybe the
Contains() method is not supported on gtk2. [See my P.S. at the bottom]
Using msw, HitTest works correctly, but it is actually cleverer than I want
it to be. The first circle works perfectly, the second two return True if I
click within the border, but False if I click in the centre of the circle. I
want a click anywhere within the outer circle to return True, but I cannot
figure out how to do it.
I have tried three approaches -
1. AddCircle() for the outer and the inner circles
2. AddCircle() for the outer, then create a sub-path and AddCircle() to the
sub-path for the inner circle
3. AddEllipse() for the outer and the inner circles
They all give the same result.
I do not have a clear understanding of what constitutes a Path, what
constitutes a SubPath, how the Stroke/Fill/Draw methods interact with them,
and how to manipulate them to give the desired effect. The docs do not give
any assistance here.
Most symbols are quite a bit more complex than a simple circle. I will need
to detect a click anywhere within outer perimeter of the shape.
Any info will be much appreciated.
Frank Millman
P.S. I have just noticed that gtk2 returns True if you click on the actual
line defining the circle, but not if you click within the circle.
Unfortunately this does not help me.
Christopher Barker
> I am having fun learning how to draw a chart using BPMN (Business Process
> Modelling Notation).
Frank, did you consider using wx.lib.floatcanvas? There is a bunch of
code in there that does hit-testing all that for you.
The current version uses DCs, rather than GraphicsContext, so ti doesn't
handle alpha blending, which you may need (but may not). However there
is new version about to be released (and currently in a branch in SVN
that is based on GraphicsContext.
Also, now that I think about it, you can create a custom DrawObject for
FloatCanvas1 that uses a GraphicsContext to draw, if you do need some
of those features:
http://morticia.cs.dal.ca/FloatCanvas/wiki/SmoothLines
-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
Frank Millman
>
> Frank Millman wrote:
> > I am having fun learning how to draw a chart using BPMN (Business
> > Process Modelling Notation).
>
> Frank, did you consider using wx.lib.floatcanvas? There is a
> bunch of code in there that does hit-testing all that for you.
>
> The current version uses DCs, rather than GraphicsContext, so
> ti doesn't handle alpha blending, which you may need (but may
> not). However there is new version about to be released (and
> currently in a branch in SVN that is based on GraphicsContext.
>
> Also, now that I think about it, you can create a custom
> DrawObject for
> FloatCanvas1 that uses a GraphicsContext to draw, if you do
> need some of those features:
>
> http://morticia.cs.dal.ca/FloatCanvas/wiki/SmoothLines
>
> -Chris
>
Thanks for the suggestion, Chris.
I have not tried FloatCanvas yet, as I have no requirement for numpy, and I
am trying to avoid too many dependencies.
I will wait a bit to see if Robin comes up with any ideas. If not, I will
bit the bullet, install numpy, and start playing with FloatCanvas.
Thanks again
Frank
Bryan Cole
> P.S. I have just noticed that gtk2 returns True if you click on the actual
> line defining the circle, but not if you click within the circle.
> Unfortunately this does not help me.
On wxGTK, wxGraphics* uses cairo for drawing. wxGraphicsPath.Contains()
is calling the 'cairo_point_in_stroke()' to do hit testing. This only
tests the stroked area (not the fill). Cairo has a different function
for doing hit-testing on a fill 'cairo_point_in_fill()'. This is not
used in wxGraphicsPath, hence your problem.
If you want to get hit-testing working for wxGTK, you could use
wxGraphicsPath.GetNativePath() to get a pointer to the raw cairo_path_t,
then call 'cairo_point_in_fill' using ctypes/pycairo.
I posted some notes on the pyWiKi on using cairo with wxPython; you
could follow a similar strategy to convert between wxGraphicsPaths and
pycairo.Path objects.
FWIW, I recommend cairo for drawing on Windows as well as GTK, as the
API is great and you have svg/pdf/png output as well as screen-output.
BC
> _______________________________________________
> wxpython-users mailing list
> wxpytho...@lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
Robin Dunn
> Hi all
>
> I am having fun learning how to draw a chart using BPMN (Business Process
> Modelling Notation).
>
> Here is a link to a poster showing all the symbols -
>
> http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner/BPMN1_1_Poster_EN.pdf
>
> Drawing the symbols in no real problem - some of them are quite challenging,
> but that is part of the fun.
>
> I am trying to work out how to do a HitTest, so that I can detect if the
> user wants to drag a symbol. At this stage I am concentrating on a Circle.
>
> GraphicsPath has a Contains() method - you pass it a Point, and it returns
> True if the point is within the path, else False. This seems like the
> obvious way to perform the test.
>
> If you run the attached program, you will see that there are three circles.
> One is a plain circle, the second has a thick transparent border, and the
> third has a thick solid border.
>
> Using gtk2, HitTest always returns None, no matter where I click. Maybe the
> Contains() method is not supported on gtk2. [See my P.S. at the bottom]
Please add a bug report about this.
>
> Using msw, HitTest works correctly, but it is actually cleverer than I want
> it to be. The first circle works perfectly, the second two return True if I
> click within the border, but False if I click in the centre of the circle. I
> want a click anywhere within the outer circle to return True, but I cannot
> figure out how to do it.
My guess is that it wasn't intended to act this way, so please enter a
bug report about this too.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Nitro
> Frank Millman wrote:
>
>> Using msw, HitTest works correctly, but it is actually cleverer than I
>> want
>> it to be. The first circle works perfectly, the second two return True
>> if I
>> click within the border, but False if I click in the centre of the
>> circle. I
>> want a click anywhere within the outer circle to return True, but I
>> cannot
>> figure out how to do it.
>
> My guess is that it wasn't intended to act this way, so please enter a
> bug report about this too.
I am quite sure it was intended to act the way it does. The docs of
Contains() say "Returns true if the point is within the path.". The last
two circles are not two circles, but a ring. The area which is filled is
considered "in", everything else "out".
For fc2, I definately want to have the current behaviour. However, it was
nice if GraphicsPath had more Contains* methods. For example the current
Contains() method returns False if I have a very thick border and click
it. I doubt this is possibly to do with the underlying toolkits though.
-Matthias
Nitro
Addendum:
Use wx.GraphicsPath.Contains and set fillStyle to wx.WINDING_RULE instead
of the default wx.ODDEVEN_RULE . Then you example works on msw.
-Matthias
Christoffer Sørensen
> FWIW, I recommend cairo for drawing on Windows as well as GTK, as the
> API is great and you have svg/pdf/png output as well as screen-output.
So you recommend bypassing most of graphicscontext and use cairo directly?
I am interested since I am still evaluating the different methods of
drawing in wxpython.
/Chris
Christopher Barker
> I have not tried FloatCanvas yet, as I have no requirement for numpy, and I
> am trying to avoid too many dependencies.
don't be too afraid, numpy is very robust and easy to install. It's also
very useful, even if you don't have a lot of numbers to crunch. The core
of it really should be in the standard lib, but what can you do?
However, folks often do want to minimize dependencies. As I think about
it numpy was pretty critical for FloatCanvas1, because it was used for
all the zooming and scaling computation. However, with FC2,
GraphicsContext is doing a lot of that -- I wonder how key it is now?
Maybe pretty key, I think it's used for generating buffers for bitmaps
and the like, too, but I'm not sure.
Matthias, what do you think? Is the numpy dependency still important?
-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
Nitro
<Chris....@noaa.gov>:
> Frank Millman wrote:
>> I have not tried FloatCanvas yet, as I have no requirement for numpy,
>> and I
>> am trying to avoid too many dependencies.
>
> don't be too afraid, numpy is very robust and easy to install. It's also
> very useful, even if you don't have a lot of numbers to crunch. The core
> of it really should be in the standard lib, but what can you do?
>
> However, folks often do want to minimize dependencies. As I think about
> it numpy was pretty critical for FloatCanvas1, because it was used for
> all the zooming and scaling computation. However, with FC2,
> GraphicsContext is doing a lot of that -- I wonder how key it is now?
> Maybe pretty key, I think it's used for generating buffers for bitmaps
> and the like, too, but I'm not sure.
>
> Matthias, what do you think? Is the numpy dependency still important?
Yes, it's very essential. The filtering capabilities use it, the
transforms use it (especially the projection transforms), bounding boxes
use it and probably more things.
Removing numpy would
a) be hard to remove from fc2, because we rely on it.
b) slow down fc2 too much in general.
c) I don't see a good reason to not use numpy. Python is too slow for
math-intensive applications written in pure python. Numpy was written to
help exactly this. 10 MB of extra dependencies are not noteworthy these
days (if you use handphones or similar maybe, but then fc will be way too
slow on them anyways). Numpy is a mature library, so including and relying
on it should not be a problem.
-Matthias
Robin Dunn
I was going to check the rule setting but forgot about it when I
answered the email. Thanks!
Bryan Cole
> On Mon, Sep 1, 2008 at 10:27 PM, Bryan Cole <br...@cole.uklinux.net> wrote:
> > FWIW, I recommend cairo for drawing on Windows as well as GTK, as the
> > API is great and you have svg/pdf/png output as well as screen-output.
>
> So you recommend bypassing most of graphicscontext and use cairo directly?
Yes. The availability of cross-platform SVG output is the compelling
reason for me.
To use cairo on windows, you need to install libcairo.dll (+ libpng.dll,
as a dependency) and the pycairo pacakge.
For efficient construction of large paths, I have a compiled helper
module with functions like "Path_fromArray", to create a path from data
in a numpy array.
One caveat: I've not yet tested text-rendering on win32 or benchmarked
performance on this platform.
BC
>
> I am interested since I am still evaluating the different methods of
> drawing in wxpython.
>
> /Chris
Chris Barker
> Yes. The availability of cross-platform SVG output is the compelling
> reason for me.
presumably you get PDF and other, too!
> For efficient construction of large paths, I have a compiled helper
> module with functions like "Path_fromArray", to create a path from data
> in a numpy array.
Very nice! This could be just what we're looking for! Have you
contributed that code to the pyCairo project? 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.
A couple questions:
* 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?
* Can you specify line widths in floating point? i.e. I want to specify
a line width of say 0.01, and then have Cairo scale everything up to
some reasonable size, like a factor of 200. The point would be to be
able to use whatever coordinate system was natural to the user's data,
then have Cairo do the scaling to the resolution desired.
* same question as above but for font sizes.
> One caveat: I've not yet tested text-rendering on win32 or benchmarked
> performance on this platform.
hmm -- well, it'll be interesting to see.
Frank Millman
>
> Hi all
>
> I am having fun learning how to draw a chart using BPMN
> (Business Process
> Modelling Notation).
>
>
> I am trying to work out how to do a HitTest, so that I can
> detect if the user wants to drag a symbol.
Many thanks to all for the really informative replies.
I can now get it working on msw using wx.WINDING_RULE (thanks, Matthias),
but it appears from Bryan's reply that it is not possible to get it working
on gtk2 using native wxPython and GraphicsContext.
As an alternative, I am looking at wx.Region, as this also has a Contains()
method. It looks promising, but there is something fundamental I do not
understand.
I can create a circular Region using RegionFromBitmap(), and it correctly
reports whether a particular mouse click is within the circle, on both
platforms.
However, I cannot figure out how to position the Region on the screen - it
defaults to (0,0). The other wx.Region constructors include positional
information in their arguments, but RegionFromBitmap does not.
In the attached program, the circles in the centre are given wx.Regions
based on rectangles. The one in the top left is given a wx.Region based on a
bitmap containing a circle.
HitTest works on the three circles in the centre, but it also returns True
(wx.InRegion) if you click in the four corners just outside the circle, but
within the rectangle. HitTest works correctly on the circle in the top left,
but I can't figure out how to position it anywhere else.
Any hints will be much appreciated.
Frank
Bryan Cole
>
> 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. Right now I just use
function calls, passing the Context and data-array as an argument.
Pycairo is a "proper" python extension with cairo objects wrapped into
compiled python types. These new functions should probably be added as
methods to the PyCairoContext object, however I'm kinda rusty on the
full details of defining python types in C.
> 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? I just used the numpy API
directly. I hope to maintain compatibility with py-2.4.
> * 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.
If you created specialisation of the general Path, with a homogeneous
elements (i.e. all lines, no curves), you could arrange for direct,
random access. 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.
>
> * Can you specify line widths in floating point? i.e. I want to specify
> a line width of say 0.01, and then have Cairo scale everything up to
> some reasonable size, like a factor of 200. The point would be to be
> able to use whatever coordinate system was natural to the user's data,
> then have Cairo do the scaling to the resolution desired.
>
> * same question as above but for font sizes.
Everything in cairo is specified in floating point "user units" and is
designed to by fully scalable. This should also be true for wxGraphics*,
for that matter.
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.
BC
Robin Dunn
> However, I cannot figure out how to position the Region on the screen - it
> defaults to (0,0). The other wx.Region constructors include positional
> information in their arguments, but RegionFromBitmap does not.
wx.Region has the Offset method that lets you relocate where it's origin
is located.
Frank Millman
>
> Frank Millman wrote:
> > However, I cannot figure out how to position the Region on
> the screen
> > - it defaults to (0,0). The other wx.Region constructors include
> > positional information in their arguments, but
> RegionFromBitmap does not.
>
> wx.Region has the Offset method that lets you relocate where
> it's origin is located.
>
Perfect! Thank you.
Frank
Christopher Barker
> Frank Millman wrote:
> I can now get it working on msw using wx.WINDING_RULE (thanks, Matthias),
> but it appears from Bryan's reply that it is not possible to get it working
> on gtk2 using native wxPython and GraphicsContext.
>
> As an alternative, I am looking at wx.Region, as this also has a Contains()
> method. It looks promising, but there is something fundamental I do not
> understand.
Frank,
I think you may be going about this the wrong way -- so I offer an
alternative.
The problem with all these methods is that you are using math to try to
figure out whether an object is hit -- but once you try to include line
width, filling, etc, you end up having to do as much work as drawing in
the first place.
So, why not draw?
In FloatCanvas (version 1), hit testing is handled by drawing each
"hitable" object on an offscreen bitmap in a unique color. When there is
a mouse event, the color of the pixel where the mouse is is checked, and
presto -- you know which (if any)object was hit.
There are some limitation to this method:
1) you can only detect the top object of overlapping objects
2) with anti-aliasing, an object can not be drawn in only one color.
FC1 uses DCs, so this works. I don't know if anti-aliasing can be turned
off with GCs.
3) all hitable objects need to be drawn twice -- which can slow down
rendering, though the hit-testing is blazingly fast!
Another route to take, which solves all of these problems (but may be
slower to do a hit-test) is to maintain a small off-screen bitmap, then
when you want to do a hit-test, you transform the coordinates so that
the desired pixel is in the middle, draw each object to it, and check if
the middle pixel changes color when the drawing is done. If you do a
bounding box check first (or even better, use a spatial index) then you
won't have to check many objects, and it should be plenty speedy for
most use (MOUSE_MOVE events may be an issue.
At the end of the day, however, you'd still probably be better off using
FloatCanvas 1 or 2 (or wxOGL, maybe), rather than figuring out how to
solve all these issues yourself.
It's not the best time to get started with FC, as we are in a transition
period -- FC1 does not support GCS very well, and FC is brand new and
not fully tested and mature yet -- but we'd love to have a few more
folks on board!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
Frank Millman
>
> Frank Millman wrote:
> > Frank Millman wrote:
> > I can now get it working on msw using wx.WINDING_RULE (thanks,
> > Matthias), but it appears from Bryan's reply that it is not
> possible
> > to get it working on gtk2 using native wxPython and GraphicsContext.
> >
> > As an alternative, I am looking at wx.Region, as this also has a
> > Contains() method. It looks promising, but there is something
> > fundamental I do not understand.
>
> Frank,
>
> I think you may be going about this the wrong way -- so I
> offer an alternative.
>
> The problem with all these methods is that you are using math
> to try to figure out whether an object is hit -- but once you
> try to include line width, filling, etc, you end up having to
> do as much work as drawing in the first place.
>
> So, why not draw?
>
Hi Chris, thanks for the info - I do appreciate the input.
A few points -
1. This is my first attempt at drawing, so I am definitely feeling my way. I
have looked at OGL and OGLLike, but a lack of documentation meant that I
could not be sure that they would give me all the functionality I need, and
I did not want to spend a lot of time only to find that it was wasted. I
also looked at DragImage and PseudoDC in the demo. I am particularly
impressed with PseudoDC - it works so smoothly, on gtk2 and on msw, but
again cannot be sure that it would give me what I need.
2. The attached program shows part of what I am trying to achieve. I have
actually got it working 'well enough' that I was ready to move on to other
things, so unless there is something fundamentally wrong with my approach I
am a bit reluctant to go back and revisit it now. How much effort would
there be in re-implementing this in FC? I am still getting some flicker on
msw, so if FC would help remove this it could be a reason to reconsider.
3. I may revise my entire approach anyway, depending on how my project
evolves. I am trying to create an 'executable' business process, which means
that the drawing must be saved in a structured format (probably xml) which
can be fed into a workflow engine, which I am writing at the same time.
Instead of allowing the user to manipulate the drawing directly, and
inferring the structure from the drawing, I may end up having the user
manipulate the structure, and then re-generate the drawing from the
structure after each change.
The jury is still out on the best way to accomplish this. Any comments will
be much appreciated.
Frank
Christopher Barker
> 1. This is my first attempt at drawing, so I am definitely feeling my way. I
> have looked at OGL and OGLLike, but a lack of documentation meant that I
> could not be sure that they would give me all the functionality I need, and
> I did not want to spend a lot of time only to find that it was wasted.
Well, it's more fun to write code than docs!
I don't know anything about OGL, but it sure looks like it was made for
this sort of thing! Did you ask on the list? Do we know if the author
(of the python version) is actively maintaining it or at least answering
questions?
Anyway, I find myself doing this too, but I think it is a mistake -- if
there is a lib that does most of what you want, and it is open source, I
think it makes more sense to use that lib, and then add the feature or
tow you may need, rather than starting from scratch -- unless your goal
is to learn about drawing (or whatever)
> also looked at DragImage
very minimal
> and PseudoDC in the demo. I am particularly
> impressed with PseudoDC - it works so smoothly, on gtk2 and on msw, but
> again cannot be sure that it would give me what I need.
the question shouldn't be "will it give me what I need", but rather,
"will it prevent me from building what I need" -- and I'd think a post
or two to this list would probably answer that for you.
PsuedoDC is limited to DCs, so if you need any of the featured unique to
GraphicsContext (anti-aliasing, alpha-blending, complex paths), it's
probably not the way to go. It's still a lot more low-level that
FloatCanvas or OGL though. I might have build FC on top of it if it had
existed when I wrote FC. Though DCs inherently don't support full
zooming and scaling, so perhaps not.
> 2. The attached program shows part of what I am trying to achieve. I have
> actually got it working 'well enough' that I was ready to move on to other
> things, so unless there is something fundamentally wrong with my approach I
> am a bit reluctant to go back and revisit it now.
well, I think that question is: how many more features might you need?
scaling? panning? more complex draw objects, etc. The nice thing about
using a more feature lib is that you can get a lot of these features fro
free -- even if you don't need them when you get started.
> How much effort would
> there be in re-implementing this in FC? I am still getting some flicker on
> msw, so if FC would help remove this it could be a reason to reconsider.
From a quick look, this would be pretty easy to do in FC1 (I'm not as
sure about FC2 -- it's brand new). The best way to check it out is to
take a look at the demos in the source (I don't think all the little
ones are distributed with wxPython right now):
http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/Demos/
MovingElements.py
Should get you started. You can ask specific questions on the
floatcanvas mailing list.
It may be quite doable with FC2 as well -- ask on the list. I'm not yet
up to speed with that.
> 3. I may revise my entire approach anyway, depending on how my project
> evolves. I am trying to create an 'executable' business process, which means
> that the drawing must be saved in a structured format (probably xml) which
> can be fed into a workflow engine, which I am writing at the same time.
> Instead of allowing the user to manipulate the drawing directly, and
> inferring the structure from the drawing, I may end up having the user
> manipulate the structure, and then re-generate the drawing from the
> structure after each change.
>
> The jury is still out on the best way to accomplish this. Any comments will
> be much appreciated.
This seems to be begging for an MVC (or MVP) structure -- you need a
data model, and that model could be manipulated in more than one way --
with the GUI, or otherwise programmaticly.
FC2 was designed with MVC in mind, so it may be a bit easier, but you
could certainly do it with FC1 too.
Christopher Barker
> sure about FC2 -- it's brand new). The best way to check it out is to
> take a look at the demos in the source (I don't think all the little
> ones are distributed with wxPython right now):
>
> http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/Demos/
>
> MovingElements.py
>
> Should get you started.
Make sure to check out Tree.py too.
Robin Dunn
> Frank Millman wrote:
>> 1. This is my first attempt at drawing, so I am definitely feeling my
>> way. I
>> have looked at OGL and OGLLike, but a lack of documentation meant that I
>> could not be sure that they would give me all the functionality I
>> need, and
>> I did not want to spend a lot of time only to find that it was wasted.
>
> Well, it's more fun to write code than docs!
>
> I don't know anything about OGL, but it sure looks like it was made for
> this sort of thing! Did you ask on the list? Do we know if the author
> (of the python version) is actively maintaining it or at least answering
> questions?
He still answers questions now and then, and I've been applying patches
that have been submitted. Since it's all Python code now it's much
easier for the people using OGL to be able to fix bugs or create
enhancements for it, and there's been a few instances of that happening
over the past few years.
Christopher Barker
>> 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!
Frank Millman
> From a quick look, this would be pretty easy to do in FC1
> (I'm not as sure about FC2 -- it's brand new). The best way
> to check it out is to take a look at the demos in the source
> (I don't think all the little ones are distributed with
> wxPython right now):
>
> http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/Demos/
>
> MovingElements.py
>
> Should get you started. You can ask specific questions on the
> floatcanvas mailing list.
Ok, I installed numpy, so now I can run the wxPython demo.
I downloaded MovingElements.py and tried to run it, but it failed because
FC.Arc does not exist. Looking at svn, I see it was added in August 2007. I
am using wxPython 2.8.7.1, so it looks as if the version of FC bundled with
that is too old.
I tried to download the latest version of FC using Tortoise svn. I gave it
this repository -
http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/
It failed with the message 'Error: Repository moved permanently to
'/viewvc/wx/wxPython/3rdParty/FloatCanvas/';please relocate'
I'm not sure what to do next - can you give some assistance please.
Thanks
Frank
Nitro
> Christopher Barker wrote:
>
>> From a quick look, this would be pretty easy to do in FC1
>> (I'm not as sure about FC2 -- it's brand new). The best way
>> to check it out is to take a look at the demos in the source
>> (I don't think all the little ones are distributed with
>> wxPython right now):
>>
>> http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/Demos/
>>
>> MovingElements.py
>>
>> Should get you started. You can ask specific questions on the
>> floatcanvas mailing list.
>
> Ok, I installed numpy, so now I can run the wxPython demo.
>
> I downloaded MovingElements.py and tried to run it, but it failed because
> FC.Arc does not exist. Looking at svn, I see it was added in August
> 2007. I
> am using wxPython 2.8.7.1, so it looks as if the version of FC bundled
> with
> that is too old.
>
> I tried to download the latest version of FC using Tortoise svn. I gave
> it
> this repository -
>
> http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/
Replace viewvc with svn, i.e. use
http://svn.wxwidgets.org/svn/wx/wxPython/3rdParty/FloatCanvas/
I think viewvc is just the svn front-end on the webserver which allows you
to browse the sources with your browser.
-Matthias
Frank Millman
> > I tried to download the latest version of FC using Tortoise svn. I
> > gave it this repository -
> >
> > http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/
>
> Replace viewvc with svn, i.e. use
>
> http://svn.wxwidgets.org/svn/wx/wxPython/3rdParty/FloatCanvas/
>
> I think viewvc is just the svn front-end on the webserver
> which allows you to browse the sources with your browser.
>
> -Matthias
It worked! Thanks, Matthias
Frank
Pierre Hjälm
> He still answers questions now and then, and I've been applying patches
> that have been submitted. Since it's all Python code now it's much
> easier for the people using OGL to be able to fix bugs or create
> enhancements for it, and there's been a few instances of that happening
> over the past few years.
That would be me. Unfortunately I no longer work on my project where I
used OGL so my grasp of it is quickly fading.
But from time to time I do answer questions.
I tend to at least read all threads with "OGL" in the subject.
--
Pierre Hjälm, OGL - less and less
Frank Millman
>
> From a quick look, this would be pretty easy to do in FC1
> (I'm not as sure about FC2 -- it's brand new). The best way
> to check it out is to take a look at the demos in the source
> (I don't think all the little ones are distributed with
> wxPython right now):
>
> http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanv
> as/Demos/
>
> MovingElements.py
>
> Should get you started. You can ask specific questions on the
> floatcanvas mailing list.
>
> It may be quite doable with FC2 as well -- ask on the list.
> I'm not yet up to speed with that.
>
Hi Chris
I installed numpy, downloaded the latest FC1, and ran a couple of the demos.
They do look nice.
However, and I really don't want to appear ungrateful, I will stick with my
own for now -
- it is working, and I have got a mountain of other stuff to tackle
- I don't need any of the extra features of FC, such as zooming and handling
thousands of objects
- I have even got rid of the flicker on msw - see a separate post reporting
a small oddity on gtk2
I will definitely look at FC again, when I have more time, and when FC2 is
more stable. I assume you will report progress to this list, so I will keep
an eye open.
Many thanks for all your input - I really do appreciate it.
Frank
Christopher Barker
> I installed numpy, downloaded the latest FC1, and ran a couple of the demos.
> They do look nice.
thanks.
> However, and I really don't want to appear ungrateful,
no gratitude expected!
> - it is working, and I have got a mountain of other stuff to tackle
working code is working code -- there is a lot to be said for that!
> I will definitely look at FC again, when I have more time, and when FC2 is
> more stable. I assume you will report progress to this list,
we will.
But for the record, FC1 is pretty stable, if it does what you need now.