Re: GraphicsContext and export to vector format files

[David Gilbert]

I would totally support this request from Bruce.  I’ve implemented a number of 
libraries (JFreeSVG, OrsonPDF, FXGraphics2D and SWTGraphics2D) on top of the 
Graphics2D API, as have others.  The Java2D engineers got this right back in 
1999!

All it needs is an API (interface) that users can code against without having 
to think about the implementation, and the ability to swap in an alternative 
implementation.  JavaFX prevents that, but it wouldn’t be that hard to rectify 
(as far as I can tell).

Best regards,

David

> On 03 Nov 2020, at 00:43, Bruce Johnson  wrote:
> 
> 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.).
 
 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 

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.).
>>> 
>>> 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 

Re: GraphicsContext and export to vector format files

[Kevin Rushforth]

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.).

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: Taskbar API from JavaFX Window?

[Will Iverson]

The bug reports are great, thank you.

Aside from philosophically voting up the issue not sure what else I can add.

Here is the (somewhat amusing) workaround thread from StackOverflow:
https://stackoverflow.com/questions/64616443/how-to-get-awt-window-for-javafx-stage/64651359#64651359

Cheers,
-Will



On Mon, Nov 2, 2020 at 1:29 PM Scott Palmer  wrote:

> For that API, you might consider using an AWT root Window with a JFXPanel
> rather than a JavaFX Window to hold your JavaFX UI.  But discussion of how
> to code the application side is not relevant for this list.
>
> For the record here are the relevant JavaFX issues:
> https://bugs.openjdk.java.net/browse/JDK-8091107
> https://bugs.openjdk.java.net/browse/JDK-8091517
>
> If you want to discuss those further, this list might be the right place.
> Currently JavaFX modules require the java.desktop module, so it doesn't
> hurt your JRE footprint to use the Swing integration.  Hopefully
> that dependency won't last long though (see
> https://bugs.openjdk.java.net/browse/JDK-8240844), and perhaps at the
> point the desktop module dependency is removed, the motivation to implement
> the above issues will be higher.
>
> Cheers,
>
> Scott
>
>
> On Mon, Nov 2, 2020 at 11:46 AM Will Iverson  wrote:
>
>> What Window should I pass in for the setWindowProgressState window
>> argument?  It requires a java.awt.Window?
>>
>> On Sun, Nov 1, 2020 at 5:48 PM Scott Palmer  wrote:
>>
>>> They work fine. Just remember to use the Swing/AWT event thread to call
>>> them.
>>>
>>> Scott
>>>
>>> > On Nov 1, 2020, at 8:39 PM, Will Iverson  wrote:
>>> >
>>> > Looking at native desktop integration with JavaFX.  As I was
>>> exploring, I
>>> > noticed that the java.awt.Taskbar API does not appear to be available
>>> for
>>> > JavaFX Windows.
>>> >
>>> >
>>> https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State)
>>> >
>>> > Many of the other methods on this class (e.g. setting progress, custom
>>> > icons) work fine on macOS from my testing so far.
>>> >
>>> > Is there any way to use the AWT methods from a JavaFX app?
>>> >
>>> > Cheers,
>>> > -Will
>>>
>>

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

[Kevin Rushforth]

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: Taskbar API from JavaFX Window?

[Scott Palmer]

For that API, you might consider using an AWT root Window with a JFXPanel
rather than a JavaFX Window to hold your JavaFX UI.  But discussion of how
to code the application side is not relevant for this list.

For the record here are the relevant JavaFX issues:
https://bugs.openjdk.java.net/browse/JDK-8091107
https://bugs.openjdk.java.net/browse/JDK-8091517

If you want to discuss those further, this list might be the right place.
Currently JavaFX modules require the java.desktop module, so it doesn't
hurt your JRE footprint to use the Swing integration.  Hopefully
that dependency won't last long though (see
https://bugs.openjdk.java.net/browse/JDK-8240844), and perhaps at the point
the desktop module dependency is removed, the motivation to implement the
above issues will be higher.

Cheers,

Scott


On Mon, Nov 2, 2020 at 11:46 AM Will Iverson  wrote:

> What Window should I pass in for the setWindowProgressState window
> argument?  It requires a java.awt.Window?
>
> On Sun, Nov 1, 2020 at 5:48 PM Scott Palmer  wrote:
>
>> They work fine. Just remember to use the Swing/AWT event thread to call
>> them.
>>
>> Scott
>>
>> > On Nov 1, 2020, at 8:39 PM, Will Iverson  wrote:
>> >
>> > Looking at native desktop integration with JavaFX.  As I was
>> exploring, I
>> > noticed that the java.awt.Taskbar API does not appear to be available
>> for
>> > JavaFX Windows.
>> >
>> >
>> https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State)
>> >
>> > Many of the other methods on this class (e.g. setting progress, custom
>> > icons) work fine on macOS from my testing so far.
>> >
>> > Is there any way to use the AWT methods from a JavaFX app?
>> >
>> > Cheers,
>> > -Will
>>
>

Re: RFR: 8255714: Switch FX build to use JDK 15.0.1 as boot JDK

[Johan Vos]

On Mon, 2 Nov 2020 12:47:06 GMT, Kevin Rushforth  wrote:

> Bump the boot JDK used to build JavaFX to 15.0.1. This does not change the 
> minimum boot JDK which remains at JDK 11.

Marked as reviewed by jvos (Reviewer).

-

PR: https://git.openjdk.java.net/jfx/pull/347

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/ 
> 
> 
> 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
>> 

Integrated: 8255415: Nested calls to snap methods in Region give different results

[Jose Pereda]

On Fri, 23 Oct 2020 08:32:59 GMT, Jose Pereda  wrote:

> As discussed in the [JBS 
> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an 
> already snapped value (either intentionally or by  mistake), the result 
> should be the same, otherwise we'll be jumping unnecessary from a valid pixel 
> to another pixel.
> 
> This PR provides a fix to `snapSizeXX` methods used in `Region`, which 
> ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value 
> before ceiling, to ensure snapping a snapped value gives the same value.
> 
> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 
> different UI scales is provided.
> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. 
> Only for 1.75 and the random 1.374562997 value fails (the test fails for 
> around 2% of the values with 1.75 and around 10% with 1.374562997).
> With the proposed fix, it doesn't fail at all.

This pull request has now been integrated.

Changeset: c31ed6bf
Author:Jose Pereda 
URL:   https://git.openjdk.java.net/jfx/commit/c31ed6bf
Stats: 114 lines in 3 files changed: 108 ins; 0 del; 6 mod

8255415: Nested calls to snap methods in Region give different results

Reviewed-by: kcr, fastegal, jvos

-

PR: https://git.openjdk.java.net/jfx/pull/336

Re: compile errors around JMemoryBuddy

[Florian Kirmaier]

Eclipse probably handles the modules differently than Gradle.
The simplest solution would be to remove the code to automatically create
heap dumps.
Adding java.management to module-info of the tests doesn't sound wrong to
me if it's using it.

On Mon, 2 Nov 2020 at 14:01, Kevin Rushforth 
wrote:

> I didn't try it with an earlier JDK, but if it breaks when using JDK 11
> it will need to be fixed.
>
> -- Kevin
>
>
> On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote:
> >
> > just fetched the latest upstream master and getting compile errors
> > around xx.management packages (eclipse wants to add requires into the
> > module-info - which certainly is the wrong way to go ;) Compiling
> > against jdk12, if that matters (will update one of these days but
> > shouldn't jdk11 be good enough).
> >
> > Any quick ideas on what might be wrong?
> >
> > -- Jeanette
> >
> >
>
>

Re: Taskbar API from JavaFX Window?

[Will Iverson]

What Window should I pass in for the setWindowProgressState window
argument?  It requires a java.awt.Window?

On Sun, Nov 1, 2020 at 5:48 PM Scott Palmer  wrote:

> They work fine. Just remember to use the Swing/AWT event thread to call
> them.
>
> Scott
>
> > On Nov 1, 2020, at 8:39 PM, Will Iverson  wrote:
> >
> > Looking at native desktop integration with JavaFX.  As I was exploring,
> I
> > noticed that the java.awt.Taskbar API does not appear to be available for
> > JavaFX Windows.
> >
> >
> https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State)
> >
> > Many of the other methods on this class (e.g. setting progress, custom
> > icons) work fine on macOS from my testing so far.
> >
> > Is there any way to use the AWT methods from a JavaFX app?
> >
> > Cheers,
> > -Will
>

Re: RFR: 8255415: Nested calls to snap methods in Region give different results [v5]

[Ambarish Rapte]

On Mon, 2 Nov 2020 13:07:11 GMT, Johan Vos  wrote:

>> Jose Pereda has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Apply fix to snapPortionXX methods, extend test.
>
> Looks good now.

Please go ahead and integrate with the current approvals.

-

PR: https://git.openjdk.java.net/jfx/pull/336

Re: GraphicsContext and export to vector format files

[Michael Paus]

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]

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
>> 
> 

Re: GraphicsContext and export to vector format files

[Michael Paus]

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: RFR: 8088739: [TestBug] RegionBackgroundImageUITest fail with timeout error

[Kevin Rushforth]

On Fri, 30 Oct 2020 16:04:51 GMT, Ambarish Rapte  wrote:

> Each test in RegionBackgroundImageUITest makes several calls to 
> `robot.getPixelColor()` on App thread. Due to this each test requires more 
> than **60** seconds for execution.
> 
> Fix is to save a screen capture of Scene (on App thread) and then read pixel 
> color from the screen capture(not on app thread). This reduces execution time 
> of each test to less than **3** seconds.
> Ideally with this fix(commit#1) all the tests should pass. All tests do pass 
> on Windows and Linux but three tests fail on Mac, which used to pass without 
> this change.
> - RegionBackgroundImageUITest.unalignedImage
> - RegionBackgroundFillUITest.testScenario2
> - RegionBackgroundFillUITest.testScenario3
> 
> commit#2 solves the above problem. Solution is to fallback to test color 
> again by reading it using `robot.getPixelColor()` on App thread when a test 
> fails.
> 
> One test RegionBackgroundImageUITest.unalignedImage_Cover, fails only on Mac 
> platform, before and after this fix.
> It is reported as a new issue 
> [JDK-8255679](https://bugs.openjdk.java.net/browse/JDK-8255679)
> 
> This is a test fix and affects only the tests that extend from 
> `RegionUITestBase` test class and does not affect other tests.
> Verified that `RegionBackgroundImageUITest` and `RegionBackgroundFillUITest` 
> tests pass on all three platforms(except 
> RegionBackgroundImageUITest.unalignedImage_Cover which fails on Mac).

The fact that you needed to implement a fallback to `Robot::getPixelColor` if 
reading a pixel from the buffer obtained by `Robot::getScreenCapture` fails (on 
Mac) suggests that `RegionBackgroundImageUITest` has some issues running on 
HiDPI displays. It also points out that there is a difference between the 
scaling algorithm used to read a single pixel vs an array of pixels (this might 
be a bug in Robot itself).

I confirmed the fact that these problems are related to HiDPI scaling by 
running it on my Windows 10 system with 125% scaling, and I get 30 test 
failures. I instrumented the code and I see a couple hundred fallbacks per test 
even for the non-failing tests. If I force screen scale to 1 on Windows then 
all tests pass with no fallbacks.

We used to have this problem for some of the tests in 
`RegionBackgroundFillUITest` as well. The fix for 
[JDK-8170026](https://bugs.openjdk.java.net/browse/JDK-8170026) addressed this 
by skipping the tests that were sensitive to screen scale (14 of them).  You 
either need to do something similar for `RegionBackgroundImageUITest` or else 
fix the tests to work with different screen scales (this would be challenging).

-

Changes requested by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/344

Re: GraphicsContext and export to vector format files

[Hervé Girod]

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/

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
> 

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

Re: RFR: 8255415: Nested calls to snap methods in Region give different results [v5]

[Johan Vos]

On Tue, 27 Oct 2020 12:56:28 GMT, Jose Pereda  wrote:

>> As discussed in the [JBS 
>> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an 
>> already snapped value (either intentionally or by  mistake), the result 
>> should be the same, otherwise we'll be jumping unnecessary from a valid 
>> pixel to another pixel.
>> 
>> This PR provides a fix to `snapSizeXX` methods used in `Region`, which 
>> ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value 
>> before ceiling, to ensure snapping a snapped value gives the same value.
>> 
>> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 
>> different UI scales is provided.
>> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. 
>> Only for 1.75 and the random 1.374562997 value fails (the test fails for 
>> around 2% of the values with 1.75 and around 10% with 1.374562997).
>> With the proposed fix, it doesn't fail at all.
>
> Jose Pereda has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Apply fix to snapPortionXX methods, extend test.

Looks good now.

-

Marked as reviewed by jvos (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/336

Re: compile errors around JMemoryBuddy

[Kevin Rushforth]

I didn't try it with an earlier JDK, but if it breaks when using JDK 11 
it will need to be fixed.


-- Kevin


On 11/2/2020 4:11 AM, Jeanette Winzenburg wrote:


just fetched the latest upstream master and getting compile errors 
around xx.management packages (eclipse wants to add requires into the 
module-info - which certainly is the wrong way to go ;) Compiling 
against jdk12, if that matters (will update one of these days but 
shouldn't jdk11 be good enough).


Any quick ideas on what might be wrong?

-- Jeanette

RFR: 8255714: Switch FX build to use JDK 15.0.1 as boot JDK

[Kevin Rushforth]

Bump the boot JDK used to build JavaFX to 15.0.1. This does not change the 
minimum boot JDK which remains at JDK 11.

-

Commit messages:
 - 8255714: Switch FX build to use JDK 15.0.1 as boot JDK

Changes: https://git.openjdk.java.net/jfx/pull/347/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=347=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255714
  Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jfx/pull/347.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/347/head:pull/347

PR: https://git.openjdk.java.net/jfx/pull/347

Re: compile errors around JMemoryBuddy

[Jeanette Winzenburg]

seems to be an Eclipse problem, compiling (and running tests in  
controls) via gradle on commandline looks okay ..


Zitat von Jeanette Winzenburg :

just fetched the latest upstream master and getting compile errors  
around xx.management packages (eclipse wants to add requires into  
the module-info - which certainly is the wrong way to go ;)  
Compiling against jdk12, if that matters (will update one of these  
days but shouldn't jdk11 be good enough).


Any quick ideas on what might be wrong?

-- Jeanette

Re: RFR: 8255415: Nested calls to snap methods in Region give different results [v5]

[Jeanette Winzenburg]

On Tue, 27 Oct 2020 12:56:28 GMT, Jose Pereda  wrote:

>> As discussed in the [JBS 
>> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an 
>> already snapped value (either intentionally or by  mistake), the result 
>> should be the same, otherwise we'll be jumping unnecessary from a valid 
>> pixel to another pixel.
>> 
>> This PR provides a fix to `snapSizeXX` methods used in `Region`, which 
>> ultimately use `Math.ceil`, by subtracting an epsilon value to scaled value 
>> before ceiling, to ensure snapping a snapped value gives the same value.
>> 
>> A test to verify `snapSizeX` and `snapSizeY` with 1000 random values, and 6 
>> different UI scales is provided.
>> For the 1.0, 1.25, 1.5 and 2.0 UI scales, the current approach works fine. 
>> Only for 1.75 and the random 1.374562997 value fails (the test fails for 
>> around 2% of the values with 1.75 and around 10% with 1.374562997).
>> With the proposed fix, it doesn't fail at all.
>
> Jose Pereda has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Apply fix to snapPortionXX methods, extend test.

not the requested reviewer, but this looks good to me :)

-

Marked as reviewed by fastegal (Committer).

PR: https://git.openjdk.java.net/jfx/pull/336