Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!emory!mephisto!prism!fsu!loligo!pepke
From: pepke@loligo (Eric Pepke)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: arrowheads at the end of lines.
Message-ID: <396@fsu.scri.fsu.edu>
Date: 8 Dec 89 22:19:59 GMT
References: <QZSVM7u00WB60VEUVB@andrew.cmu.edu> <1514@sequent.cs.qmc.ac.uk> <393@fsu.scri.fsu.edu> <sZTyxfu00Uh_M1fXtU@andrew.cmu.edu>
Sender: news@fsu.scri.fsu.edu
Reply-To: pepke@loligo.UUCP (Eric Pepke)
Organization: Supercomputer Computations Research Institute
Lines: 76

In article <sZTyxfu00Uh_M1fXtU@andrew.cmu.edu> ba0k+@andrew.cmu.edu (Brian Patrick Arnold) writes:
>
>Hello there,
>
>   no offense to Mr. Pepke, but if you re-read my last post:
>
>>We have tried to replace the trig [see my last post] with more
>>straightforward calculations to speed up this algorithm, but this
>>actually slowed things down a bit. 

None taken!  I apologize for not reading your posting all the way through the
first time.

> [example code]
>we scale the endpoint to be flush with a rectangle at the destination. 
>Also, using the polygon tool saves you from drawing a couple of extra
>lines.
>
>We found this version to be a bit slower than our trig version.  I
>attribute this to interpreted HyperTalk execution overhead.  If you
>remain unconvinced, you can do your own timing tests.  I recommend the
>trig version for arrow drawing as presented in my last post, or writing
>an XCMD to do the math.

Well, I just converted my basic non-trig algorithm to HyperTalk and found 
it to be slightly faster than your trig algorithm (about 7%).  To keep from 
comparing apples and oranges, I used your clipping code verbatim and also your 
polygon trick.  (I usually use lines, because that's what most of our 
researchers seem to prefer.)  I did the test on a Mac II with an Apple
color board set to two colors, System 6.0.4, Multifinder with nothing else
running except After Dark in the background.

Here is the converted algorithm:

ON DrawALink fromLoc,toLoc,toSize
  --
  -- Draw a line from fromLoc to an arrow head flush with the rectangle
  -- toSize located at toLoc.  Side effect: leaves you with polygon tool.
  --
  -- fromLoc   starting point
  -- toLoc     end point
  -- toSize    "width && height" of a rectangle located at toLoc
  
  set cursor to busy -- feedback when redrawing
  
  -- Calculate longitudinal unit vector
  put item 1 of toLoc - item 1 of fromLoc into XL
  put item 2 of toLoc  - item 2 of fromLoc into YL
  
  -- scale endpoint (toLoc) to account for toSize rectangle overlap
  IF abs(YL/XL) < ((word 2 of toSize / word 1 of toSize)) THEN
    put (1-(abs(XL)-(word 1 of toSize)/2)/abs(XL)) into factor
  ELSE put (1-(abs(YL)-(word 2 of toSize)/2)/abs(YL)) into factor
  subtract round(XL*factor) from item 1 of toLoc
  subtract round(YL*factor) from item 2 of toLoc
  
  --Normalize longitudinal vector
  put SQRT(XL * XL + YL * YL) into L
  divide XL by L
  divide YL by L
  
  --Draw arrow
  choose line tool
  drag from fromloc to toLoc
  choose regular polygon tool
  drag from round(item 1 of toLoc - 5 * XL), <option-return> 
  round (item 2 of toLoc - 5 * YL) to toLoc
END DrawALink
  
Eric Pepke                                     INTERNET: pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute  MFENET:   pepke@fsu
Florida State University                       SPAN:     scri::pepke
Tallahassee, FL 32306-4052                     BITNET:   pepke@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.