I have no idea why this discussion is in this thread, but...
Quote:
I think I'll be redoing the svg.datatype with libsvgtiny instead.
Did you ever do this? I've been poking the drawing.datatype this weekend and it's now in a basic working state where the majority of what libsvgtiny does can be pushed up to the superclass. So, I set aside the DR2D datatype and wrote an SVG one instead.
However, it crashes in pthread_open which is used by libxml2, with little explanation (although I assume it is some library or other that it thinks it has an interface for and actually doesn't). If you got your datatype to work with libsvgtiny, OR I guess the old one could have had the same issue if it used libxml2, do you know what it is looking for?
If I can get that working I might be in a position to release an early drawing/SVG datatype beta. Otherwise it'll be another two years before I look at it again.
On a related note, my SVG descriptor sucks because it seems to be lower down the food chain than the HTML one. How did you create your descriptor? (I might just be able to use it as-is, but it's linked to picture.datatype and I have no idea if that's a problem... dtdesc doesn't support drawing.datatype anyway of course)
I vaguely remember this one. There was something about pthreads which was causing issues. At the time we didn't have access to the source code, etc. so it was difficult to move forward on it.
Well, times have changed. This may be a good time to revisit the issue.
We'll need as simple a test case as you can make for starters.
I've been poking the drawing.datatype this weekend and it's now in a basic working state where the majority of what libsvgtiny does can be pushed up to the superclass. So, I set aside the DR2D datatype and wrote an SVG one instead.
I'm very curious about this "drawing.datatype" and whether you would like to consider contributing it to AmigaOS so it becomes an official component?
There's no particular documentation, just an overview and some out-of-date implementation thoughts. At the moment the subclass sends drawing directions and attributes to the superclass (drawing.datatype), which creates a linked list that it can render. This is all working and tested via Multiview and a dummy subclass which just sends some built-in commands, and resizing Multiview's window resizes the drawing as expected. As per my first post in this thread, it is currently complete enough for the capabilities of libsvgtiny (except text), although the primary objective was intended to be to support the DR2D specification.
I would very much consider contributing it to AmigaOS, that's the main reason it's on OpenAmiga. In fact, I think datatypes.library might need some tweaks to support GID_DRAWING (to allow NewDTOject/ObtainDataType to filter for drawing.datatype subclasses), and dtdesc will need to be able to create descriptors that identify themselves as "draw" subclasses (required for the filtering I think).
As for the pthreads crash source code, unless somebody else already has something sensible that demonstrates the problem, I'll have to get back to you. It needs to be written as a library I think to get the problem to show, which increases the complexity of writing a simple test case.
With regards the older svg datatype, when I was working on MindSpace, I always had trouble as soon as I wanted the datatype to render text. Other sorts of drawing/rendering were fine. Don't know if that's of any use or not.
However, it crashes in pthread_open which is used by libxml2
My build of libxml2 has threading disabled. I did that when xmoto was updated to use libxml2 instead of its own built-in tinyxml.
It would crash and I tracked it down to libxml2. There's a possibility that libxml2 with threading enabled may work when linked against programs coded in C instead of C++.
MickJT wrote: My build of libxml2 has threading disabled. I did that when xmoto was updated to use libxml2 instead of its own built-in tinyxml.
It would crash and I tracked it down to libxml2. There's a possibility that libxml2 with threading enabled may work when linked against programs coded in C instead of C++.
I'm using C (hate C++), however I'm using an older build of libxml2, so I will try the latest.
Some minor problems, but the new libxml2 works without error.
So does this mean there really is no problem with pthreads or did you just built it without threading support?
That's built without threading support. With it pthreads crashes as per the above stack trace.
Gotcha. I'll see if I can squeeze some time in this weekend to look into that crash.
What I need is a reproducible test case. Can you please package up the software/code and the steps necessary to make that crash happen? I'd love to try and get to the bottom of this one but my time is limited.
You'll need to copy the two .datatype files to SYS:Classes/DataTypes, and the contents of SObjs to SObjs:. Double-click on SVG and then double-click (or open into MultiView) rect1.svg. This should crash it.
I'm not sure how helpful the source is, since it only really calls svgtiny_parse and the rest cascades through various other libraries, but it's there anyway (dispatch.c is the important one).
I keep my fingers crossed for you to get the crash resolved! We really need to extend the datatype class set (and improve the entire datatypes infrastructure along the way).
Quote:
I think datatypes.library might need some tweaks to support GID_DRAWING (to allow NewDTOject/ObtainDataType to filter for drawing.datatype subclasses)
Absolutely.
Quote:
dtdesc will need to be able to create descriptors that identify themselves as "draw" subclasses
Some time ago I asked about dtdesc in the Hyperion forums. I was wondering if the OS dev team had sources to this tool because it's old and could do with an overhaul of the GUI (heck, I could even volunteer to do the job). The thread died out nevertheless.