API Review RT:17407 Canvas Node

[Daniel Zwolenski]

Don't we have the 'callback' already in the form of the width and height properties? The ChangeListener will tell us how much it grew by. 

I would have liked resizable imageView. I did the bounds listener trick on ImageView in my last project to make a video stream capture window (using lti-civil to capture video to image and rapidly update the Image content) that resized so the user could make it bigger. The user could take a photo with it. 


On 26/04/2012, at 6:00 AM, Richard Bair <richard.bair at oracle.com> wrote:

> Why can't we just provide a callback? It is called whenever the canvas is resized (smaller or larger) and we could provide the rectangle of the area that needs to be drawn in the case of it getting larger. It doesn't mean we have to switch modes, it seems to me like we could just call back the developer (if the callback isn't null) and then they can do something or not. Either way we retain the pixels that were previously drawn unless they tell us otherwise.
> 
> That is separate from the question of whether Canvas should be resizable. Personally I kind of like the idea of a resizable Canvas, but that could be a separate node (we had this same debate around ImageView. I wanted it to be resizable, but we didn't make it resizable because we thought we could add a resizable one later if we wanted to). I still would have liked ImageView to be resizable and have a setResizable property which would be false by default. Probably do the same thing here would be my preference.
> 
> Richard
> 
> On Apr 24, 2012, at 5:51 PM, Jim Graham wrote:
> 
>> After reading through the many responses it sounds like there is a desire for a damage-repair-responding callback-focused Node.
>> 
>> I wonder if that is instead of the current design or in addition to? I'll ask formally below.
>> 
>> Given the current design where you instantiate a Canvas with "new Canvas()" and then get a GC using "cv.getGC()", there is little call for an interface for GC.  You could create an alternate "GC", but there is no part of that chain where you could insert your GC to redirect the output.  This is not like awt.Canvas.paint(Graphics) in that you can construct any Graphics instance you want and hand it to that method and capture what it will render.
>> 
>> But, if we later (or instead?) add such a callback-centric repainting node then it would make more sense to allow alternate implementation of GC.  If/when we make that move then we can always turn the current GC into an abstract class.  We could do an interface now in anticipation of that eventuality, but you end up with the GC2, GC3 issue that Kevin already mentioned when you want to evolve it and can't add new methods to existing interfaces without breaking binary compatibility with 3rd party implementations.
>> 
>> So, what would developers find most useful?
>> 
>> - painter's canvas (what we have now, no callbacks, retained rendering)
>> - damage repair surface (ala awt.Canvas.paint(g) etc.)
>> - both
>> 
>>            ...jim
>> 
>> On 4/18/12 11:57 PM, Dr. Michael Paus wrote:
>>> A Canvas node is very important but we should not limit the
>>> GraphicsContext to be only usable for it.
>>> Instead we should make GraphicsContext an interface and Canvas should
>>> then provide a CanvasGraphicsContext
>>> which implements this interface. The advantage would be that code can be
>>> written against that interface and
>>> if someone else writes a renderer for other output formats you can then
>>> immediately render into that format
>>> too like it is currently done for SVG, PDF and other formats by tools
>>> like Batik, iText, etc.
>>> 
>>> LG, Michael
>