API Review RT:17407 Canvas Node
zonski at googlemail.com
Tue Apr 24 07:52:49 PDT 2012
> On the resizing issue, it seems more sensible to leave resizing behavior up
> to the developer. Simply, does a resize infer scaling the canvas or
> clipping it or expanding it with white space? Those are all design choices
> best left up to the developer.
Agreed that the redrawing should be up to the developer but not so sure about resizing, ie actually adjusting the bounds. The layout managers already do the resizing math, I'd personally like to be able to leverage that and not have to create non-intuitive parent containers with bound size listeners just to get my canvas to work as 'normal' when in a pane.
Regardless of layout support though, I think there needs to be a default drawing behavior for resize? If I call setSize on the canvas it will create more (or less) area, what does this area look like by default if the developer does nothing? Or are you saying the developer should be forced to do the repaint via some hook that must be implemented (similar to Swings paint() method)?
> Regardless of how the implementation discussion ends up, the driving
> question should be what do developers expect a 2D Canvas to do? I think of
> things like photoshop, Illustrator, 8 bit arcade games, animations, 2D CAD
> apps, Flow chart designers and the like.
I would have used this in my last project to create:
- a PDF viewer with ability to draw markup/scribble on it
- a highly graphical custom component that looked like a 'clipboard' (actually a 'permit board' hanging from a wall)
- a 'flingable' carousel of the above components that the user can horizontally flip through (touch screen)
- a scrollable site map showing a schematic of an industrial site
- annotated images (ie markup/scribble on photos taken)
- simple CAD diagram rendering
Most of these things _could_ be built using 'Nodes' in a Group but a canvas feels more natural and straight forward (eg mouse detection on a map). This could be because it's what I'm used to in Swing but either way I would have used Canvas if I had it.
> When I Google to see what people have done with the Canvas node I'm not
> overly impressed, but perhaps that's because of the early nature of the
> HTML canvas element.
> On Mon, Apr 23, 2012 at 4:27 PM, Daniel Zwolenski <zonski at googlemail.com>wrote:
>> Sorry, I'm not following the problem.
>> Wouldn't the height and width properties provide the callback to say 'I
>> have been resized'? This would include the amount resized-by so the
>> developer could just render the new area if they want (or redraw the whole
>> scene, etc). If the developer chooses not to patch/repaint then that's
>> their choice.
>> HTML has never had good layout manager concepts so for me it is not the
>> best benchmark in this topic.
>> What's the requirement to repaint on every frame? I don't follow that.
>> On 24/04/2012, at 6:11 AM, Kevin Rushforth <kevin.rushforth at oracle.com>
>>> 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.
>>>> 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