API Review RT:17407 Canvas Node

[Jim Graham]

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