Re: [Inkscape-devel] new booleans patch
After some testing I can say that the four basic operations (union, intersect, diff, symdiff (which is similar to combine, except that it adds nodes where sides intersect)) are very stable. I could not force them to do something wrong or misbehave. The only problem is that when more than one object is selected, these commands only operate on the first two objects while others simply disappear. But I think it will be easy to fix. The quality of these operations seems to be good: no extra points, no curve distortion.
Inset and offset, although very very useful, are unfortunately more buggy. When you do them repeatedly, the number of nodes grows very fast, and soon some very strange artifacts appear (such as dense "clusters" of nodes that really distort the shape). Also, when you do inset or offset to a path with many nodes, it becomes extremely slow, and Inkscape may hang for minutes. Sometimes, a path simply disappears (the object is there, but its d="" attribute is empty).
The outline stroke function works acceptable. Sometimes the strokes are distorted (usually near ends or sharp cusps) but the number of nodes in the resulting shape is not too big, and for simple strokes it gives good results.
Actually, having looked at the patch, I think we really need to leave this 'til the next release. Three reasons: First, it's in C++ and we had decided to hold off on changes that commit us to C++ until 0.37.
What is the value of preserving plain C compilability? Will people complain if we require C++ for 0.36? I, for one, do not care what is the compiler, so long as the program works :)
Second, it's a good bit of code, and deserves to be tested.
The best way to test is to release! We're not doing 1.0, after all. It's just a 0. release.
Third, we will need to do some additional development (buttons, etc.) to integrate it.
I could certainly live without buttons - menu commands and shortcuts are quite enough for the time being. Besides, we could borrow buttons from the other patch, and I think I remember seeing the icons somewhere in the sodipodi innards already.
So my opinion is this: let's include the four boolean operations and outline path for this release, and then help the author debug the inset/offset operations for the next release.
_________________________________________________________________ Get holiday tips for festive fun. http://special.msn.com/network/happyholidays.armx
bulia byak wrote:
After some testing I can say that the four basic operations (union, intersect, diff, symdiff (which is similar to combine, except that it adds nodes where sides intersect)) are very stable. I could not force them to do something wrong or misbehave. The only problem is that when more than one object is selected, these commands only operate on the first two objects while others simply disappear. But I think it will be easy to fix. The quality of these operations seems to be good: no extra points, no curve distortion.
Sounds like a good job! My french is comme ci comme ça but I think the author is using a BSP tree to do the searching and resulting intersecting - an excellent approach!
Inset and offset, although very very useful, are unfortunately more buggy. When you do them repeatedly, the number of nodes grows very fast, and soon some very strange artifacts appear (such as dense "clusters" of nodes that really distort the shape). Also, when you do inset or offset to a path with many nodes, it becomes extremely slow, and Inkscape may hang for minutes. Sometimes, a path simply disappears (the object is there, but its d="" attribute is empty).
The outline stroke function works acceptable. Sometimes the strokes are distorted (usually near ends or sharp cusps) but the number of nodes in the resulting shape is not too big, and for simple strokes it gives good results.
These operations are quite hard to do, and I looked at the code and think it is the wrong/incomplete approach. I'll look closer once we move to C++.
Actually, having looked at the patch, I think we really need to leave this 'til the next release. Three reasons: First, it's in C++ and we had decided to hold off on changes that commit us to C++ until 0.37.
What is the value of preserving plain C compilability? Will people complain if we require C++ for 0.36? I, for one, do not care what is the compiler, so long as the program works :)
Indeed, but that's what we've been aiming for for this release, so I think it might be dangerous to switch to C++ at such short notice. I would rather release 0.36 ASAP and leave this for the next release - we(you)'ve made a lot of significant changes already and adding a whole slab of code at this point may be bad.
Second, it's a good bit of code, and deserves to be tested.
The best way to test is to release! We're not doing 1.0, after all. It's just a 0. release.
You've nearly convinced me :)
Third, we will need to do some additional development (buttons, etc.) to integrate it.
I could certainly live without buttons - menu commands and shortcuts are quite enough for the time being. Besides, we could borrow buttons from the other patch, and I think I remember seeing the icons somewhere in the sodipodi innards already.
So my opinion is this: let's include the four boolean operations and outline path for this release, and then help the author debug the inset/offset operations for the next release.
I agree with this if you can check the code over reasonably carefully - can you commit it to a branch in CVS and we can all have a play first? I would like to look at using yafoyah's maths tools pervasively through inkscape too - peter and I have spent quite some time thinking about this issue. But it should wait until 0.37.
MHO, njh
participants (2)
-
bulia byak -
Nathan Hurst