API Review RT:17407 Canvas Node

[Daniel Zwolenski]

Getting on a plane so just a quick, half-thought idea:

What if we had a renderer interface that was independent of Canvas. 

Eg. Renderer.render(GraphicsContext g) 

Then we could set this on Canvas, or call it for saving to an image, printing, etc. 

Not sure... Just a random thought. 





On 25/04/2012, at 8:51 AM, Jim Graham <james.graham at oracle.com> 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