On Wed, 04 Dec 2002, Dave Hoover wrote:
> Hi Lars, your edge detection code looks nice. There are a few weird
> things that happen when you slide objects over each other, but that may
> be inevitable since the only information available is the
> distance_to_point. But to create nice looking bond graphs in a snap, it
> works great with the flowchart - box object adjusted to have a center
> connection point. Diff included, if you want it. I did not number the
> center point connection #0 to avoid breaking existing box objects...
> Check the file out to make sure I did it correctly, if you want to
> incorporate it. I use it, and it seems to work fine. In the medium
> term, I will simply create something similar (with no outer connection
> points) in the bond graph library.
I don't think I want to incorporate that now. First the Gtk 2.0 release,
then we can look at how this gap code changes the way we design objects. I
might then want the middle point to be somewhat different, maybe it should
attract lines from the entire interior of the object.
> About the ellipse: I tried out the math, and ran into things that would
> be messy to do (requiring polynomial root solvers). I found something
> on the web that confirms this (see below).
http://www.kevlindev.com/gui/math/intersection/ has some code that
supposedly does line-ellipse intersection, and it doesn't look too evil.
http://astronomy.swin.edu.au/~pbourke/geometry/sphereline/ suggests
treating the ellipse as a scaled circle to be able to do intersection like
a circle.
>>Probably useful. However, we still have to figure out what to do for
>>arc, zigzagline, polyline and bezier.
>>
> For polyline, it will be simple. calculate_gap_endpoints and
> calculate_object_edge will work.
What happens if the gap is greater than the end segment?
> For arcs and bezier lines, there will be no code overlap, I think.
> The concept of fractional or
> proportional gap would require calculating bezier/arc length, and then
> not drawing the last 'x'
> units of the line. Impossible, I think, for bezier lines without a
> math engine running inside
> dia. For arcs, probably possible--but with new code. Is it worth it?
I'm not sure it's worth it. Let's certainly not spend time on it now.
>>Look at todays anoncvs first, make a unidiff off of that.
>>
> About the included patch:
>
> line_calculate_intersection_points is a separate function because it
> may be useful elsewhere.
>
> The same goes for calculate_gap_endpoints since it is a basic
> geometric transformation. I used it a lot when doing my example arrow
> code.
>
> Having gap as a separate structure makes the code easier to read, and
> it also made my example decoration code much cleaner. Did you try it
> out, or were you too busy working on the edge detection stuff?
Didn't try it out. I'm leaving this stuff until after the release.
> All of the
>
> (line->object_edge_start || line->object_edge_end ||
> line->absolute_start_gap || line->absolute_end_gap ||
> line->fractional_start_gap || line->fractional_end_gap) {
>
> stuff has been moved into line_calculate_visible_endpoints() and
> line_calculate_intersection_points(). This makes the rest of the
> code much more readable. These functions just copy their inputs to
> their outputs if the gap/edge variables are not set.
>
> This adds a couple of function calls--I don't know if you're a
> clock-cycle counter, or not. I prefer code that's easy to read.
> Tell me if this is a problem.
We definitely go by the old Unix adage: Make it work, make it right, make
it fast. Some implementations of other things are really quite slow, but
we don't try to optimize until we see that speed is a problem. It's more
important that we all can understand the code -- it's rather complex as it
is.
-Lars
--
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I |----------------------------
will defend to the death your right to say it." | Where are we going, and
--Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket?