Re: [External] : Re: Convenience factories for Border and Background

[Bruce Johnson]

I very much like the idea of a simpler way to create Borders and Backgrounds, 
but once you get beyond the original proposal of Border.stroke(Paint stroke), 
it  seems like a case where a fluent interface would be useful. The 
alternatives of multiple argument constructors just start getting back into 
more complexity and debates about who needs what combination of options 
supported.
 

So if one wanted a simple border:

Border.stroke(Color.RED)

but if you want to set width and styles you could do something like:

   Border.stroke(Color.RED).width(3).dotted();

—Bruce

> On Jun 9, 2021, at 7:59 AM, John Hendrikx  wrote:
> 
> I'm not entirely convinced taking width is all that useful. The (final) pxiel 
> width of a border is normally a calculated value based on the chosen unit and 
> scaling needs of the platform.
> 
> A lot of methods in JavaFX work with pixel values only, while for proper 
> scaling I often find myself needing a different unit, in which case CSS is 
> the only option.
> 
> Perhaps however this is a different issue, as it would apply to much more 
> than just borders.
> 
> --John
> 
> On 08/06/2021 17:29, Scott Palmer wrote:
>> +1 for having a variant that takes a width. Colour, width, and radius are 
>> the main parameters I need, so a variant that takes all three would help:
>> 
>> Border.stroke(Paint p, double width, double radii)
>> 
>> (Though to be honest for my larger projects most of the time this stuff is 
>> set in a style sheet.  It’s smaller tools and utilities that I find this 
>> particularly tedious as the verbosity of the code becomes annoying.)
>> 
>> Scott
>> 
>>> On Jun 8, 2021, at 9:59 AM, Kevin Rushforth  
>>> wrote:
>>> 
>>> I think that the convenience methods should just cover the most common 
>>> cases, so I'd rather skip the dotted and dashed variants. It is a good 
>>> question as to whether there ought to be a variant that takes width. I 
>>> wouldn't do that as the only method, though. I'd lean towards not taking 
>>> the width. Once you start getting into more parameters you can just use the 
>>> constructors without much more trouble.
>>> 
>>> As for the names, I have a slight preference for Border.stroke and 
>>> Background.fill.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> On 6/8/2021 4:25 AM, Nir Lisker wrote:
 Are dashed and dotted used frequently? I find that I only use solid unless 
 I'm doing something fancy.
 
 On Tue, Jun 8, 2021 at 5:21 AM Michael Strauß >>> > wrote:
 
   What do you think about this variation?
 
   Border.solid(Paint color, double width) ->
   new Border(new BorderStroke(color, BorderStrokeStyle.SOLID,
   null, new BorderWidths(width)))
 
   Border.dashed(Paint color, double width)  ->
   new Border(new BorderStroke(color, BorderStrokeStyle.DASHED,
   null, new BorderWidths(width)))
 
   Border.dotted(Paint color, double width) ->
   new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED,
   null, new BorderWidths(width)))
 
   Background.fill(Paint color) ->
   new BackgroundFill(color, null, null)
 
   This gives developers a good deal of customizability before needing to
   fall back to using constructors.
 
 
   Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker
   mailto:nlis...@gmail.com>>:
   >
   > The new API:
   >
   > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)`
   that does
   > `new Border(new BorderStroke(Paint stroke ,
   BorderStrokeStyle.SOLID, null,
   > null));`
   > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)`
   that does
   > `new Background(new BackgroundFill(Paint fill, null, null));`
   >
   > I don't mind either name choice.
   >
 
>>> 
>> 

Re: Integrated: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina

[Bruce Johnson]

> On Dec 7, 2020, at 10:33 AM, Kevin Rushforth  wrote:
> 
> On Wed, 2 Dec 2020 20:00:55 GMT, Kevin Rushforth  wrote:
> 
>> This is a proposed fix for the bug where the Apple system menubar is 
>> initially non-responsive on macOS 10.15 and later after a JavaFX application 
>> has started up. The end user can workaround this by switching to some other 
>> application and then back to the JavaFX app, but there is no known 
>> workaround that the application developer can use.
>> 
>> JavaFX is using a non-standard approach to creating the system menus, and 
>> seems likely that some change in macOS 10.15 means that this no longer works 
>> the same as in previous versions of macOS. We have had problems with 
>> application startup on macOS in the past that affected the system menubar: 
>> see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and 
>> [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743).
>> 
>> The solution is to deactivate and then reactivate the application after the 
>> app has initially been made active, but before any window is initialized and 
>> before the system menu is populated.
>> 
>> I pushed this as two commits: one with the fix and one with some temporary 
>> verbose debug print statements. I will remove the print statements prior to 
>> the formal review, but wanted to leave them in for now in case someone 
>> wanted to test them, and ran into an issue (the debug print statements could 
>> help isolate any problems).
>> 
>> I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need 
>> additional testing.
>> 
>> The only drawback I see with this approach is that there can be a very brief 
>> flash when launching the JavaFX app from a  terminal window as the FX 
>> application activates, deactivates, and reactivates.
> 
> This pull request has now been integrated.
> 
> Changeset: e7dbdfcb
> Author:Kevin Rushforth 
> URL:   https://git.openjdk.java.net/jfx/commit/e7dbdfcb
> Stats: 109 lines in 4 files changed: 94 ins; 0 del; 15 mod
> 
> 8233678: [macos 10.15] System menu bar does not work initially on macOS 
> Catalina
> 
> Reviewed-by: jvos, aghaisas
> 
> -
> 
> PR: https://git.openjdk.java.net/jfx/pull/361


It would be useful, at least to me, to see a brief comment in this email thread 
about why this approach (which results in the application flashing) is 
necessary.  Why does JavaFX require this approach, or is there an alternative, 
but more complex approach that could ultimately be used in later releases.  I’d 
just like to be able to look back in the email thread when I (or the users of 
my software) see the flash to understand why it's there.

Bruce

Re: GraphicsContext and export to vector format files

[Bruce Johnson]

But standardization of the interface is they key.  I can imagine one group 
writing a really useful charting library that just took a 
GraphicsContextInterface and used it to render to the canvas.  Someone else 
could independently develop something like JFreeSVG that took a 
GraphicsContextInterface and drew to .svg files.  A third group could simply 
plug the two together and get nice plots displayed on the Canvas or written to 
a .svg file without even starting up the GUI.

Instead I’ve got my basic plotting code (for rendering NMR spectra) and my own 
SVG exporter that only knows how to export the methods that I use in the 
plotting.  Those two don’t lead to a whole ecosystem of tools that leads to 
great applications.

Bruce




> On Nov 2, 2020, at 6:07 PM, Kevin Rushforth  
> wrote:
> 
> I can see how this could be useful to a certain class of applications, but 
> I'm not convinced there is enough value, since the work that the application 
> would need to do is pretty much the same even if we added the ability to 
> subclass. As for providing an interface, I think that a third-party library 
> could do that just as easily. What you wouldn't get is standardization of 
> that interface.
> 
> -- Kevin
> 
> 
> On 11/2/2020 2:34 PM, Bruce Johnson wrote:
>> I should not even have mentioned the GraphicsContext for scene graph 
>> rendering.  There is something elegant about being able to easily make the 
>> whole scene render to some other device/file, but I’m well aware of the 
>> practical issues.
>> 
>> But I do wish there was a better solution for the original question.  
>> Libraries like VectorGraphics and JFreeSVG are really useful for actual real 
>> world applications and I don’t see comparable tools appearing for JavaFX 
>> without some changes like I propose (or better ones than I can think of).
>> 
>> Bruce
>> 
>> 
>> 
>>> On Nov 2, 2020, at 5:04 PM, Kevin Rushforth  
>>> wrote:
>>> 
>>> Yeah, there is no chance we would consider changing the JavaFX to use 
>>> Canvas GraphicsContext for scene graph rendering.
>>> 
>>> As for the original question, we are unlikely to make GraphicsContext 
>>> extensible in the core JavaFX. I think the solution you came up with for 
>>> your application (with a proxy class and interface) is a reasonable 
>>> approach.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> On 11/2/2020 6:58 AM, Michael Paus wrote:
>>>> At this point I would disagree with you. Doing so would just
>>>> result in a sever performance hit. I will not go into the details
>>>> here because that idea is out of reach anyway.
>>>> 
>>>> Am 02.11.20 um 15:42 schrieb Bruce Johnson:
>>>>> And if you want to think of even further advances (which I’d avoid at 
>>>>> this point because I’d like this to get done in a useful time frame), 
>>>>> I’ve often thought that all JavaFX scene drawing should use the Canvas 
>>>>> GraphicsContext.  So with the changes I’m suggesting that would allow 
>>>>> export of the complete scene graph to another device (vector graphics 
>>>>> files etc.)
>>>>> 
>>>>> Bruce
>>>>> 
>>>>> 
>>>>>> On Nov 2, 2020, at 9:17 AM, Michael Paus  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> I very much like the idea in general but I think it falls too short.
>>>>>> Such an interface should not be tied to any existing graphics
>>>>>> framework. Instead it should be just pure Java. This would allow
>>>>>> to write complex graphics rendering code for a lot of different
>>>>>> platforms and not only platforms where JavaFX already exists
>>>>>> and can be used. Just think of the Android canvas or, via cross-
>>>>>> compilation, even the HTML 5 canvas.
>>>>>> Just my two €ent.
>>>>>> Michael
>>>>>> 
>>>>>> Am 02.11.20 um 14:18 schrieb Bruce Johnson:
>>>>>>> A variety of packages (for example, VectorGraphics or JFreeSVG) exist 
>>>>>>> that allow redirecting Java2D drawing to output other than the Java2D 
>>>>>>> canvas.
>>>>>>> 
>>>>>>> These work by extending java.awt.Graphics2D.  By passing the extended 
>>>>>>> Graphics2D object into a paint method, output can be redirected to a 
>>>>>>> file (.svg, .pdf, etc.).
>>>>>>> 
>>&

Re: GraphicsContext and export to vector format files

[Bruce Johnson]

I should not even have mentioned the GraphicsContext for scene graph rendering. 
 There is something elegant about being able to easily make the whole scene 
render to some other device/file, but I’m well aware of the practical issues.

But I do wish there was a better solution for the original question.  Libraries 
like VectorGraphics and JFreeSVG are really useful for actual real world 
applications and I don’t see comparable tools appearing for JavaFX without some 
changes like I propose (or better ones than I can think of).

Bruce



> On Nov 2, 2020, at 5:04 PM, Kevin Rushforth  
> wrote:
> 
> Yeah, there is no chance we would consider changing the JavaFX to use Canvas 
> GraphicsContext for scene graph rendering.
> 
> As for the original question, we are unlikely to make GraphicsContext 
> extensible in the core JavaFX. I think the solution you came up with for your 
> application (with a proxy class and interface) is a reasonable approach.
> 
> -- Kevin
> 
> 
> On 11/2/2020 6:58 AM, Michael Paus wrote:
>> At this point I would disagree with you. Doing so would just
>> result in a sever performance hit. I will not go into the details
>> here because that idea is out of reach anyway.
>> 
>> Am 02.11.20 um 15:42 schrieb Bruce Johnson:
>>> And if you want to think of even further advances (which I’d avoid at this 
>>> point because I’d like this to get done in a useful time frame), I’ve often 
>>> thought that all JavaFX scene drawing should use the Canvas 
>>> GraphicsContext.  So with the changes I’m suggesting that would allow 
>>> export of the complete scene graph to another device (vector graphics files 
>>> etc.)
>>> 
>>> Bruce
>>> 
>>> 
>>>> On Nov 2, 2020, at 9:17 AM, Michael Paus  wrote:
>>>> 
>>>> Hi,
>>>> I very much like the idea in general but I think it falls too short.
>>>> Such an interface should not be tied to any existing graphics
>>>> framework. Instead it should be just pure Java. This would allow
>>>> to write complex graphics rendering code for a lot of different
>>>> platforms and not only platforms where JavaFX already exists
>>>> and can be used. Just think of the Android canvas or, via cross-
>>>> compilation, even the HTML 5 canvas.
>>>> Just my two €ent.
>>>> Michael
>>>> 
>>>> Am 02.11.20 um 14:18 schrieb Bruce Johnson:
>>>>> A variety of packages (for example, VectorGraphics or JFreeSVG) exist 
>>>>> that allow redirecting Java2D drawing to output other than the Java2D 
>>>>> canvas.
>>>>> 
>>>>> These work by extending java.awt.Graphics2D.  By passing the extended 
>>>>> Graphics2D object into a paint method, output can be redirected to a file 
>>>>> (.svg, .pdf, etc.).
>>>>> 
>>>>> The GraphicsContext class of JavaFX serves a similar function to 
>>>>> Graphics2D of java.awt, but because it is a final class it cannot be 
>>>>> extended to create similar functionality as found in VectorgGraphics or 
>>>>> JFreeSVG.
>>>>> 
>>>>> This is a serious limitation (at least as far as I can tell) to JavaFX 
>>>>> applications.  It would be highly desirable to be able to redirect 
>>>>> drawing on a Canvas to other output formats such as vector graphics files 
>>>>> (.svg, .pdf etc.).
>>>>> 
>>>>> I currently work around this by using composition.  I have a Java 
>>>>> interface that has most methods of GraphicsContext. Then a 
>>>>> GraphicsContextProxy class implements the interface and contains an 
>>>>> instance of GraphicsContext.  This class is used for drawing to the 
>>>>> Canvas.  I’ve then created a SVGGraphicsContext and PDFGraphicsContext 
>>>>> that implement the interface and these can be used to draw to .svg or 
>>>>> .pdf files.
>>>>> 
>>>>> This works, but means that all code that draws on the canvas has to be 
>>>>> rewritten to take the GraphicsContextInterface rather than the normal 
>>>>> GraphicsContext.
>>>>> 
>>>>> It would be much simpler if
>>>>> 1) GraphicsContext was not final and could be extended.
>>>>> or
>>>>> 2) A GraphicsContextInterface existed that GraphicsContext 
>>>>> implemented.  Developers could then have alternative GraphicsContext 
>>>>> implementations that implemented that interface.  This would require 
>>>>> canvas drawing code to be written to use the interface, but would still 
>>>>> be very useful.
>>>>> 
>>>>> Either solution could (I think) be easily implemented in JavaFX without 
>>>>> breaking existing code and add a significant advance to the toolkit.
>>>>> 
>>>>> If there are alternative solutions to the problem, that would allow 
>>>>> exporting canvas drawing to vector graphics files without requiring a 
>>>>> change to the code that draws to the canvas, I’d appreciate hearing them.
>>>>> 
>>>>> — Bruce
>>>>> 
>> 
> 

Re: GraphicsContext and export to vector format files

[Bruce Johnson]

Looks like a nice and useful project!  But,I’m looking for something specific 
to the JavaFX canvas and that doesn’t require use of java.awt.  There are many 
examples of code that has been built on top of java.awt.Graphics2D (like 
yours), but this doesn’t seem to be possible with the JavaFX GraphicsContext.  
I think some small changes within JavaFX would allow a lot of nice tools to be 
developed in a way similar to what was done with Graphics2D.

Bruce


> On Nov 2, 2020, at 8:51 AM, Hervé Girod  wrote:
> 
> Hello, Ivhabe created some time ago an OpenSource project called 
> jfcClnvertercwhichvtefurect the Jz aFX calls to a Graphics2D context. I don’t 
> know if it answers at least partially to this need. The project is here: 
> https://sourceforge.net/projects/jfxconverter/ 
> <https://sourceforge.net/projects/jfxconverter/>
> 
> Hervé
> 
> Sent from my iPhone
> 
>> On Nov 2, 2020, at 14:19, Bruce Johnson  wrote:
>> 
>> 
>> A variety of packages (for example,  VectorGraphics or JFreeSVG) exist that 
>> allow redirecting Java2D drawing to output other than the Java2D canvas. 
>> 
>> These work by extending java.awt.Graphics2D.  By passing the extended 
>> Graphics2D object into a paint method, output can be redirected to a file 
>> (.svg, .pdf, etc.).
>> 
>> The GraphicsContext class of JavaFX serves a similar function to Graphics2D 
>> of java.awt, but because it is a final class it cannot be extended to create 
>> similar functionality as found in VectorgGraphics or JFreeSVG.
>> 
>> This is a serious limitation (at least as far as I can tell) to JavaFX 
>> applications.  It would be highly desirable to be able to redirect drawing 
>> on a Canvas to other output formats such as vector graphics files (.svg, 
>> .pdf etc.).
>> 
>> I currently work around this by using composition.  I have a Java interface 
>> that has most methods of GraphicsContext.  Then a GraphicsContextProxy class 
>> implements the interface and contains an instance of GraphicsContext.  This 
>> class is used for drawing to the Canvas.  I’ve then created a 
>> SVGGraphicsContext and PDFGraphicsContext that implement the interface and 
>> these can be used to draw to .svg or .pdf files.
>> 
>> This works, but means that all code that draws on the canvas has to be 
>> rewritten to take the GraphicsContextInterface rather than the normal 
>> GraphicsContext.
>> 
>> It would be much simpler if
>>1) GraphicsContext was not final and could be extended.
>>or
>>2) A GraphicsContextInterface existed that GraphicsContext implemented.  
>> Developers could then have alternative GraphicsContext implementations that 
>> implemented that interface.  This would require canvas drawing code to be 
>> written to use the interface, but would still be very useful.
>> 
>> Either solution could (I think) be easily implemented in JavaFX without 
>> breaking existing code and add a significant advance to the toolkit.
>> 
>> If there are alternative solutions to the problem, that would allow 
>> exporting canvas drawing to vector graphics files without requiring a change 
>> to the code that draws to the canvas, I’d appreciate hearing them.
>> 
>> — Bruce
>> 

Re: GraphicsContext and export to vector format files

[Bruce Johnson]

And if you want to think of even further advances (which I’d avoid at this 
point because I’d like this to get done in a useful time frame), I’ve often 
thought that all JavaFX scene drawing should use the Canvas GraphicsContext.  
So with the changes I’m suggesting that would allow export of the complete 
scene graph to another device (vector graphics files etc.)

Bruce


> On Nov 2, 2020, at 9:17 AM, Michael Paus  wrote:
> 
> Hi,
> I very much like the idea in general but I think it falls too short.
> Such an interface should not be tied to any existing graphics
> framework. Instead it should be just pure Java. This would allow
> to write complex graphics rendering code for a lot of different
> platforms and not only platforms where JavaFX already exists
> and can be used. Just think of the Android canvas or, via cross-
> compilation, even the HTML 5 canvas.
> Just my two €ent.
> Michael
> 
> Am 02.11.20 um 14:18 schrieb Bruce Johnson:
>> A variety of packages (for example,  VectorGraphics or JFreeSVG) exist that 
>> allow redirecting Java2D drawing to output other than the Java2D canvas.
>> 
>> These work by extending java.awt.Graphics2D.  By passing the extended 
>> Graphics2D object into a paint method, output can be redirected to a file 
>> (.svg, .pdf, etc.).
>> 
>> The GraphicsContext class of JavaFX serves a similar function to Graphics2D 
>> of java.awt, but because it is a final class it cannot be extended to create 
>> similar functionality as found in VectorgGraphics or JFreeSVG.
>> 
>> This is a serious limitation (at least as far as I can tell) to JavaFX 
>> applications.  It would be highly desirable to be able to redirect drawing 
>> on a Canvas to other output formats such as vector graphics files (.svg, 
>> .pdf etc.).
>> 
>> I currently work around this by using composition.  I have a Java interface 
>> that has most methods of GraphicsContext.  Then a GraphicsContextProxy class 
>> implements the interface and contains an instance of GraphicsContext.  This 
>> class is used for drawing to the Canvas.  I’ve then created a 
>> SVGGraphicsContext and PDFGraphicsContext that implement the interface and 
>> these can be used to draw to .svg or .pdf files.
>> 
>> This works, but means that all code that draws on the canvas has to be 
>> rewritten to take the GraphicsContextInterface rather than the normal 
>> GraphicsContext.
>> 
>> It would be much simpler if
>>  1) GraphicsContext was not final and could be extended.
>>  or
>>  2) A GraphicsContextInterface existed that GraphicsContext implemented. 
>>  Developers could then have alternative GraphicsContext implementations that 
>> implemented that interface.  This would require canvas drawing code to be 
>> written to use the interface, but would still be very useful.
>> 
>> Either solution could (I think) be easily implemented in JavaFX without 
>> breaking existing code and add a significant advance to the toolkit.
>> 
>> If there are alternative solutions to the problem, that would allow 
>> exporting canvas drawing to vector graphics files without requiring a change 
>> to the code that draws to the canvas, I’d appreciate hearing them.
>> 
>> — Bruce
>> 
> 

Re: GraphicsContext and export to vector format files

[Bruce Johnson]

I think were’ not too far different in our ideas, but I think the practical 
odds of getting this implemented are much higher if the existing 
GraphicsContext methods are the base for the interface I propose.  I think (but 
could be wrong) that in fact the GraphicsContext was modeled after the HTML 5 
canvas so in that sense it forms a good base for what you suggest.  One could 
write code that drew to the Canvas, to an HTML 5 canvas, to graphics files etc. 
 It’s just that now, with GraphicsContext being a final class rather than 
non-final or an interface, one can’t do any of this.

Bruce



> On Nov 2, 2020, at 9:17 AM, Michael Paus  wrote:
> 
> Hi,
> I very much like the idea in general but I think it falls too short.
> Such an interface should not be tied to any existing graphics
> framework. Instead it should be just pure Java. This would allow
> to write complex graphics rendering code for a lot of different
> platforms and not only platforms where JavaFX already exists
> and can be used. Just think of the Android canvas or, via cross-
> compilation, even the HTML 5 canvas.
> Just my two €ent.
> Michael
> 
> Am 02.11.20 um 14:18 schrieb Bruce Johnson:
>> A variety of packages (for example,  VectorGraphics or JFreeSVG) exist that 
>> allow redirecting Java2D drawing to output other than the Java2D canvas.
>> 
>> These work by extending java.awt.Graphics2D.  By passing the extended 
>> Graphics2D object into a paint method, output can be redirected to a file 
>> (.svg, .pdf, etc.).
>> 
>> The GraphicsContext class of JavaFX serves a similar function to Graphics2D 
>> of java.awt, but because it is a final class it cannot be extended to create 
>> similar functionality as found in VectorgGraphics or JFreeSVG.
>> 
>> This is a serious limitation (at least as far as I can tell) to JavaFX 
>> applications.  It would be highly desirable to be able to redirect drawing 
>> on a Canvas to other output formats such as vector graphics files (.svg, 
>> .pdf etc.).
>> 
>> I currently work around this by using composition.  I have a Java interface 
>> that has most methods of GraphicsContext.  Then a GraphicsContextProxy class 
>> implements the interface and contains an instance of GraphicsContext.  This 
>> class is used for drawing to the Canvas.  I’ve then created a 
>> SVGGraphicsContext and PDFGraphicsContext that implement the interface and 
>> these can be used to draw to .svg or .pdf files.
>> 
>> This works, but means that all code that draws on the canvas has to be 
>> rewritten to take the GraphicsContextInterface rather than the normal 
>> GraphicsContext.
>> 
>> It would be much simpler if
>>  1) GraphicsContext was not final and could be extended.
>>  or
>>  2) A GraphicsContextInterface existed that GraphicsContext implemented. 
>>  Developers could then have alternative GraphicsContext implementations that 
>> implemented that interface.  This would require canvas drawing code to be 
>> written to use the interface, but would still be very useful.
>> 
>> Either solution could (I think) be easily implemented in JavaFX without 
>> breaking existing code and add a significant advance to the toolkit.
>> 
>> If there are alternative solutions to the problem, that would allow 
>> exporting canvas drawing to vector graphics files without requiring a change 
>> to the code that draws to the canvas, I’d appreciate hearing them.
>> 
>> — Bruce
>> 
> 

GraphicsContext and export to vector format files

[Bruce Johnson]

A variety of packages (for example,  VectorGraphics or JFreeSVG) exist that 
allow redirecting Java2D drawing to output other than the Java2D canvas. 

These work by extending java.awt.Graphics2D.  By passing the extended 
Graphics2D object into a paint method, output can be redirected to a file 
(.svg, .pdf, etc.).

The GraphicsContext class of JavaFX serves a similar function to Graphics2D of 
java.awt, but because it is a final class it cannot be extended to create 
similar functionality as found in VectorgGraphics or JFreeSVG.

This is a serious limitation (at least as far as I can tell) to JavaFX 
applications.  It would be highly desirable to be able to redirect drawing on a 
Canvas to other output formats such as vector graphics files (.svg, .pdf etc.).

I currently work around this by using composition.  I have a Java interface 
that has most methods of GraphicsContext.  Then a GraphicsContextProxy class 
implements the interface and contains an instance of GraphicsContext.  This 
class is used for drawing to the Canvas.  I’ve then created a 
SVGGraphicsContext and PDFGraphicsContext that implement the interface and 
these can be used to draw to .svg or .pdf files.

This works, but means that all code that draws on the canvas has to be 
rewritten to take the GraphicsContextInterface rather than the normal 
GraphicsContext.

It would be much simpler if
1) GraphicsContext was not final and could be extended.
or
2) A GraphicsContextInterface existed that GraphicsContext implemented. 
 Developers could then have alternative GraphicsContext implementations that 
implemented that interface.  This would require canvas drawing code to be 
written to use the interface, but would still be very useful.

Either solution could (I think) be easily implemented in JavaFX without 
breaking existing code and add a significant advance to the toolkit.

If there are alternative solutions to the problem, that would allow exporting 
canvas drawing to vector graphics files without requiring a change to the code 
that draws to the canvas, I’d appreciate hearing them.

— Bruce