Typescript and Jangaroo

October 5, 2012 2 comments

I think I’m about to set a new personal record for lowest number of posts in a given year. Is it really October already?

Well, at least I’m working and on a pretty interesting project from both a mathematical and programming perspective, so I should be thankful for that.

I am, however, still interested in doing something new and interesting this year and I think it will be along the lines of a computational geometry library and/or version of the Freehand Drawing Library in Javascript.  The CG library is likely to be released through a series of posts in an open-source context similar to the TechNotes series I did in Actionscript for Flash/Flex programmers.  The JS FDL is intended for clients doing mobile development in an HTML/JS environment.  Okay, it’s mostly for me to have fun – I confess! However, an extra license or two never hurt anyone 🙂

To this end, I’m currently looking into both Typescript and Jangaroo.  Coffeescript is on the list as well, but I’m really looking to get back into Visual Studio and C++/C# development, so Typescript has some natural appeal.  Perhaps sufficient time will arise to deep-dive into all three?

I guess we’ll have to wait and see.  Sorry again for the waiting part.  This has been a strange (but fortunately very profitable) year.

Privatizing Freehand Drawing Library

September 7, 2012 1 comment

I’m into an extension of my prior gig, so time is still very limited.  In addition to family issues, what little time remains is dedicated to supporting existing beta users of the Freehand Drawing Library.  And, these users just scored big time.  I’ve decided to keep the library private and license it only to customers, providing requested customization at an hourly rate.

Existing beta users will continue to receive free updates of the core library and the current beta period is now permanently closed.  I will blog about development of the library as a segue into discussing some of the math behind the programming.  I also hope to start a series on computational geometry in Javascript some time this fall.

Thanks for bearing with the extreme lack of posts this year 🙂

An Extension

August 30, 2012 1 comment

Well, this is what every contractor likes to hear – “you’ve been extended.”  Although relatively short, it means that between the gig, taking care of family, and supporting users of the Freehand Drawing Library, my lack of blogging will also be extended for a while.

On a personal note, I hope to get back into tennis after being out of practice since April due to a foot injury.  Looking forward to hitting this afternoon instead of just watching the US Open 🙂

Categories: General, Tennis Tags: , , ,

QA and Change Requests

August 7, 2012 2 comments

Okay, well, I hope that tells you where my summer is at this point and helps explain the lack of posts.  With some luck, I’ll be back to work on the Freehand Drawing Library later this month.

Thanks!

Categories: General Tags: , , ,

Gone Underground

June 29, 2012 Comments off

No, I haven’t bugged out.  Just going through the typical ‘long haul through the summer.’  For some reason, it’s been this way every year since 2006.  It’s a nice problem to have, however, so no complaints here.  Just no posts for a while.

Thanks.

Categories: General

Geometric Shapes in Freehand Drawing Library

May 11, 2012 Comments off

Well, here’s another example that I would not have though appropriate for the Freehand Drawing Library.  Regular  geometric shapes might be drawable as strokes (i.e. press-move-release) with some sort of external control to force straight or constant-angle line segments.  That concept, however, does not seem to fit in a freehand or freeform drawing library.

After some thought, many geometric shapes can be defined (even if somewhat arbitrarily) by a bounding rectangle. The current TwoPoint stroke class could easily be extended to define such a bounding rectangle.  By injecting different drawing engines, it is possible to draw a nearly unlimited number of shapes inside that bounding rectangle.

To illustrate the idea, a GeometricShape class was created that extends TwoPoint.  I developed three sample drawing engines for this stroke, Ellipse, Triangle, and BasicArrow.  Each engine draws the bounding rectangle while the mouse is down and clears it on release.  Pre-draw parameters may be assigned to each engine to further control the shape (i.e. select an isosceles or equilateral triangle or alter arrow shape).

While these engines may seem trivial, they open the door to creating a wide variety of such drawings in the FDL, and, all line decorators are available for each shape.  So, if you want a dashed ellipse or dotted arrow, it’s simply a matter of injecting the desired line decorator.

An astute reader (aka existing beta users) may ask, “what about editing?”  It’s easy to modify or extend these shape drawing engines to return the vertex information for the shape.  This information can be edited and then stored in a value object.  That VO may be sent as auxData in the stroke dataProvider.  If present, the stroke could simply redraw the shape directly from the edited vertex information instead of a bounding rectangle.  It’s all supported in the FDL architecture.

An update is going out to all beta users this morning.

Categories: Flex, Math, Portfolio

Editing A Cubic Bezier Spline

May 7, 2012 Comments off

A couple months ago, this was something I believed I would never say about the Freehand Drawing Library.  Now, the library is and always will be a drawing library. Editing is not part of the core library architecture, however, it is something that requires a level of support inside the library.  In the past, this was accomplished by caching the sequence of mouse motions used to define a stroke.  The points could be edited and manually assigned to a stroke, either all at once or in an ENTER_FRAME event to animate the stroke.

This works cleanly with a simple interface for typical strokes, i.e. touch-move-release motions.  Now that the FDL supports splines and possibly other constructs that stretch the definition of a stroke, what about editing more complex drawings?  I want to maintain a light interface and not make editing operations an integral part of the library.  That inevitably leads to interface and code bloat in an attempt to satisfy every possible combination of customer-created editor.

I think it was the movie ‘War Games’ that popularized the phrase, ‘always leave yourself a back door.’  The back door to stroke manipulation outside normal FDL methods is to use arbitrary name-value parameters.  Every stroke has the ability to access or mutate arbitrary data objects.  It’s only two methods in the API, but they provide a wide variety of capability to custom strokes.

I added a simple spline editor to the PolyLine demo as an illustration.  After creating a spline (by clicking the end button), the knot/tangent display is overlaid on top of the stroke as shown below.

The spline knots are already available since they were manually assigned to the stroke.  The tangent information is entirely encapsulated inside the drawing engine, inside the stroke.  That information is obtained by the demo via a parameter request,

__stroke.getParam( “tangent” + i.toString() );

It is the responsibility of each stroke class to document all custom parameter queries and settings.  The above query returns in- and out-tangent values in an Object and that information is passed to the editor.  Knots may be dragged, which cause a parallel shift in the tangent.  The new knot and tangent information is conveyed back to the stroke with a sequence of parameter settings,

__stroke.params = { “changeKnot”:{vertex:index, x:editor.knotX, y:editor.knotY} };

or

__stroke.params = { “changeInTangent”:{vertex:index, x:editor.inTangentX, y:editor.inTangentY} };

__stroke.params = { “changeOutTangent”:{vertex:index, x:editor.outTangentX, y:editor.outTangentY} };

If a spline drawing engine is assigned to the PolyLine, it passes this information onto the internal FDLIntepolatingSpline instance.  A non-spline engine (line segments) ignores the parameters.

The screenshot below shows the result of a knot drag.

After dragging the middle vertex, the following screenshot shows the result of editing the first-vertex out-tangent.

This is all supported by the existing architecture, but there is one wrinkle.  If the edited spline is to be saved and then redrawn at a future time, we must have the facility to record the tangent edits *and* bypass the tangent Command when the spline is reconstructed.

I added an auxData parameter to the StrokeDataVO, which allows arbitrary auxiliary data to be recorded for a stroke.  It’s easy to deep-copy an Object with a ByteArray, so preserving immutability was no problem.  Now, by adding support for a ‘redraw’ parameter in the PolyLine stroke, the spline can be redrawn with arbitrary tangents supplied by external data instead of the tangents computed by the injected tangent Command.