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.
