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.
