add 'perimeter' anchors

[GoogleCodeExporter]

a useful feature would be to provide anchors that could track around shapes 
that were not rectangular.  Every anchor implementation in jsPlumb currently 
assumes rectangular nodes, yet the underlying mechanism supports arbitrary 
anchor placement.  So a new type of Anchor - an extension of DynamicAnchor - 
whose locations traced the perimeter of some shape would be useful and not 
incredibly difficult to implement.

shapes i'm considering are:

circle
ellipse
diamond
triangle
rectangle
square

(rectangle and square are in there just for completeness, really, since they 
will mimic existing behaviour).

a proof of concept is here:

http://morrisonpitt.com/jsPlumbTest/tests/miscellaneous/perimeter-anchors-test.h
tml

Original issue reported on code.google.com by simon.po...@gmail.com on 15 Aug 2012 at 12:40

[GoogleCodeExporter]

This proof looks great. Any chance you can make the anchor shift at a per pixel 
level to avoid the slight jump that is happening now. This is one advantage to 
using the "hack" (anchor at the center with overlays that end at the edge of 
the sphere), the motion is smooth as butter and it looks like the anchor is on 
the circumference.

Original comment by alanlind...@gmail.com on 15 Aug 2012 at 3:21

[GoogleCodeExporter]

not sure what you mean by "per pixel level"...

it jumps because this is an approximation. currently it uses 40 sample points - 
to get it smoother we could use more sample points but then we perhaps run the 
risk of bad performance on slower browsers.

Original comment by simon.po...@gmail.com on 15 Aug 2012 at 6:15

[GoogleCodeExporter]

Ah ok, I thought you had it set to jump every x pixels to the next anchor 
point. I didn't realize that it was limited to / based on 40 anchor points. 
This is still cool. It would be even cooler if there weren't a limited number 
of anchor points but the anchor actually just slid around the shape.

Original comment by alanlind...@gmail.com on 15 Aug 2012 at 8:27

[GoogleCodeExporter]

yeah that is what it is doing, really, where N is related to the circumference 
/ 40.  using more sample points would bring N down but also make for more 
processing.

the other option is to do this as a function, and then calculate the minimum 
difference between the function for each shape.  this could be a lot more work 
though. and i'm mindful of the fact that we are limited by the resolution of 
people's monitors anyway.  

Original comment by simon.po...@gmail.com on 15 Aug 2012 at 10:48

[GoogleCodeExporter]

this is going in to 1.3.13. default number of points is 60.  for now these 
shapes are supported:

circle
ellipse
rectangle
square
triangle (one point at top center, other two points at bottom corners)
diamond (a square rotated through 90 degrees)

i'm going to see how this goes down with people.  there;s stuff i could add in 
future releases, like the ability to supply your own path, and perhaps rotation.

Original comment by simon.po...@gmail.com on 28 Aug 2012 at 7:28

• Changed state: Fixed
• Added labels: 1.3.13