API Review RT:17407 Canvas Node

[Daniel Zwolenski]

> It's a lot harder than adding it to a container that does layout and wondering why your drawing disappears.  You tend to notice a call to "cv.setWidth()" or "cv.widthProperty().bind()" in your own code.  

On a similar line of reasoning, I'd argue that you tend to notice a BorderLayout.setCenter(canvas) in your own code. 

> Many apps will add scrollbars if you resize them rather than have the "game" dynamically change its dimensions.  

Scroll pane contained view is a good one for fixed size. Fair call. 

> This is in contrast to your claim that you can't come up with a single use case.  I don't think it's that dramatically unpopular.

Sorry, it wasn't intended to be dramatic or a claim. Genuinely meant it as a question: ie I can't think of a use case, tell me yours. 

The challenges of email conversations :)

> This sounds like a vote for a "resizeable damage-oriented surface" node and, in your case, no vote for the existing "retained painting" variant we've spec'd.

Actually I prefer the retained painting option. I quite like the idea of being able to grab the graphics context and update it. 

It's just that I'd almost always want to put it in a layout manager. Can I vote for option C, a retained painted canvas that when resized just adds white space and it's up to the developer to listen to bounds changes and redraw if needed?

Failing that I think I'd still prefer your original suggestion and I'll just shave it into a sphere as needed.