That's a nice solution - though in real world code I worry that the endDrawing
snapshotting would be triggered more often than necessary.
I still think there is no compelling reason for Canvas to be a Node, and there
is a significant drawback if you want to reuse the same Canvas many times in
I think a graphics context on a writable image would make more sense.
In any case, Canvas is a Node and will remain one forever.
Steve
On 2014-04-22 6:15 PM, Jeff Martin wrote:
I have a case where I need to draw to a canvas and reuse it in multiple nodes.
My non-optimal work-around is to
I understand that Canvas has to remain a node - but I think the basic problem
could be fixed in a very backward compatible way:
A future release could simply add a CanvasImage class which had a
GraphicsContext - then Canvas could remain, but simply embed a CanvasImage.
Though for practical
How would you (easily) use it in the scenegraph if it wasn't a Node?
-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
Jeff Martin
Sent: Wednesday, April 23, 2014 8:16 AM
To: openjfx-dev@openjdk.java.net Mailing
Subject: Should Canvas have
Just by using it as an ImageView.Image.
jeff
On Apr 22, 2014, at 5:43 PM, John C. Turnbull ozem...@ozemail.com.au wrote:
How would you (easily) use it in the scenegraph if it wasn't a Node?
-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
It would be great if you could get a Graphics context for drawing into a
WritableImage instead of having to deal with snapshots. But I suppose you
could build something like that based on Canvas that would update an image.
Scott
On Apr 22, 2014 6:52 PM, Jeff Martin j...@reportmill.com wrote:
