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 <m...@jugs.org> 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 <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 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<
kevin.rushfo...@oracle.com>  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<
kevin.rushfo...@oracle.com>  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<
kevin.rushfo...@oracle.com>  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.