API Review RT:17407 Canvas Node

Kevin Rushforth kevin.rushforth at oracle.com
Mon Apr 23 15:11:35 PDT 2012


I wrote:
 
> 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.

-- Kevin


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.
>
>             ...jim
>
> 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
>>>> notifications.
>>>
>>> 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 mailing list