The Trunk: Morphic-fbs.677.mcz

Frank Shearar uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-fbs.677.mcz

==================== Summary ====================

Name: Morphic-fbs.677
Author: fbs
Time: 10 August 2013, 10:55:08.711 pm
UUID: 1874456c-56bc-fc43-a073-245fb196b965
Ancestors: Morphic-cmm.676

Move the #Curvier preference into CurvierMorph.

=============== Diff against Morphic-cmm.676 ===============

Item was changed:
  PolygonMorph subclass: #CurvierMorph
  instanceVariableNames: ''
+ classVariableNames: 'DrawCurvier SlopeConstantsCache'
- classVariableNames: 'SlopeConstantsCache'
  poolDictionaries: ''
  category: 'Morphic-Basic-NewCurve'!
 
  !CurvierMorph commentStamp: '<historical>' prior: 0!
  I want to be merged into PolygonMorph.
  I implement Closed Cubic Curves and restructured routines to ease maintence and development.
 
 
 
  New way to calculate curves.
 
  cVariables
  SlopeConstantsCache anArray size 2  indexed by nVerts \\2 .
  Each element is an array of integers. The integers represent the constants for
    calculating slopes for closed cubic curves from the vertices.
 
 
 
 
  Class Variable SlopeConstantsCache holds a pair of arrays for even and odd number of vertices( aka knots).
  Each array holds a series of constants in Integer form.
  This allows slopes to be calculated directly from the array of knots.
  Wonderfully it turns out that only two arrays are needed.
  By matching up the knots equidistant from the point in question;
  Summing the weighted differences of the pairs the unscaled slope can be arrived at.
  The scale needed to get the slopes needed is trice the reciprical of the next integer in the series.
  We leave the division til last to get the full benifit of the integer arithmetic.
 
  Rounding the vertices before calculation is recommended.
 
 
  Instead of calculating the number of curve subsegments in lineSegDo we add a ninth array to curve state to allow the number to be precalculated.
  Getting better looking curves motivates finding a better way of guessing n. So this provides a framework for trying.
 
  For the first pass we just used the constant 12 for every thing.
  In the second pass we judge the number of segments by starting with two and doubling the number until the distance of the curve no longer increases.
  Then we hone in using a binary search to find the smallest number of segments with that same curve length.
 
 
  We have changed some assumptions. Previously curves were figured by solving for the second derivative  first and using the results to determine the slope and the third derivative. So lineSegDo counted on the last second deriv being a number it could use in its calculation of the number of subsegments.
 
  Currently we just solve for slopes and the second and third derivs are derived from that.
  Also the derivation for the second and third derivs only assume C(1) (first derivitive continuity). The calculations for the slopes are the only calcs using C(2) continuity. Therefore the slopes can alternately be chosen to fit some other chriteria  and the resulting curves will still be smooth to the first degree.
  A useful variant of closed slopes is to scale them by a constant.
 
 
  Also the last of each element of curvestate always reflects a closing segment. And we don't add an extra row for closed curves anymore.
  That is now lineSegDo's responsibility to be aware of as it was already doing with segmented curves. So the last n does not track its old value.
 
  Preferences:
  A Preference has been added to toggle between the old (ugly) closed curves based on natural cubic slopes and the new smooth algorythim. This doesn't make much difference while newcurves are a subclass of polygons but the ambition is for newcurves to supercede polygons. This will allow backwards  compatibility.
 
  Shapes: With closed curves a smooth oval results from rectagular or diamond vertices. So two menuitems have been added (to PolygonMorph) that allow the vertices to be set to these shapes using the current bounds of the polygon. The former state of vertices will be lost but it seems useful to lose a complicated shape and start fresh with a simple symmetrical one.
 
  Furthur on: Modify curveState to only contain slope and higher deriv information. Let the information about the knots only be held only in the vertices of the polygon. Once that is done curvestate will not have to be recalcutaled each time the polygon is moved but only when its shape changes.
 
  There is also some possible speed up to be had by refining or experimenting with other number of segment calculating schemes but not as much as preserving curvestate over a move.
 
  Furthur furthur on: Figure out how to combine straight and curved segments into a single shape in a pleasing way.
 
   
 
 
 
 
 
 
 
  !

Item was added:
+ ----- Method: CurvierMorph class>>Curvier (in category 'class initialization') -----
+ Curvier
+ <preference: 'Curvier'
+ category: 'morphic'
+ description: 'If true, closed CurvierMorphs will be smoother and more symmetrical all about. If false they will mimic the old curve shapes with the one sharp bend.'
+ type: #Boolean>
+ ^ self drawCurvier.!

Item was added:
+ ----- Method: CurvierMorph class>>drawCurvier (in category 'class initialization') -----
+ drawCurvier
+ ^ DrawCurvier.!

Item was added:
+ ----- Method: CurvierMorph class>>drawCurvier: (in category 'class initialization') -----
+ drawCurvier: aBoolean
+ DrawCurvier := aBoolean.!

Item was changed:
  ----- Method: PolygonMorph>>isCurvier (in category 'testing') -----
  isCurvier
  "Test used by smoothing routines.  If true use true closed curve splines for closed curves. If not mimic old stodgy curveMorph curves with one sharp bend.. Override this routine in classes where backward compatability is still needed."
+ ^ CurvierMorph drawCurvier!
- ^ (Preferences valueOfFlag: #Curvier)!

On Sat, 10 Aug 2013, [hidden email] wrote:

I think the above two methods should be replaced with this:

drawCurvier

  <preference: 'Curvier'
  category: 'morphic'
  description: 'If true, closed CurvierMorphs will be smoother and more symmetrical all about. If false they will mimic the old curve shapes with the one sharp bend.'
  type: #Boolean>
  ^DrawCurvier ifNil: [ true ]

Why?
- The setter method's name is derived from the getter method's name via
#asMutator. The getter method is always the method which holds the pragma.
So this code doesn't work.
- It's better to have a default value, than to get a debugger when the
variable is uninitialized.
- Capitalized selector names are unusual in smalltalk code, when no
external code/data/objects are involved.


Levente

Am 11.08.2013 um 08:23 schrieb [hidden email]:

Should we honor this plead?

On 10 August 2013 23:46, Levente Uzonyi <[hidden email]> wrote:
I'd largely agree, but I intentionally performed a _refactoring_ here,
preserving the API. We should do what you suggest, and keep Curvier
but deprecated and in 45Deprecated for eventual GC.

frank

On Sun, 11 Aug 2013, Frank Shearar wrote:

I don't see why should we keep a recently introduced method with no
senders, and an awkward name.


Levente