Re: com.sun.javafx vs javafx (with example/request)

[jfx user2]

Turns out that I partially misunderstood the use of Path2D in
GraphicsContext.  I had been using appendSVGPath for nearly everything and
within a single beginPath/closePath.  Under those circumstances
 converting GraphicsContext.path from Path2D to Path (using code from
Shape.createFromGeomShape(Path2D p)) gives you a relatively simple path
that can be used as a simplified version of what is rendered in the
Canvas.  It can be used as a very "degraded" version of what was placed in
the canvas and is way faster than other solutions.

However, it would only apply to the last beginPath/closePath and it does
not include any of the other path methods in GraphicsContext.  Path IS used
by those methods but is empty after a call to e.g. fillRect.  That's
unfortunate... If path did retain everything, I'd continue to push for a
"getPath" method on GraphicsContext.  I'll have to stick with my current
implementations.

As for the performance of Canvas vs. the Scene, I'm also speaking from
experience.  But I'm referring to highly dynamic applications.  If you have
an app with lots of objects (and lots dynamic behavior such as motion of
all types, animation, and color) Canvas will be many times more performant
than the Scene graph.  I think Gerrit Grunwald's TileFX is a good example
(more complex usage of Canvas than most but still not even close to the
level of dynamic behavior that I'm referring to).

On Fri, May 8, 2020 at 7:13 PM Michael Paus  wrote:

> I think I know quite a bit about JavaFX graphics and I do not generally
> agree with your statements.
> Especially the statement that the Canvas is so much superior is a myth
> from the old days of Java 8
> where there were a few performance bugs in the scene graph handling. But
> that's a long time ago.
> (I even gave a workshop on this at the JavaLand conference some time ago.)
> Maybe you could present
> a few more details about your use-case and not so much about the technique
> that you think is the
> best fit for it. Maybe even some demo code somewhere. I am always
> interested in a discussion about
> graphics as long as it is supported by facts. Neither the scene graph nor
> the canvas is a silver bullet.
> It always depends on your use-case.
> Michael
>
> Am 09.05.20 um 00:18 schrieb jfx user2:
>
> From the JavaDoc "Canvas is an image that can be drawn on using a set of
> graphics commands provided by a GraphicsContext."  This a bit of a
> misnomer.  While canvas can be used to draw in image (actually
> GraphicsContext not canvas itself), the image based methods of
> GraphicsContext are far outweighed by the "vector" or path based methods.
> The GraphicsContext gives you the ability to freely create dynamic graphics
> without the constraints of the Scene Graph.  It can be highly performant
> and scalable if done properly.  The Scene Graph will not perform like the
> GraphicsContext.  If you haven't worked with highly dynamic graphics, you
> might not have encountered any issues.  The Scene Graph works ok up to a
> certain number of objects and it is not good at adding and removing objects
> often.  GraphicsContext does not have the same restrictions.  It can
> involve more work but the end result will scale far beyond what you can do
> in a Scene Graph... I think this is already widely accepted.
>
> The proposed method on the GraphicsContext simply returns what is already
> there.  It would convert the already stored Path2D to a Path.  Why reinvent
> what is already present and only private?  This in turn CAN be used in the
> Scene Graph but it can also be used as a container to draw back onto the
> GraphicsContext.  You see,  a Path that is calculated once and then used
> repeatedly to draw in the GraphicsContext (possibly even transformed) is
> better than sub-optimally calculating that Path on every pass through the
> GraphicsContext or storing it as an image or Shape (those were some of my
> workarounds).
>
> Anyway, I'm requesting that a private API be used to create a new public
> method.  This is really no different than existing public methods that use
> private APIs.  I'm not asking to expose private APIs (not in this request
> :o).  There isn't even much code.  It's reusing what's already there.
>
> Ask Gerrit Grunwald about his experience with the Scene Graph vs
> Canvas/GraphicsContext.
>
>
> On Fri, May 8, 2020 at 4:27 PM Michael Paus  wrote:
>
>> Hi,
>> I have to say that your requirements sound a little bit strange to me,
>> but maybe you can make it clearer what your real use-case behind them is.
>> What I do not understand is why you are using the canvas at all.
>> Conceptually the canvas is for direct mode rendering into an image. The
>> fact that
>> this is handled a little bit different internally is an implementation
>> detail, you should not rely on. Why don't you use the scene graph which
>> seems
>> to provide many of the aspects that you need? I admit that there are a
>> few hidden gems internally that I would also like to be made 

Re: com.sun.javafx vs javafx (with example/request)

[Michael Paus]

I think I know quite a bit about JavaFX graphics and I do not generally 
agree with your statements.
Especially the statement that the Canvas is so much superior is a myth 
from the old days of Java 8
where there were a few performance bugs in the scene graph handling. But 
that's a long time ago.
(I even gave a workshop on this at the JavaLand conference some time 
ago.) Maybe you could present
a few more details about your use-case and not so much about the 
technique that you think is the
best fit for it. Maybe even some demo code somewhere. I am always 
interested in a discussion about
graphics as long as it is supported by facts. Neither the scene graph 
nor the canvas is a silver bullet.

It always depends on your use-case.
Michael

Am 09.05.20 um 00:18 schrieb jfx user2:
From the JavaDoc "Canvas is an image that can be drawn on using a set 
of graphics commands provided by a GraphicsContext."  This a bit of a 
misnomer.  While canvas can be used to draw in image (actually 
GraphicsContext not canvas itself), the image based methods of 
GraphicsContext are far outweighed by the "vector" or path based 
methods.  The GraphicsContext gives you the ability to freely create 
dynamic graphics without the constraints of the Scene Graph.  It can 
be highly performant and scalable if done properly.  The Scene Graph 
will not perform like the GraphicsContext.  If you haven't worked with 
highly dynamic graphics, you might not have encountered any issues.  
The Scene Graph works ok up to a certain number of objects and it is 
not good at adding and removing objects often.  GraphicsContext does 
not have the same restrictions.  It can involve more work but the end 
result will scale far beyond what you can do in a Scene Graph... I 
think this is already widely accepted.


The proposed method on the GraphicsContext simply returns what is 
already there.  It would convert the already stored Path2D to a Path.  
Why reinvent what is already present and only private? This in turn 
CAN be used in the Scene Graph but it can also be used as a container 
to draw back onto the GraphicsContext.  You see,  a Path that is 
calculated once and then used repeatedly to draw in the 
GraphicsContext (possibly even transformed) is better than 
sub-optimally calculating that Path on every pass through the 
GraphicsContext or storing it as an image or Shape (those were some of 
my workarounds).


Anyway, I'm requesting that a private API be used to create a new 
public method.  This is really no different than existing public 
methods that use private APIs.  I'm not asking to expose private APIs 
(not in this request :o).  There isn't even much code.  It's reusing 
what's already there.


Ask Gerrit Grunwald about his experience with the Scene Graph vs 
Canvas/GraphicsContext.



On Fri, May 8, 2020 at 4:27 PM Michael Paus > wrote:


Hi,
I have to say that your requirements sound a little bit strange to
me,
but maybe you can make it clearer what your real use-case behind
them is.
What I do not understand is why you are using the canvas at all.
Conceptually the canvas is for direct mode rendering into an
image. The
fact that
this is handled a little bit different internally is an
implementation
detail, you should not rely on. Why don't you use the scene graph
which
seems
to provide many of the aspects that you need? I admit that there
are a
few hidden gems internally that I would also like to be made public
(e.g. the flattening path iterator) but I definitely see these things
more in the scene graph context but not for Canvas.
Just my two €ent.
Michael

Am 08.05.20 um 22:08 schrieb jfx user2:
> No... given a Shape, create a Path that represents the outline
of that shape.  If I had a Path I wouldn’t be requesting the new
methods.
>
> One of the workarounds for getting a Path from a GraphicsContext
is to keep track of it as I’m drawing... however, this is overhead
in the gc call that can become very expensive when you have a lot
of gcs or if your gc is doing a lot of work.  The path is already
there in Path2D along with a method to convert it to a public
Path.  There’s no need for an expensive custom workaround.  All
that’s required is a method on the GraphicsContext that returns a
Path.  The same is true for getting a Path from a Shape.
>
> Please note that this behavior is desirable for highly optimized
use of GraphicsContext and Shapes where you need “outlines” of
things in vector format.  The private api is unnecessarily hiding
this information.
>
>> On May 8, 2020, at 3:38 PM, Philip Race mailto:philip.r...@oracle.com>> wrote:
>>
>> The current path is defined by the application - you - and yet
you don't know what it is  ?
>> You do say
>>> I have other workarounds where I have to maintain a path as
I’m drawing in the 

Re: com.sun.javafx vs javafx (with example/request)

[Kevin Rushforth]

I can see the value in a Shape.toPath() method (or alternatively  a 
Path.of(Shape) method). I'm still not sold on the value proposition of a 
similar method to GraphicsContext (and "just make this internal 
information public" isn't a recipe for adding new API).


You can file an Enhancement request or two if you want. They aren't 
likely to be high on our list to look at. If you are willing to put in 
the effort to define and implement the feature yourself including: 
getting consensus that it is worth adding as a supported public API, 
specifying the API, implementing it (this is the one step where the fact 
that there is existing implementation is even relevant), writing 
automated tests for it, etc., then that might be a way forward. In that 
case, I refer you to the CONTRIBUTING [1] guidelines for the project.


-- Kevin

[1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md


On 5/8/2020 3:18 PM, jfx user2 wrote:

 From the JavaDoc "Canvas is an image that can be drawn on using a set of
graphics commands provided by a GraphicsContext."  This a bit of a
misnomer.  While canvas can be used to draw in image (actually
GraphicsContext not canvas itself), the image based methods of
GraphicsContext are far outweighed by the "vector" or path based methods.
The GraphicsContext gives you the ability to freely create dynamic graphics
without the constraints of the Scene Graph.  It can be highly performant
and scalable if done properly.  The Scene Graph will not perform like the
GraphicsContext.  If you haven't worked with highly dynamic graphics, you
might not have encountered any issues.  The Scene Graph works ok up to a
certain number of objects and it is not good at adding and removing objects
often.  GraphicsContext does not have the same restrictions.  It can
involve more work but the end result will scale far beyond what you can do
in a Scene Graph... I think this is already widely accepted.

The proposed method on the GraphicsContext simply returns what is already
there.  It would convert the already stored Path2D to a Path.  Why reinvent
what is already present and only private?  This in turn CAN be used in the
Scene Graph but it can also be used as a container to draw back onto the
GraphicsContext.  You see,  a Path that is calculated once and then used
repeatedly to draw in the GraphicsContext (possibly even transformed) is
better than sub-optimally calculating that Path on every pass through the
GraphicsContext or storing it as an image or Shape (those were some of my
workarounds).

Anyway, I'm requesting that a private API be used to create a new public
method.  This is really no different than existing public methods that use
private APIs.  I'm not asking to expose private APIs (not in this request
:o).  There isn't even much code.  It's reusing what's already there.

Ask Gerrit Grunwald about his experience with the Scene Graph vs
Canvas/GraphicsContext.


On Fri, May 8, 2020 at 4:27 PM Michael Paus  wrote:


Hi,
I have to say that your requirements sound a little bit strange to me,
but maybe you can make it clearer what your real use-case behind them is.
What I do not understand is why you are using the canvas at all.
Conceptually the canvas is for direct mode rendering into an image. The
fact that
this is handled a little bit different internally is an implementation
detail, you should not rely on. Why don't you use the scene graph which
seems
to provide many of the aspects that you need? I admit that there are a
few hidden gems internally that I would also like to be made public
(e.g. the flattening path iterator) but I definitely see these things
more in the scene graph context but not for Canvas.
Just my two €ent.
Michael

Am 08.05.20 um 22:08 schrieb jfx user2:

No... given a Shape, create a Path that represents the outline of that

shape.  If I had a Path I wouldn’t be requesting the new methods.

One of the workarounds for getting a Path from a GraphicsContext is to

keep track of it as I’m drawing... however, this is overhead in the gc call
that can become very expensive when you have a lot of gcs or if your gc is
doing a lot of work.  The path is already there in Path2D along with a
method to convert it to a public Path.  There’s no need for an expensive
custom workaround.  All that’s required is a method on the GraphicsContext
that returns a Path.  The same is true for getting a Path from a Shape.

Please note that this behavior is desirable for highly optimized use of

GraphicsContext and Shapes where you need “outlines” of things in vector
format.  The private api is unnecessarily hiding this information.

On May 8, 2020, at 3:38 PM, Philip Race  wrote:

The current path is defined by the application - you - and yet you

don't know what it is  ?

You do say

I have other workarounds where I have to maintain a path as I’m

drawing in the canvas

Why can't you do that ? No internal API digging.

-phil


On 5/8/20, 12:02 PM, jfx user2 wrote:
Ok, then please consider the 

Re: com.sun.javafx vs javafx (with example/request)

[jfx user2]

>From the JavaDoc "Canvas is an image that can be drawn on using a set of
graphics commands provided by a GraphicsContext."  This a bit of a
misnomer.  While canvas can be used to draw in image (actually
GraphicsContext not canvas itself), the image based methods of
GraphicsContext are far outweighed by the "vector" or path based methods.
The GraphicsContext gives you the ability to freely create dynamic graphics
without the constraints of the Scene Graph.  It can be highly performant
and scalable if done properly.  The Scene Graph will not perform like the
GraphicsContext.  If you haven't worked with highly dynamic graphics, you
might not have encountered any issues.  The Scene Graph works ok up to a
certain number of objects and it is not good at adding and removing objects
often.  GraphicsContext does not have the same restrictions.  It can
involve more work but the end result will scale far beyond what you can do
in a Scene Graph... I think this is already widely accepted.

The proposed method on the GraphicsContext simply returns what is already
there.  It would convert the already stored Path2D to a Path.  Why reinvent
what is already present and only private?  This in turn CAN be used in the
Scene Graph but it can also be used as a container to draw back onto the
GraphicsContext.  You see,  a Path that is calculated once and then used
repeatedly to draw in the GraphicsContext (possibly even transformed) is
better than sub-optimally calculating that Path on every pass through the
GraphicsContext or storing it as an image or Shape (those were some of my
workarounds).

Anyway, I'm requesting that a private API be used to create a new public
method.  This is really no different than existing public methods that use
private APIs.  I'm not asking to expose private APIs (not in this request
:o).  There isn't even much code.  It's reusing what's already there.

Ask Gerrit Grunwald about his experience with the Scene Graph vs
Canvas/GraphicsContext.


On Fri, May 8, 2020 at 4:27 PM Michael Paus  wrote:

> Hi,
> I have to say that your requirements sound a little bit strange to me,
> but maybe you can make it clearer what your real use-case behind them is.
> What I do not understand is why you are using the canvas at all.
> Conceptually the canvas is for direct mode rendering into an image. The
> fact that
> this is handled a little bit different internally is an implementation
> detail, you should not rely on. Why don't you use the scene graph which
> seems
> to provide many of the aspects that you need? I admit that there are a
> few hidden gems internally that I would also like to be made public
> (e.g. the flattening path iterator) but I definitely see these things
> more in the scene graph context but not for Canvas.
> Just my two €ent.
> Michael
>
> Am 08.05.20 um 22:08 schrieb jfx user2:
> > No... given a Shape, create a Path that represents the outline of that
> shape.  If I had a Path I wouldn’t be requesting the new methods.
> >
> > One of the workarounds for getting a Path from a GraphicsContext is to
> keep track of it as I’m drawing... however, this is overhead in the gc call
> that can become very expensive when you have a lot of gcs or if your gc is
> doing a lot of work.  The path is already there in Path2D along with a
> method to convert it to a public Path.  There’s no need for an expensive
> custom workaround.  All that’s required is a method on the GraphicsContext
> that returns a Path.  The same is true for getting a Path from a Shape.
> >
> > Please note that this behavior is desirable for highly optimized use of
> GraphicsContext and Shapes where you need “outlines” of things in vector
> format.  The private api is unnecessarily hiding this information.
> >
> >> On May 8, 2020, at 3:38 PM, Philip Race  wrote:
> >>
> >> The current path is defined by the application - you - and yet you
> don't know what it is  ?
> >> You do say
> >>> I have other workarounds where I have to maintain a path as I’m
> drawing in the canvas
> >> Why can't you do that ? No internal API digging.
> >>
> >> -phil
> >>
> >>> On 5/8/20, 12:02 PM, jfx user2 wrote:
> >>> Ok, then please consider the GraphicsContext request that I’ve made.
> It simply enables you to get the Path from the context without exposing com
> classes at all.  I have other workarounds where I have to maintain a path
> as I’m drawing in the canvas or I have to do hit testing on a non vector
> image to determine the path but these are way more expensive than simply
> creating a Path object from the Path2D that is already in the
> GraphicContext.  That path can be used in drag and drop scenarios, fast
> secondary rendering under heavy gc use, edge tracing, and the list goes on.
> >>>
> >>> The same is true for the Shape class.  I’d like to request that the
> following be added to Shape:
> >>> public Path getPath() {
> >>>  return Shape.createFromGeomShape(getTransformedArea());
> >>> }
> >>>
> >>> That’s it.  The underlying methods are 

Re: com.sun.javafx vs javafx (with example/request)

[Michael Paus]

Hi,
I have to say that your requirements sound a little bit strange to me, 
but maybe you can make it clearer what your real use-case behind them is.
What I do not understand is why you are using the canvas at all. 
Conceptually the canvas is for direct mode rendering into an image. The 
fact that
this is handled a little bit different internally is an implementation 
detail, you should not rely on. Why don't you use the scene graph which 
seems
to provide many of the aspects that you need? I admit that there are a 
few hidden gems internally that I would also like to be made public 
(e.g. the flattening path iterator) but I definitely see these things 
more in the scene graph context but not for Canvas.

Just my two €ent.
Michael

Am 08.05.20 um 22:08 schrieb jfx user2:

No... given a Shape, create a Path that represents the outline of that shape.  
If I had a Path I wouldn’t be requesting the new methods.

One of the workarounds for getting a Path from a GraphicsContext is to keep 
track of it as I’m drawing... however, this is overhead in the gc call that can 
become very expensive when you have a lot of gcs or if your gc is doing a lot 
of work.  The path is already there in Path2D along with a method to convert it 
to a public Path.  There’s no need for an expensive custom workaround.  All 
that’s required is a method on the GraphicsContext that returns a Path.  The 
same is true for getting a Path from a Shape.

Please note that this behavior is desirable for highly optimized use of 
GraphicsContext and Shapes where you need “outlines” of things in vector 
format.  The private api is unnecessarily hiding this information.


On May 8, 2020, at 3:38 PM, Philip Race  wrote:

The current path is defined by the application - you - and yet you don't know 
what it is  ?
You do say

I have other workarounds where I have to maintain a path as I’m drawing in the 
canvas

Why can't you do that ? No internal API digging.

-phil


On 5/8/20, 12:02 PM, jfx user2 wrote:
Ok, then please consider the GraphicsContext request that I’ve made.  It simply 
enables you to get the Path from the context without exposing com classes at 
all.  I have other workarounds where I have to maintain a path as I’m drawing 
in the canvas or I have to do hit testing on a non vector image to determine 
the path but these are way more expensive than simply creating a Path object 
from the Path2D that is already in the GraphicContext.  That path can be used 
in drag and drop scenarios, fast secondary rendering under heavy gc use, edge 
tracing, and the list goes on.

The same is true for the Shape class.  I’d like to request that the following 
be added to Shape:
public Path getPath() {
 return Shape.createFromGeomShape(getTransformedArea());
}

That’s it.  The underlying methods are there but the public api doesn’t expose 
them.  This gives you a vector outline of the Shape as Path.l on demand, not 
stored.

There are expensive workarounds for performing these tasks and I spent a long 
time trying... until I discovers the private apis already had the capability 
but simply did. It expose it.

I’d these are not supported, I’ll have to stick with reflection,  bytebuddy, or 
forking - non of which will be easily maintained or portable.

Ps I will post additional concerns over time.  The next one likely has to do 
with the mismatch between javafx canvas (gc) and other canvases such as svg, 
html2.  I think there is private api that would help in this case.


On May 8, 2020, at 2:41 PM, Kevin Rushforth  wrote:

Since Canvas is an immediate mode graphics API, I presume you are interested 
in the most recent drawing primitive? (we don't keep the composite shape for 
all drawing primitives -- that would be both too expensive and not really 
appropriate). How would you expect current rendering attributes (e.g., 
transforms) to affect the results? These are all questions that need to be 
addressed.

As for the bigger picture, we intentionally have a separate render graph with 
"peers" for each node, although some of the duplication of classes is 
historical (we used to have a looser decoupling before Prism became the only backend). 
Unless there is a compelling need, we are unlikely to consider changing this in the 
general case, but perhaps could look at specific cases if it made sense. This is a 
separate issue, though, from public API and the two shouldn't be conflated.

Btw, JavaFX has been fully open-sourced since 2013, although the design of 
Prism predates that.

-- Kevin



On 5/8/2020 10:43 AM, jfx user2 wrote:
Kevin, go easy please :0).  There is a need.

Access to the outline of the path in the canvas is great for edge following, 
node attachment points, animating around the non-rectangular border of what’s 
actually displayed, etc.

The other request that I haven’t posted yet is to do the same for Shape.   I’ve 
tested both of these enhancements and it works as desired.  I’ll post the 
second request soon.

But back to the 

Re: com.sun.javafx vs javafx (with example/request)

[jfx user2]

No... given a Shape, create a Path that represents the outline of that shape.  
If I had a Path I wouldn’t be requesting the new methods.

One of the workarounds for getting a Path from a GraphicsContext is to keep 
track of it as I’m drawing... however, this is overhead in the gc call that can 
become very expensive when you have a lot of gcs or if your gc is doing a lot 
of work.  The path is already there in Path2D along with a method to convert it 
to a public Path.  There’s no need for an expensive custom workaround.  All 
that’s required is a method on the GraphicsContext that returns a Path.  The 
same is true for getting a Path from a Shape.

Please note that this behavior is desirable for highly optimized use of 
GraphicsContext and Shapes where you need “outlines” of things in vector 
format.  The private api is unnecessarily hiding this information.

> On May 8, 2020, at 3:38 PM, Philip Race  wrote:
> 
> The current path is defined by the application - you - and yet you don't 
> know what it is  ?
> You do say
> > I have other workarounds where I have to maintain a path as I’m drawing in 
> > the canvas
> 
> Why can't you do that ? No internal API digging.
> 
> -phil
> 
>> On 5/8/20, 12:02 PM, jfx user2 wrote:
>> Ok, then please consider the GraphicsContext request that I’ve made.  It 
>> simply enables you to get the Path from the context without exposing com 
>> classes at all.  I have other workarounds where I have to maintain a path as 
>> I’m drawing in the canvas or I have to do hit testing on a non vector image 
>> to determine the path but these are way more expensive than simply creating 
>> a Path object from the Path2D that is already in the GraphicContext.  That 
>> path can be used in drag and drop scenarios, fast secondary rendering under 
>> heavy gc use, edge tracing, and the list goes on.
>> 
>> The same is true for the Shape class.  I’d like to request that the 
>> following be added to Shape:
>> public Path getPath() {
>> return Shape.createFromGeomShape(getTransformedArea());
>> }
>> 
>> That’s it.  The underlying methods are there but the public api doesn’t 
>> expose them.  This gives you a vector outline of the Shape as Path.l on 
>> demand, not stored.
>> 
>> There are expensive workarounds for performing these tasks and I spent a 
>> long time trying... until I discovers the private apis already had the 
>> capability but simply did. It expose it.
>> 
>> I’d these are not supported, I’ll have to stick with reflection,  bytebuddy, 
>> or forking - non of which will be easily maintained or portable.
>> 
>> Ps I will post additional concerns over time.  The next one likely has to do 
>> with the mismatch between javafx canvas (gc) and other canvases such as svg, 
>> html2.  I think there is private api that would help in this case.
>> 
 On May 8, 2020, at 2:41 PM, Kevin Rushforth  
 wrote:
>>> 
>>> Since Canvas is an immediate mode graphics API, I presume you are 
>>> interested in the most recent drawing primitive? (we don't keep the 
>>> composite shape for all drawing primitives -- that would be both too 
>>> expensive and not really appropriate). How would you expect current 
>>> rendering attributes (e.g., transforms) to affect the results? These are 
>>> all questions that need to be addressed.
>>> 
>>> As for the bigger picture, we intentionally have a separate render graph 
>>> with "peers" for each node, although some of the duplication of classes is 
>>> historical (we used to have a looser decoupling before Prism became the 
>>> only backend). Unless there is a compelling need, we are unlikely to 
>>> consider changing this in the general case, but perhaps could look at 
>>> specific cases if it made sense. This is a separate issue, though, from 
>>> public API and the two shouldn't be conflated.
>>> 
>>> Btw, JavaFX has been fully open-sourced since 2013, although the design of 
>>> Prism predates that.
>>> 
>>> -- Kevin
>>> 
>>> 
 On 5/8/2020 10:43 AM, jfx user2 wrote:
 Kevin, go easy please :0).  There is a need.
 
 Access to the outline of the path in the canvas is great for edge 
 following, node attachment points, animating around the non-rectangular 
 border of what’s actually displayed, etc.
 
 The other request that I haven’t posted yet is to do the same for Shape.   
 I’ve tested both of these enhancements and it works as desired.  I’ll post 
 the second request soon.
 
 But back to the bigger picture.  The requests that I’m making are only 
 additions to return a path from javafx not com.  But there are other cases 
 where geometry and convenience methods in com would be beneficial to the 
 public api.  It also seems odd that there are two layers to begin with...  
 parallel apis often result in too much object creation or cpu overhead 
 translating between them.  I’ll be more specific about these cases over 
 time.   Part of my intention is to spark a discussion 

Re: com.sun.javafx vs javafx (with example/request)

[Kevin Rushforth]

The performance tracker was identified back in the JDK 9 time frame as a 
possible candidate for a public API. The following request is tracking it:


https://bugs.openjdk.java.net/browse/JDK-8145154

If someone wants to spend the effort to take this feature request and 
drive it to completion, including discussing the feature, proposing a 
public API (which is not "just make the existing impl class public"), 
filing a CSR, implementing it (you can very likely leverage the existing 
internal implementation), testing it, and getting it reviewed, then that 
would be possible.


-- Kevin


On 5/8/2020 12:11 PM, Ty Young wrote:
On the topic of private APIs that should probably be public... can the 
performance tracker class be made public too? I'd very much like to 
know the FPS at which my application is running at.

Re: com.sun.javafx vs javafx (with example/request)

[Philip Race]

The current path is defined by the application - you - and yet you don't 
know what it is  ?

You do say
> I have other workarounds where I have to maintain a path as I’m 
drawing in the canvas


Why can't you do that ? No internal API digging.

-phil

On 5/8/20, 12:02 PM, jfx user2 wrote:

Ok, then please consider the GraphicsContext request that I’ve made.  It simply 
enables you to get the Path from the context without exposing com classes at 
all.  I have other workarounds where I have to maintain a path as I’m drawing 
in the canvas or I have to do hit testing on a non vector image to determine 
the path but these are way more expensive than simply creating a Path object 
from the Path2D that is already in the GraphicContext.  That path can be used 
in drag and drop scenarios, fast secondary rendering under heavy gc use, edge 
tracing, and the list goes on.

The same is true for the Shape class.  I’d like to request that the following 
be added to Shape:
public Path getPath() {
 return Shape.createFromGeomShape(getTransformedArea());
}

That’s it.  The underlying methods are there but the public api doesn’t expose 
them.  This gives you a vector outline of the Shape as Path.l on demand, not 
stored.

There are expensive workarounds for performing these tasks and I spent a long 
time trying... until I discovers the private apis already had the capability 
but simply did. It expose it.

I’d these are not supported, I’ll have to stick with reflection,  bytebuddy, or 
forking - non of which will be easily maintained or portable.

Ps I will post additional concerns over time.  The next one likely has to do 
with the mismatch between javafx canvas (gc) and other canvases such as svg, 
html2.  I think there is private api that would help in this case.


On May 8, 2020, at 2:41 PM, Kevin Rushforth  wrote:

Since Canvas is an immediate mode graphics API, I presume you are interested 
in the most recent drawing primitive? (we don't keep the composite shape for 
all drawing primitives -- that would be both too expensive and not really 
appropriate). How would you expect current rendering attributes (e.g., 
transforms) to affect the results? These are all questions that need to be 
addressed.

As for the bigger picture, we intentionally have a separate render graph with 
"peers" for each node, although some of the duplication of classes is 
historical (we used to have a looser decoupling before Prism became the only backend). 
Unless there is a compelling need, we are unlikely to consider changing this in the 
general case, but perhaps could look at specific cases if it made sense. This is a 
separate issue, though, from public API and the two shouldn't be conflated.

Btw, JavaFX has been fully open-sourced since 2013, although the design of 
Prism predates that.

-- Kevin



On 5/8/2020 10:43 AM, jfx user2 wrote:
Kevin, go easy please :0).  There is a need.

Access to the outline of the path in the canvas is great for edge following, 
node attachment points, animating around the non-rectangular border of what’s 
actually displayed, etc.

The other request that I haven’t posted yet is to do the same for Shape.   I’ve 
tested both of these enhancements and it works as desired.  I’ll post the 
second request soon.

But back to the bigger picture.  The requests that I’m making are only 
additions to return a path from javafx not com.  But there are other cases 
where geometry and convenience methods in com would be beneficial to the public 
api.  It also seems odd that there are two layers to begin with...  parallel 
apis often result in too much object creation or cpu overhead translating 
between them.  I’ll be more specific about these cases over time.   Part of my 
intention is to spark a discussion about the design since previously this was 
relatively closed source.


On May 8, 2020, at 1:12 PM, Kevin Rushforth  wrote:

While there is no plan to "open up" more of com.sun.javafx (and that isn't 
really the right way to look at it), if you have a proposed enhancement to the existing 
public javafx.* classes we could discuss it.

As for your specific example, can you say more about what your use case is? The 
GraphicsContext object is a drawing context for a Canvas node, so it is not a natural 
place to put an API that computes or returns a path. I get the sense that you are looking 
at the existing internal implementation classes and saying "how can I get access to 
some information that might be useful to my application" rather than describing what 
your application is trying to do. Once we understand what you are trying to do, we can 
discuss whether the need is general enough to propose adding to the public API of JavaFX 
and what form such a new API might take.

-- Kevin



On 5/8/2020 9:35 AM, jfx user2 wrote:
I am aware of this and that’s why I am asking.  There are useful private 
features in com.sun.javafx and I explained one of them in my message.  I have 
an additional related example but the 

Re: com.sun.javafx vs javafx (with example/request)

[Ty Young]

On the topic of private APIs that should probably be public... can the 
performance tracker class be made public too? I'd very much like to know 
the FPS at which my application is running at.

Re: com.sun.javafx vs javafx (with example/request)

[jfx user2]

Ok, then please consider the GraphicsContext request that I’ve made.  It simply 
enables you to get the Path from the context without exposing com classes at 
all.  I have other workarounds where I have to maintain a path as I’m drawing 
in the canvas or I have to do hit testing on a non vector image to determine 
the path but these are way more expensive than simply creating a Path object 
from the Path2D that is already in the GraphicContext.  That path can be used 
in drag and drop scenarios, fast secondary rendering under heavy gc use, edge 
tracing, and the list goes on.

The same is true for the Shape class.  I’d like to request that the following 
be added to Shape:
public Path getPath() {
return Shape.createFromGeomShape(getTransformedArea());
}

That’s it.  The underlying methods are there but the public api doesn’t expose 
them.  This gives you a vector outline of the Shape as Path.l on demand, not 
stored.

There are expensive workarounds for performing these tasks and I spent a long 
time trying... until I discovers the private apis already had the capability 
but simply did. It expose it.

I’d these are not supported, I’ll have to stick with reflection,  bytebuddy, or 
forking - non of which will be easily maintained or portable.

Ps I will post additional concerns over time.  The next one likely has to do 
with the mismatch between javafx canvas (gc) and other canvases such as svg, 
html2.  I think there is private api that would help in this case.

> On May 8, 2020, at 2:41 PM, Kevin Rushforth  
> wrote:
> 
> Since Canvas is an immediate mode graphics API, I presume you are interested 
> in the most recent drawing primitive? (we don't keep the composite shape for 
> all drawing primitives -- that would be both too expensive and not really 
> appropriate). How would you expect current rendering attributes (e.g., 
> transforms) to affect the results? These are all questions that need to be 
> addressed.
> 
> As for the bigger picture, we intentionally have a separate render graph with 
> "peers" for each node, although some of the duplication of classes is 
> historical (we used to have a looser decoupling before Prism became the only 
> backend). Unless there is a compelling need, we are unlikely to consider 
> changing this in the general case, but perhaps could look at specific cases 
> if it made sense. This is a separate issue, though, from public API and the 
> two shouldn't be conflated.
> 
> Btw, JavaFX has been fully open-sourced since 2013, although the design of 
> Prism predates that.
> 
> -- Kevin
> 
> 
>> On 5/8/2020 10:43 AM, jfx user2 wrote:
>> Kevin, go easy please :0).  There is a need.
>> 
>> Access to the outline of the path in the canvas is great for edge following, 
>> node attachment points, animating around the non-rectangular border of 
>> what’s actually displayed, etc.
>> 
>> The other request that I haven’t posted yet is to do the same for Shape.   
>> I’ve tested both of these enhancements and it works as desired.  I’ll post 
>> the second request soon.
>> 
>> But back to the bigger picture.  The requests that I’m making are only 
>> additions to return a path from javafx not com.  But there are other cases 
>> where geometry and convenience methods in com would be beneficial to the 
>> public api.  It also seems odd that there are two layers to begin with...  
>> parallel apis often result in too much object creation or cpu overhead 
>> translating between them.  I’ll be more specific about these cases over 
>> time.   Part of my intention is to spark a discussion about the design since 
>> previously this was relatively closed source.
>> 
 On May 8, 2020, at 1:12 PM, Kevin Rushforth  
 wrote:
>>> 
>>> While there is no plan to "open up" more of com.sun.javafx (and that isn't 
>>> really the right way to look at it), if you have a proposed enhancement to 
>>> the existing public javafx.* classes we could discuss it.
>>> 
>>> As for your specific example, can you say more about what your use case is? 
>>> The GraphicsContext object is a drawing context for a Canvas node, so it is 
>>> not a natural place to put an API that computes or returns a path. I get 
>>> the sense that you are looking at the existing internal implementation 
>>> classes and saying "how can I get access to some information that might be 
>>> useful to my application" rather than describing what your application is 
>>> trying to do. Once we understand what you are trying to do, we can discuss 
>>> whether the need is general enough to propose adding to the public API of 
>>> JavaFX and what form such a new API might take.
>>> 
>>> -- Kevin
>>> 
>>> 
 On 5/8/2020 9:35 AM, jfx user2 wrote:
 I am aware of this and that’s why I am asking.  There are useful private 
 features in com.sun.javafx and I explained one of them in my message.  I 
 have an additional related example but the larger question is if there is 
 a plan to open more of com.sun.javafx to the 

Re: com.sun.javafx vs javafx (with example/request)

[Kevin Rushforth]

Since Canvas is an immediate mode graphics API, I presume you are 
interested in the most recent drawing primitive? (we don't keep the 
composite shape for all drawing primitives -- that would be both too 
expensive and not really appropriate). How would you expect current 
rendering attributes (e.g., transforms) to affect the results? These are 
all questions that need to be addressed.


As for the bigger picture, we intentionally have a separate render graph 
with "peers" for each node, although some of the duplication of classes 
is historical (we used to have a looser decoupling before Prism became 
the only backend). Unless there is a compelling need, we are unlikely to 
consider changing this in the general case, but perhaps could look at 
specific cases if it made sense. This is a separate issue, though, from 
public API and the two shouldn't be conflated.


Btw, JavaFX has been fully open-sourced since 2013, although the design 
of Prism predates that.


-- Kevin


On 5/8/2020 10:43 AM, jfx user2 wrote:

Kevin, go easy please :0).  There is a need.

Access to the outline of the path in the canvas is great for edge following, 
node attachment points, animating around the non-rectangular border of what’s 
actually displayed, etc.

The other request that I haven’t posted yet is to do the same for Shape.   I’ve 
tested both of these enhancements and it works as desired.  I’ll post the 
second request soon.

But back to the bigger picture.  The requests that I’m making are only 
additions to return a path from javafx not com.  But there are other cases 
where geometry and convenience methods in com would be beneficial to the public 
api.  It also seems odd that there are two layers to begin with...  parallel 
apis often result in too much object creation or cpu overhead translating 
between them.  I’ll be more specific about these cases over time.   Part of my 
intention is to spark a discussion about the design since previously this was 
relatively closed source.


On May 8, 2020, at 1:12 PM, Kevin Rushforth  wrote:

While there is no plan to "open up" more of com.sun.javafx (and that isn't 
really the right way to look at it), if you have a proposed enhancement to the existing 
public javafx.* classes we could discuss it.

As for your specific example, can you say more about what your use case is? The 
GraphicsContext object is a drawing context for a Canvas node, so it is not a natural 
place to put an API that computes or returns a path. I get the sense that you are looking 
at the existing internal implementation classes and saying "how can I get access to 
some information that might be useful to my application" rather than describing what 
your application is trying to do. Once we understand what you are trying to do, we can 
discuss whether the need is general enough to propose adding to the public API of JavaFX 
and what form such a new API might take.

-- Kevin



On 5/8/2020 9:35 AM, jfx user2 wrote:
I am aware of this and that’s why I am asking.  There are useful private 
features in com.sun.javafx and I explained one of them in my message.  I have 
an additional related example but the larger question is if there is a plan to 
open more of com.sun.javafx to the public api, documentation surrounding this, 
or possibly a complete replacement?

Please consider the example I provided as a feature request.


On May 8, 2020, at 9:39 AM, Kevin Rushforth  wrote:

Only javafx.* packages are part of the public API. Anything else, including 
com.sun.javafx.*, is internal implementation details that an application should 
never call.

-- Kevin



On 5/8/2020 12:38 AM, jfx user2 wrote:
Is there documentation around the packages (com.sun.javafx vs javafx) used
in JavaFX?

For example, why is there a com.sun.javafx.geom that isn't fully mirrored
in the javafx.scene.shape package?  Why are there missing features from
Graphics2D?

I have a specific example that prompted the question:

Consider the following classes:

javafx.scene.shape.Shape
 private static Path
createFromGeomShape(com.sunjavafx.geom.Shape geomShape)

javafx.scene.canvas.GraphicsContext
 Path2D path;

I want to write a line as follows:
Path path = Path.createFromGeomShape(gc.path);
b/c I want to inexpensively get the outline of the GraphicsContext.

However:
We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
by the module.
We can't access Path.createFromGeomShape b/c it's private.
We can't access path in GraphicsContext b/c it's default and doesn't have
an accessor.

A possible solution is to add a new method:
javafx.scene.canvas.GraphicsContext
public Path getPath() {
 //implementation copied from
javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
}

That would solve my immediate problem but raises the question... why is
com.sun.javafx hidden?  What's the architectural reason?  Is there any work
in progress that will impact this design?

PS my example is actually very important. 

Re: com.sun.javafx vs javafx (with example/request)

[jfx user2]

Kevin, go easy please :0).  There is a need.

Access to the outline of the path in the canvas is great for edge following, 
node attachment points, animating around the non-rectangular border of what’s 
actually displayed, etc.

The other request that I haven’t posted yet is to do the same for Shape.   I’ve 
tested both of these enhancements and it works as desired.  I’ll post the 
second request soon.

But back to the bigger picture.  The requests that I’m making are only 
additions to return a path from javafx not com.  But there are other cases 
where geometry and convenience methods in com would be beneficial to the public 
api.  It also seems odd that there are two layers to begin with...  parallel 
apis often result in too much object creation or cpu overhead translating 
between them.  I’ll be more specific about these cases over time.   Part of my 
intention is to spark a discussion about the design since previously this was 
relatively closed source.

> On May 8, 2020, at 1:12 PM, Kevin Rushforth  
> wrote:
> 
> While there is no plan to "open up" more of com.sun.javafx (and that isn't 
> really the right way to look at it), if you have a proposed enhancement to 
> the existing public javafx.* classes we could discuss it.
> 
> As for your specific example, can you say more about what your use case is? 
> The GraphicsContext object is a drawing context for a Canvas node, so it is 
> not a natural place to put an API that computes or returns a path. I get the 
> sense that you are looking at the existing internal implementation classes 
> and saying "how can I get access to some information that might be useful to 
> my application" rather than describing what your application is trying to do. 
> Once we understand what you are trying to do, we can discuss whether the need 
> is general enough to propose adding to the public API of JavaFX and what form 
> such a new API might take.
> 
> -- Kevin
> 
> 
>> On 5/8/2020 9:35 AM, jfx user2 wrote:
>> I am aware of this and that’s why I am asking.  There are useful private 
>> features in com.sun.javafx and I explained one of them in my message.  I 
>> have an additional related example but the larger question is if there is a 
>> plan to open more of com.sun.javafx to the public api, documentation 
>> surrounding this, or possibly a complete replacement?
>> 
>> Please consider the example I provided as a feature request.
>> 
 On May 8, 2020, at 9:39 AM, Kevin Rushforth  
 wrote:
>>> 
>>> Only javafx.* packages are part of the public API. Anything else, 
>>> including com.sun.javafx.*, is internal implementation details that an 
>>> application should never call.
>>> 
>>> -- Kevin
>>> 
>>> 
 On 5/8/2020 12:38 AM, jfx user2 wrote:
 Is there documentation around the packages (com.sun.javafx vs javafx) used
 in JavaFX?
 
 For example, why is there a com.sun.javafx.geom that isn't fully mirrored
 in the javafx.scene.shape package?  Why are there missing features from
 Graphics2D?
 
 I have a specific example that prompted the question:
 
 Consider the following classes:
 
 javafx.scene.shape.Shape
 private static Path
 createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
 
 javafx.scene.canvas.GraphicsContext
 Path2D path;
 
 I want to write a line as follows:
 Path path = Path.createFromGeomShape(gc.path);
 b/c I want to inexpensively get the outline of the GraphicsContext.
 
 However:
 We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
 by the module.
 We can't access Path.createFromGeomShape b/c it's private.
 We can't access path in GraphicsContext b/c it's default and doesn't have
 an accessor.
 
 A possible solution is to add a new method:
 javafx.scene.canvas.GraphicsContext
 public Path getPath() {
 //implementation copied from
 javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
 }
 
 That would solve my immediate problem but raises the question... why is
 com.sun.javafx hidden?  What's the architectural reason?  Is there any work
 in progress that will impact this design?
 
 PS my example is actually very important.  I currently use reflection and
 module opens in the build to get the path but if the getPath method could
 be added to GraphicsContext, that would be great.  For performance, it
 would be even better to get the PathIterator directly instead of
 translating into a javafx..Path but that is related to the bigger question.
> 

Re: com.sun.javafx vs javafx (with example/request)

[Kevin Rushforth]

While there is no plan to "open up" more of com.sun.javafx (and that 
isn't really the right way to look at it), if you have a proposed 
enhancement to the existing public javafx.* classes we could discuss it.


As for your specific example, can you say more about what your use case 
is? The GraphicsContext object is a drawing context for a Canvas node, 
so it is not a natural place to put an API that computes or returns a 
path. I get the sense that you are looking at the existing internal 
implementation classes and saying "how can I get access to some 
information that might be useful to my application" rather than 
describing what your application is trying to do. Once we understand 
what you are trying to do, we can discuss whether the need is general 
enough to propose adding to the public API of JavaFX and what form such 
a new API might take.


-- Kevin


On 5/8/2020 9:35 AM, jfx user2 wrote:

I am aware of this and that’s why I am asking.  There are useful private 
features in com.sun.javafx and I explained one of them in my message.  I have 
an additional related example but the larger question is if there is a plan to 
open more of com.sun.javafx to the public api, documentation surrounding this, 
or possibly a complete replacement?

Please consider the example I provided as a feature request.


On May 8, 2020, at 9:39 AM, Kevin Rushforth  wrote:

Only javafx.* packages are part of the public API. Anything else, including 
com.sun.javafx.*, is internal implementation details that an application should 
never call.

-- Kevin



On 5/8/2020 12:38 AM, jfx user2 wrote:
Is there documentation around the packages (com.sun.javafx vs javafx) used
in JavaFX?

For example, why is there a com.sun.javafx.geom that isn't fully mirrored
in the javafx.scene.shape package?  Why are there missing features from
Graphics2D?

I have a specific example that prompted the question:

Consider the following classes:

javafx.scene.shape.Shape
 private static Path
createFromGeomShape(com.sunjavafx.geom.Shape geomShape)

javafx.scene.canvas.GraphicsContext
 Path2D path;

I want to write a line as follows:
Path path = Path.createFromGeomShape(gc.path);
b/c I want to inexpensively get the outline of the GraphicsContext.

However:
We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
by the module.
We can't access Path.createFromGeomShape b/c it's private.
We can't access path in GraphicsContext b/c it's default and doesn't have
an accessor.

A possible solution is to add a new method:
javafx.scene.canvas.GraphicsContext
public Path getPath() {
 //implementation copied from
javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
}

That would solve my immediate problem but raises the question... why is
com.sun.javafx hidden?  What's the architectural reason?  Is there any work
in progress that will impact this design?

PS my example is actually very important.  I currently use reflection and
module opens in the build to get the path but if the getPath method could
be added to GraphicsContext, that would be great.  For performance, it
would be even better to get the PathIterator directly instead of
translating into a javafx..Path but that is related to the bigger question.

Re: com.sun.javafx vs javafx (with example/request)

[jfx user2]

I am aware of this and that’s why I am asking.  There are useful private 
features in com.sun.javafx and I explained one of them in my message.  I have 
an additional related example but the larger question is if there is a plan to 
open more of com.sun.javafx to the public api, documentation surrounding this, 
or possibly a complete replacement?

Please consider the example I provided as a feature request.

> On May 8, 2020, at 9:39 AM, Kevin Rushforth  
> wrote:
> 
> Only javafx.* packages are part of the public API. Anything else, including 
> com.sun.javafx.*, is internal implementation details that an application 
> should never call.
> 
> -- Kevin
> 
> 
>> On 5/8/2020 12:38 AM, jfx user2 wrote:
>> Is there documentation around the packages (com.sun.javafx vs javafx) used
>> in JavaFX?
>> 
>> For example, why is there a com.sun.javafx.geom that isn't fully mirrored
>> in the javafx.scene.shape package?  Why are there missing features from
>> Graphics2D?
>> 
>> I have a specific example that prompted the question:
>> 
>> Consider the following classes:
>> 
>> javafx.scene.shape.Shape
>> private static Path
>> createFromGeomShape(com.sunjavafx.geom.Shape geomShape)
>> 
>> javafx.scene.canvas.GraphicsContext
>> Path2D path;
>> 
>> I want to write a line as follows:
>> Path path = Path.createFromGeomShape(gc.path);
>> b/c I want to inexpensively get the outline of the GraphicsContext.
>> 
>> However:
>> We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
>> by the module.
>> We can't access Path.createFromGeomShape b/c it's private.
>> We can't access path in GraphicsContext b/c it's default and doesn't have
>> an accessor.
>> 
>> A possible solution is to add a new method:
>> javafx.scene.canvas.GraphicsContext
>> public Path getPath() {
>> //implementation copied from
>> javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
>> }
>> 
>> That would solve my immediate problem but raises the question... why is
>> com.sun.javafx hidden?  What's the architectural reason?  Is there any work
>> in progress that will impact this design?
>> 
>> PS my example is actually very important.  I currently use reflection and
>> module opens in the build to get the path but if the getPath method could
>> be added to GraphicsContext, that would be great.  For performance, it
>> would be even better to get the PathIterator directly instead of
>> translating into a javafx..Path but that is related to the bigger question.
> 

Re: com.sun.javafx vs javafx (with example/request)

[Kevin Rushforth]

Only javafx.* packages are part of the public API. Anything else, 
including com.sun.javafx.*, is internal implementation details that an 
application should never call.


-- Kevin


On 5/8/2020 12:38 AM, jfx user2 wrote:

Is there documentation around the packages (com.sun.javafx vs javafx) used
in JavaFX?

For example, why is there a com.sun.javafx.geom that isn't fully mirrored
in the javafx.scene.shape package?  Why are there missing features from
Graphics2D?

I have a specific example that prompted the question:

Consider the following classes:

javafx.scene.shape.Shape
 private static Path
createFromGeomShape(com.sunjavafx.geom.Shape geomShape)

javafx.scene.canvas.GraphicsContext
 Path2D path;

I want to write a line as follows:
Path path = Path.createFromGeomShape(gc.path);
b/c I want to inexpensively get the outline of the GraphicsContext.

However:
We can't access Path2D b/c it's in com.sun.javafx.geom which isn't exported
by the module.
We can't access Path.createFromGeomShape b/c it's private.
We can't access path in GraphicsContext b/c it's default and doesn't have
an accessor.

A possible solution is to add a new method:
javafx.scene.canvas.GraphicsContext
public Path getPath() {
 //implementation copied from
javafx.scene.shape.Shape.createFromGeomShape but use gc.path as the path
}

That would solve my immediate problem but raises the question... why is
com.sun.javafx hidden?  What's the architectural reason?  Is there any work
in progress that will impact this design?

PS my example is actually very important.  I currently use reflection and
module opens in the build to get the path but if the getPath method could
be added to GraphicsContext, that would be great.  For performance, it
would be even better to get the PathIterator directly instead of
translating into a javafx..Path but that is related to the bigger question.