API Review RT:17407 Canvas Node
james.graham at oracle.com
Wed Apr 25 01:03:34 PDT 2012
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...?
More information about the openjfx-dev