push/popMatrix, push/popStyle, save/restore, push/popState?

[lmccart]

I just looked into matrix stuff and realized it's not really implemented.

Canvas supports save() and restore() which push and pop contexts onto a stack, which consist of the transformation matrix as well as style settings. There are methods for setting the transform of the canvas directly and transforming it in various ways, but there is no default way to access the transformation matrix, meaning it needs to be kept track of internally by hand if you want access.

http://html5.litten.com/understanding-save-and-restore-for-the-canvas-context/

A few options:

1. Keep track of the matrix internally. This means manually multiplying and setting all variables instead of relying on the canvas built in translate(), rotate(), transform() etc. This would slow performance and also leave considerable error for matrix manipulation errors.
2. Have push/popMatrix() backed by save()/restore(), and keep track of the styles to apply them after calling restore(), so that calling popMatrix() doesn't reset the style as well as the transform matrix. Probably faster than option 1, but not super elegant to pop off the style just to immediately manually place it back on again.
3. Replace push/popMatrix() and push/popStyle() with one function push/popState() or push/popContext(), that is effectively the save as save()/restore(), plus maybe a few other things (relating to imageMode, text stuff, etc). I'm in favor of this option as it's the cleanest, but I'd like to hear if there's strong objection from Processing natives.

**It also always felt a little non-intuitive to me that styles carry through from setup to draw and around the draw loop, but transforms do not (ie setup and draw are wrapped with push/popMatrix). I think my proposal would be that setup is wrapped with nothing (everything carries through, transforms and styles), and draw is wrapped with pushState so transforms do not accumulate and styles do not wraparound).

[shiffman]

I think 3 sounds like the way to go to. I think it's ok to break with Java Processing here in order to align with native canvas. The one question I would have, however, is if we ever get a webgl renderer going would that include a push and pop matrix for transformation only?

[REAS]

All changes the move away from matching Processing syntax worry me. But, logically, I like option 3 the best and changing the name makes sense because it's doing something different from push/popMatrix() and push/popStyles(). I don't feel good about "state" or "context" yet. Historically, push/popStyles() was added much later in the development of Processing. push/popMatrix() was there from the very beginning and was modeled after OpenGL.

[scotthmurray]

Thinking out loud here:

I'm imagining explaining option 3 in a classroom context. Already, push/popMatrix() are a bit confusing for beginners. Would it simplify or confuse matters to roll styles into the mix, in one grand, unified push/pop() pair of methods? I'm not sure. One one hand, yes, it's simpler (fewer commands to remember). On the other hand, does the grouping of matrix and styles make any logical sense to beginners? For someone new, are translations / rotations / scales peers to stroke / fill?

I'm also thinking to how I personally use push/pop. First, to be honest, I've never used push/popStyle() at all. When I use push/popMatrix(), it's often for tree-like structures of things — apply a transformation once, then from that point do several other transformations, then walk "back" down the tree and repeat, for example. Each time I step "back" down the tree, does it make sense for the styles to clear, as well as the positions?

I agree, of course, it sounds much simpler to implement by matching the native canvas behavior, but is canvas's way of thinking in line with the novice's way of thinking? If not, that's okay, but I'd like to be able to articulate why it's worth the added explanation or learning curve.

[REAS]

I think staying with the mental model of the canvas makes the most sense. Then if/when people want to work with the canvas directly, they can apply that model. The main/only reason we used push/popMatrix() as a mental model with Processing was to stick with the mental model used by OpenGL.

@lmccart Is there a reason to avoid push() and pop()?

[lmccart]

thanks for the thoughts everyone, I've removed push/popStyle and push/popMatrix, for push() and pop(). it could come back with webgl, but will leave it out for now.