Re: Feature freeze



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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]