API Review RT:17407 Canvas Node

Jim Graham james.graham at oracle.com
Wed Apr 25 17:03:24 PDT 2012

First, someone else already pointed out that listeners on the size 
properties can be used for this callback, but I wanted to also point out 
that if we did provide a callback with the current "just render and it 
will be retained" we'd have to be careful not to confuse developers 
familiar with awt.Canvas and swing.Panel as they may then believe that 
this will be called on every repaint and/or they should only render in 
the callback.  That's not the base model here.

Given the potential for confusion about the model, and given that there 
are already notifications of size changes, I don't think a 
painting-specific callback makes sense for the current design.

Also, I think ImageView is actually a very close model to what Canvas 
was designed to be.  Image/ImageView are a static image that you load 
from a file or URL, though potentially it could be an animated GIF 
and/or you could swap out the underlying Image in the View.  Canvas is a 
persistent image that you create with rendering commands and can then be 
static for its lifetime or you can change it at will by rerendering...


On 4/25/12 1:00 PM, Richard Bair 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

More information about the openjfx-dev mailing list