I am going to be creating a class that is going to be drawing lines on a canvas. It will be similar to what you might expect when graphing mathematical functions. There might be 1 to 6 lines drawn on the graph.
My original plan was to make each line a Group2D made up of several CurveShape objects (in this case small straight line segments) that are connected head to tail to make up the entire line.
With the recent versions of Xojo, a new class has been made available GraphicsPath. In my context, a GraphicsPath instance would seem to be similar to a Group2D made up of a collection of CurveShape objects. I understand that GraphicsPath can draw Bezier lines but that is not my use case.
Basically, I am trying to figure out whether one or the other approach has some advantages that I am not seeing. In general, In broad strokes, I am trying to understand just what new functionality the GraphicsPath is bringing to Xojo. What new advantage does it have?
I am not sure either… It seems one is creating an object, but once created one does not have have access to any of the properties, you can only print it (to whatever output). Object 2D can do all that currently a graphics path can do, but has more functionality (rotation - which can save us a lot of math) and You can get at the properties after creation and change them which makes them more reusable once created.
I Know Object2D is home grown (IIRC that was Joe Strout’s baby) and don’t know if GraphicsPath is… But is seems to me as Object2D seems to work well, and has more capabilities I cannot see the purpose of GraphicsPath either…
Of course if GraphicsPaths could be used to created irregularly shaped clipping areas, it could be useful (can it?), but then again that could be added to object2Ds…
Its seems to me Xojo would be better off building off of object2Ds to support vector graphics output… it would certainly help with compatibility with a lot of existing code… if that matters these days to Xojo inc.
GraphicsPath is closer to the CoreGraphics “Path” API, and so I would expect the best performance from it, but I absolutely have no idea what Object2D is using, so I might be wrong.
It looks to me, like an Object2D has control over rotation, scaling and translation. If you need these with the GraphicsPath, you may need to consider using declares, I may be wrong, but when I looked at the docs I didn’t these functions for the graphics class.
[quote=488812:@Sam Rowlands]GraphicsPath is closer to the CoreGraphics “Path” API, and so I would expect the best performance from it, but I absolutely have no idea what Object2D is using, so I might be wrong.
[/quote]
For myself, most of the time I am only interested in doing things X-Platform…
I paid for RB/RS/Xojo to do things under the hood to provide both a lot of solid/consistent X-platform functionality and good performance without me having to worry about the hows. … Though it seems too often I am disappointed with the progress on those things these days.
[quote]
It looks to me, like an Object2D has control over rotation, scaling and translation. If you need these with the GraphicsPath, you may need to consider using declares, I may be wrong, but when I looked at the docs I didn’t these functions for the graphics class.[/quote]
That’s why i would have thought enhancing/optimizing Object2Ds would have made more sense that introducing a GraphicsPath class… After all an Object2D should be able to be converted under the hood to a path (or multiple paths executed in order) if needed for execution speed …
I am sure there is a good sized body of existing code using object2Ds that could benefit … I know I have written a decent amount over the years.
I usually try and stay clear of Xojo criticism because it does not seem to me to be productive. I am not interested in arguments about naming.
But when they finally do officially add something to the language like GraphicsPath, it is no longer a “future” thing that they want to stay mum about. Now it is out there. The documentation is sparse. I never like that, but whatever. I understand that producing documentation is a pain.
But really, it should be incumbent upon them to explain just why this feature has been added. I assume it took a fair amount of work to create the feature.
But, as expressed in my introductory note, I am not sure what GraphicsPath is for except for Bezier lines perhaps. I like to jump on new things under the assumption that they have been added for some reason: to complement or extend or speedup or future proof or simplify the existing Xojo code base. But in this case, instead, there seems to be a huge overlap with Object2D/Group2D and not much guidance about why the new is preferable to the pre-existing.
The documentation doesn’t even do much in the way of cross-referencing these two worlds. It is as if they are not in the same language. And on the surface of things, it seems to me that Object2D is more robust and powerful.
But if there enthusiasts out there who find GraphicsPath to be really superior to what has already been present, I would love to hear from you. For the moment, my instinctive reaction is a little like Karen’s. Why didn’t they just build on Object2D/Group2D?
[quote=488818:@Karen Atkocius]For myself, most of the time I am only interested in doing things X-Platform…
I paid for RB/RS/Xojo to do things under the hood to provide both a lot of solid/consistent X-platform functionality and good performance without me having to worry about the hows. … Though it seems too often I am disappointed with the progress on those things these days.[/quote]
Please understand that this was just a guess, I don’t actually know what Xojo uses underneath, I have experience with CGPaths and this appears to be very similar to me, which is why I made that assumption.
I am sorry if I lead you to believe something that may or may not be true, based upon my assumptions.
Hi,
I use Graphicspath to create masks in pictures
I can then rotate with pixmap shapes, represent smaller, larger
The advantage over polygam is the open and closed
Presentation (colored lines from pictures or lasso sections)
The disadvantage is that I have only one item on Graphicspath
seperade Paralelle Create a list with basic data and first have to create a new graphic path from this list.
Likewise, there is still a difference between the fill and draw representation around the line width and must be calculated from the basic data with minus line width / 2.
It would of course make sense to pack a Object2D immediately
my solution via pixmap shapes easily compensates for this.
With the Pixmapshapes I can still access the graphics data Pixmapshape.image.graphics … and thus change the shapes directly.