API Review RT:17407 Canvas Node
zonski at googlemail.com
Tue Apr 24 23:43:26 PDT 2012
> 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.
More information about the openjfx-dev