API Review RT:17407 Canvas Node

[Jim Graham]

On 4/24/12 5:48 PM, Daniel Zwolenski wrote:
> It's still totally possible to resize it though, either through direct calls or by binding the height/width to its container. Don't we then have all the problems you mention whether it's easy or hard, frequent or infrequent to change the bounds? The only way to avoid that would be to make size readonly and pass the dimensions to the constructor.

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.  By 
contrast, if you are manageable and you change the type of your parent 
(for reasons other than wanting to be resized (if you want to be a 
static picture in a managed scene for example) then suddenly you become 
resizeable by a 3rd party and there are no apparent calls to any 
size-related property methods in your own code.

> On desktops, with resizable windows, and different shape displays, I cant come up with a single use case where I'd not want my Canvas to grow with its window? Maybe a full screen game but since jfx allows the user to exit full screen at whim the ui would need to support resizing anyway. Anyone got any good use cases where they don't want to resize?

Even a non-fs game typically is a given size and does not resize.  I 
don't want more or fewer rows in my Tetris play space depending on how 
big the window is, for instance.  Many apps will add scrollbars if you 
resize them rather than have the "game" dynamically change its 
dimensions.  I'm not saying that nobody will resize, but I can easily 
see lots of examples of apps that don't want the primary rendering 
canvas to dynamically resize.  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.

> If Canvas is not resizable then the first thing I will do with it is create a custom ResizableCanvas component that extends BorderPane and has a Canvas in it with its bounds bound to the BorderPane. Now it's resizable. Just seems like an unnecessary step, and I'll still be faced with all the issues you mention. I'd rather we had solutions/best-practices for this straight off the shelf.

Canvas is not "a resizeable canvas that is broken and we forgot to add a 
way for it to participate in layouts".  Canvas is a "fixed size drawing 
that remembers what is on it".  If the first thing you would do to a 
block is shave off its corners so it is a sphere then it is questionable 
that the block should change its nature.  You can shave it down as a 
workaround, but really it would be more productive if someone would 
start supplying spheres for your needs.  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.

			...jim