Big Discussion: The future of Method Draw

[techninja]

Soooo... We've been living with a big kind of smelly elephant in the room for years now, and the topic has never come up. He pulls his weight when he needs to, even if he continues to drag us down often enough to not forget.

In fact it's so easy to break Method Draw (herein referred to as MD) by just trying to use it, it's laughable. Yet the interface remains clean, and (mostly) usable and better than the application components we've surrounded it with. The first task I was given for the notably different app PancakeCreator (herein referred to as PC), was to duplicate a number of SVGEdit/MD interface elements like selection rectangles and node control handles. I was a bit scared to create them, but I was even more scared of the huge, hacky and pretty well outdated codebase that is the somewhat abandoned MD.

Then I found Paper.js. A massive and far reaching framework that calls itself "The Swiss Army Knife of Vector Graphics Scripting.". I'd come across it years ago when first building RP, but went another direction as it seemed very animation oriented. I gave it another look before starting to build the drawing application for PC. Once I found it managed control points, path segments, and vectors in ways that can have math applied directly to them, I knew it was going to change everything.

In addition to a vast array of path object based abstractions for a professional level hierarchy of project > layer> path, full SVG import/export, and built in definition for creation of mouse tools, it has support for the following previously "impossible" operations:

• Filled path boolean operations like "union", "subtract" & "exclude"
• High accuracy clean path smoothing/simplification for "pencil" drawing input
• High quality efficient "flatten" conversion of any paths to polygons in milliseconds

Oh and it does awesome stuff with rasters too: http://paperjs.org/examples/spiral-raster/

(can you imagine that as a varied height painting mode?!? Awesome!)

So, what's my point? Where is this all getting to?

Near as I can tell in my cursory glances, almost every single tool, command, and setting available in MD is something that Paper.js can do basically "out of the box", or with some surprisingly small amount of tool logic support code. All the notably complicated SVG parsing, rendering, view zooming & object selection business could be (in theory) handled by this up to date and actively updated framework that prides itself on doing these things well and right. The application logic, tool/button interface and everything else could be handled in a relatively small and far easier to manage codebase.

I'm not saying that it's "easy" either. Some large parts of an implementation like this may be quite straightforward, but it's still going to take some real effort.

Great, so you've sold me on it. Now what?

Yea, I know. I've got no time these days, but I think this deserves some discussion. There might even be interest in either the Paper.js or Method-Draw communities.

• In the Paper community to have a nice looking example of their library as a drawing application.
• & in the MD community as a replacement of the somewhat funky SVGEdit back end, but in keeping to the simplification and clean user interface goals they originally set out with.

Though of course my immediate fear is that there's not enough MD community left to muster anything for this big of a schism, and that the Paper.js community, though over 10x bigger, is unlikely to embrace such a project as it does not resemble much of their current example set. Despite these possibilities, I will be posting issues looking for interested parties in the queues & message boards and linking back here where we should have the main discussion.

EDIT:
To aid in the discussion, the following is meant to be a guideline of required features, checked only when made "possible" by the library and/or custom code. For reference: Basic editor example sketch.

Method-Draw -> Paper.js required parity checklist (accomplished directly through framework API or trivial support code):

• SVG import/Export: Native, also supports JSON export
• Tools
  • Arrow select tool: see basic editor example for rotate, scale, etc.
  • Pencil draw tool: basically the example draw simplification tool
  • Single line: Path.add(event.point) API
  • Rectangle: new Path.Rectangle() API
  • Ellipse: new Path.Ellipse() API
  • Pen: Line draw with selection and curve handles shown
  • Shape Library: Import SVG API, custom placement code.
  • Zoom: Via project view zoom API
  • Eyedropper: Likely via direct canvas API, or color average, or path attribute
  • Color Picker: Probably would stay external library
• Layer order: Paper native path API
• Shape to path conversion: Not sure about this, though it's moot if we have flatten capability for non-path svg elements
• Text: This is a little iffy, but it seems like text is fully supported, don't know if we can render it to shapes though.
• Grid & Grid snapping: seems likely to be straightforward with object movement hooks or mouse tool move limits.
• Rulers: No native abilities for this, though it's likely could be ported directly knowing the view offsets.

Non RP specific support:

• Gradients: Yup
• Raster import: Native

[oskay]

Lots to think about here-- I need to try some hands-on tests.

Spiral paint is AMAZING.

[techninja]

I know, right?!

If you want to try something out, I'd recommend the current M2 build PC build (mac build). This is the culmination of the first two weeks of work creating a drawing interface (and GCode renderer) for the PancakeBot, and it's amazing how powerful the Paper.js API can be for making comprehensive and useful tools with relatively little code besides logic.

Edit:
Check the release notes on the M2 wrap issue for usage details

[techninja]

Cross linking additional discussion on the Paper.js group (I figured their issue queue was more about problems than discussions): https://groups.google.com/forum/#!topic/paperjs/4u5JHd3mpw8

[techninja]

I don't know why I didn't notice before: Apparently Paper.js was half-created for (BIG!) drawing robots through scriptographer!! See the co-creators bots here:

• Rita
• Hektor
• Viktor
• OTTO at the long now (Actually uses Paper.js directly)

This was brought up by the creator himself on the discussion board post above. He's been wanting to create an editor like this since the start back in 2001.

He even links to a now abandoned project to create an editor here: Stylii. I've tried it out and it's honestly not bad. Lots of attention paid to the pen tool (as would be expected), and the simple tools and pan are available, as well as copy/paste & undo! Beyond that, it's not quite there. My guess is that performance was an issue. Paper.js acts as a render and because of that, any benefits that browsers get from native rendering tricks/code for SVG are lost and would have to be rebuilt for big complex SVGs. It's certainly not impossible, there's just a bit more hill to climb.

[oskay]

I've been looking at paper.js here. It appears to be much the same as Processing in capabilities and style... And a long, long way from having the "easy to use" interface that MD currently has. It looks way powerful, but like a hell of a hill to climb.

[techninja]

Really, there is no "interface". But there are helpers that allow for writing such an interface relatively easily. I mean, I would basically be wiring the already existing interface HTMl & CSS into the paper.js tool API and wrap some logic around it. finding selected items, boundaries and other management is nearly automatic.

For some strange reason @docprofsky has volunteered to start work on a roadmap that would basically detail starting on reimplementing MD features from scratch one by one, starting with the zooming and view panning. Then likely the pen tool.

[oskay]

This is probably even more work than it sounds like...

[elbotho]

@techninja i agree with what you are saying. Unfortunately I don't have the skills to just do it myself, but am searching for people start working on it.
Short question: How did you end up with paper.js? Did you check out other libraries/frameworks?
I'm not sure about the use of <canvas>. What about http://svgjs.com/ for example?

Edit: I kind of withdraw my question after checking http://paperjs.org/features/ again.

[techninja]

@elpoto SVGJs could work, really what I'm looking for in a library are good abstractions for the very basics of object/path/node manipulation, bezier handles, popular/common implementation and documentation, not to mention path boolean and complex color handling (animation is pretty secondary for an editor). Some have said in other posts that Paper.JS can be inappropriate for such a task as its drawing inefficiencies vs native C code in browsers used to render complex SVGs "directly".

There is currently ZERO funding for this that I'm aware of, either in time or funds for developers, so at this point this is all good discussion, but doesn't mean much to get any development moving without finding someone with a bit of free time on their hands :)