API Review RT:17407 Canvas Node

[Jim Graham]

Hi Daniel,

On 4/24/12 11:43 PM, Daniel Zwolenski wrote:
>> This sounds like a vote for a "resizeable damage-oriented surface" node and, in your case, no vote for the existing "retained painting" variant we've spec'd.
>
> Actually I prefer the retained painting option. I quite like the idea of being able to grab the graphics context and update it.
>
> It's just that I'd almost always want to put it in a layout manager. Can I vote for option C, a retained painted canvas that when resized just adds white space and it's up to the developer to listen to bounds changes and redraw if needed?
>
> Failing that I think I'd still prefer your original suggestion and I'll just shave it into a sphere as needed.

Interesting, yes I can see there is an intersection of the two.  But, 
some use cases would not be suitable for retaining - like scrolling a 
really large area.  For that you'd really want a constantly repainted 
view like Swing and AWT scrollable panels have been as it would be a 
memory waste to store all of the pixels for the non-visible parts.

This reminds me that we should probably have a size limit on Canvas. 
While we could support a software canvas as large as the heap, most 
devices have limits on the size of a renderable surface and I'm not sure 
if developers would be happy if we suddenly backed off to software 
rendering if they have a choice of accepting a smaller size.

Hmmm...  More variants of Canvas or more attributes to set...?

			...jim