API Review RT:17407 Canvas Node
kevin.rushforth at oracle.com
Mon Apr 23 15:11:35 PDT 2012
> I can't think of any reason it should not be resizable.
Good think I'm not the only one thinking about it, then. :)
Yes, this would be an issue. So unless/until we are ready to deal with
this, my earlier suggestion of binding to the width/height property, and
adding your own listeners is probably the way to go.
Jim Graham wrote:
> We would have to deal with damage repair. Right now it is a
> persistent rendering, not an area to be "repainted" on every frame.
> If we wanted it to be dynamically and asynchronously resizable we
> would have to switch to (or provide?) a call-back model of rendering
> and you would have to keep enough state to be able to render it again
> on every frame. HTML5 Canvas demos are not rendered that way, though
> they can be at their own will - they simply clear the entire canvas
> and re-render on every pulse. Or, they just render the new stuff.
> Their call. If they change size, like you can with Canvas, then they
> are responsible for changing the size and rendering the new stuff -
> just like if you manually modify the size of our Canvas.
> On 4/23/12 5:36 AM, Kevin Rushforth wrote:
>> If Canvas were a "Resizable" node then yes, it could do that. Off-hand,
>> I can't think of any reason it should not be resizable.
>> -- Kevin
>> Daniel Zwolenski wrote:
>>>> A Canvas node is a fixed size, so it only resizes when you tell it
>>>> to. If you want it to track the size of the Scene (or similar), you
>>>> could bind its width and height properties and react to change
>>> Any reason why Canvas wouldn't just adhere to the Layout algorithm of
>>> the Container it is in? Eg if in a BorderPane center then fill, if in
>>> a GridPane take up that cell, etc. If we want to fix size then we
>>> would use min/max constraints.
>>> That would seem the most sensible and useful thing to me.
More information about the openjfx-dev