Re: JDK-8088535 Memory Leak

[Dirk Lemmermann]

In my case (1) it is a complex clipping shape that gets created based on an 
initial rectangle from which the code „subtracts“ a list of ellipses (2). The 
clip is set on paths so that their rendering stops before they enter the 
ellipses.

—Dirk

(1) https://twitter.com/dlemmermann/status/1474059970857644032 

(2) https://gist.github.com/5f4f45aa150c23f2e218b48a18d22121 



> Am 03.01.2022 um 09:34 schrieb John Hendrikx :
> 
> I tested this, and it seems to still not work quite right.
> 
> As far as I can see, it is not a memory leak, just slow performance when 
> subtracting many shapes from roughly the same location from another shape.  
> When the shapes are more spread out, it performs better.
> 
> I don't think it is a major issue, definitely not for regular uses of shapes.
> 
> Doing "game" like graphics is often an exercise to find how an API can be 
> best exploited to get what you want with good performance; telling an API to 
> brute-force render 1 points in a 100x100 grid for example won't perform 
> well, put them on a texture instead and it will perform well.
> 
> This seems to be a similar case, so I'd recommend to use a Canvas, and draw 
> circles on that instead.
> 
> --John
> 
> On 02/01/2022 15:56, Eric Bresie wrote:
>> Noticed a recent tweet (1) about an older memory leak issue (2) and was
>> curious if with recent performance and memory changes if anyone can confirm
>> if this is still an issue or if it has been resolved as part of the recent
>> changes.  There appears to be a test attached to the original issue.
>> 
>> Eric
>> 
>> References:
>> (1) https://twitter.com/dlemmermann/status/1477340490299330566?s=21
>> 
>> (2) https://bugs.openjdk.java.net/browse/JDK-8088535
>> 

RFE: Style class for prompt text in text input controls

[Dirk Lemmermann]

I noticed that the „Text“ node used to display the prompt text of a text input 
control could definitely use its own style class. At least if you want to use a 
different font for it than for the normal text. Currently the prompt text node 
is bound to the same font property of the control as the regular „Text“ nodes. 

I had a customer request today to style them differently in a TextArea: the 
prompt text with a light font, the regular text with a bold font. The only way 
to implement this was to listen to the text property of the TextArea and add / 
remove the class „blank“ to it. Then I could use this class in the CSS file.

Dirk

Re: Enhancements for JavaFX 18

[Dirk Lemmermann]

Frosted glas / blurred background for stages!

> Am 11.08.2021 um 22:07 schrieb Thiago Milczarek Sayão 
> :
> 
> Hi,
> 
> One feature I will probably submit is touch events on Linux.
> 
> Cheers.
> 
> Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth <
> kevin.rushfo...@oracle.com> escreveu:
> 
>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
>> and enhancement requests for JavaFX 18. It's the summer, so there may be
>> delays as some people are out at various times (including me), but I
>> would like to get some of the outstanding enhancement requests moving
>> over the next few weeks.
>> 
>> Specifically, I'd like to see the following proceed:
>> 
>> * Transparent backgrounds in WebView
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
>> PR: https://github.com/openjdk/jfx/pull/563
>> 
>> * Add DirectionalLight
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
>> PR: https://github.com/openjdk/jfx/pull/548
>> 
>> * CSS pseudoclasses :focus-visible and :focus-within
>> https://bugs.openjdk.java.net/browse/JDK-8268225
>> PR: https://github.com/openjdk/jfx/pull/475
>> 
>> * Improve property system to facilitate correct usage (minus the binary
>> incompatible API change)
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>> 
>> And maybe the following:
>> 
>> * Add CSS themes as a first-class concept (need a consensus on how to
>> proceed)
>> 
>> * Undecorated interactive stage style (still in early discussion, but
>> the concept looks interesting and useful)
>> 
>> There are probably others I'm forgetting.
>> 
>> Each of the above should be discussed in their own thread on openjfx-dev
>> rather than a reply to this thread.
>> 
>> -- Kevin
>> 
>> 
>> 

Re: Enhancements for JavaFX 18

[Dirk Lemmermann]

+1

Tom Eugelink  schrieb am Mi. 4. Aug. 2021 um 16:31:

> +1
>
> On 2021-08-04 11:58, Jeanette Winzenburg wrote:
> >
> > my suggestion would be the longstanding commit-edit-on-focus-lost -
> solved by an enhancement to the editing api on virtualized controls
> >
> > -- Jeanette
> >
> > Zitat von Kevin Rushforth :
> >
> >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I would
> like to get some of the outstanding enhancement requests moving over the
> next few weeks.
> >>
> >> Specifically, I'd like to see the following proceed:
> >>
> >> * Transparent backgrounds in WebView
> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> >> PR: https://github.com/openjdk/jfx/pull/563
> >>
> >> * Add DirectionalLight
> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> >> PR: https://github.com/openjdk/jfx/pull/548
> >>
> >> * CSS pseudoclasses :focus-visible and :focus-within
> >> https://bugs.openjdk.java.net/browse/JDK-8268225
> >> PR: https://github.com/openjdk/jfx/pull/475
> >>
> >> * Improve property system to facilitate correct usage (minus the binary
> incompatible API change)
> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> >> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
> >>
> >> And maybe the following:
> >>
> >> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
> >>
> >> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
> >>
> >> There are probably others I'm forgetting.
> >>
> >> Each of the above should be discussed in their own thread on
> openjfx-dev rather than a reply to this thread.
> >>
> >> -- Kevin
> >
> >
> >
>
> --
Dirk Lemmermann

Software & Consulting
Zurich, Switzerland
+41-(0)79-800-23-20
http://www.dlsc.com
mailto:dlemmerm...@gmail.com

Re: Not really a nice comment but a real issue?

[Dirk Lemmermann]

I took the liberty of informing the author of the blog. It was hard not to 
comment on the tone he used ….. but we all know that never leads to anything. 
Let the facts speak for themselves and they tell him that he was heard and his 
findings resulted in tickets and hopefully fixes soon.

Dirk

> On Mar 19, 2021, at 5:29 PM, Kevin Rushforth  
> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8263886
> 
> On 3/19/2021 9:17 AM, Kevin Rushforth wrote:
>> That's an interesting idea about looking at the HTTP response headers and 
>> checking to see whether the file has changed. If it could be done in such a 
>> way that it minimizes overhead, it might be the best of both worlds. I'll 
>> file an RFE to look into that...not sure we'll get time to do it, though, so 
>> if someone from the community wants to take it, that would help.
>> 
>> Regarding an "opt out" mechanism, If someone wants to propose an API to do 
>> that, we'd be happy to consider it (as with the above, it will be more 
>> likely to get done if someone volunteers to drive it to completion). The 
>> main question I can think of that would need to be answered is: what should 
>> be the granularity of the new boolean attribute? Global (probably on 
>> Platform then)? Per Scene? Per Region (which would also need to be on the 
>> Scene with Region overriding it)? Another is around what the behavior should 
>> be of setting it from "false" back to the (default) "true".
>> 
>> -- Kevin
>> 
>> 
>> On 3/19/2021 9:08 AM, Richard Bair wrote:
>>> Hey everybody!
>>> 
>>> These all sound like really good points. I agree with Pedro that the 
>>> ability to auto-reload (especially during development) is a really great 
>>> thing, but I agree with the blog post and Clemens that in production this 
>>> can be problematic depending on the location of the source CSS file, and in 
>>> any event does introduce some performance overhead that would be nice to 
>>> avoid.
>>> 
>>> Could JavaFX look at response headers when loading CSS over HTTP/S to 
>>> determine whether the CSS file can be cached and then maintain a local 
>>> cache for such CSS files? That would resolve one particular issue where CSS 
>>> is loaded remotely. Could JavaFX use a different mechanism for watching the 
>>> CSS files when loaded from disk so that it isn’t re-read every time but 
>>> only when a change had been detected? I think both of those enhancements 
>>> could probably be done while remaining consistent with the existing 
>>> semantics. Add the Bug fix in that Kevin mentioned and I think most of the 
>>> practical problems raised by the blog post would be fixed.
>>> 
>>> Cheers
>>> Richard
>>> 
 On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira 
  wrote:
 
 In the blog post he makes it sounds like it isn't good for anything to have
 that. That it is just a bug, something that wasn't well thought through and
 reviewed or a pointless feature. Which I totally disagree with. I think it
 can be very interesting to take advantage of that.
 
 I think the performance problem he measured was more about the buffering
 issue than about dynamically reloading the stylesheet whenever there's a
 change. But yeah, this might have a performance impact. If there is indeed
 a considerable impact, perhaps we could have a flag to opt out of this
 feature. That way we can have the best of both worlds and not have this
 feature impact the apps performance in production.
 
 Cheers,
 
 
 A good feature during development is not necessarily a good feature during
> production, especially if it (apparently) has a significant performance
> impact.
> But I see your point.
> 
> On 19-3-2021 15:32, Pedro Duque Vieira wrote:
>> Hi
>> 
>> I actually totally disagree with his conclusion.
>> 
>> In fact, I'd say, that's one of the hidden gems of JavaFX!
>> Check out CSSFX and this video
> https://www.youtube.com/watch?v=RELKg32xEWU
>> to understand the advantages of this feature (ScenicView has also
>> integrated CSSFX to take advantage of this).
>> 
>> Think about the productivity boost of tweaking your UI at runtime and not
>> having to go through the cycle: tweak UI -> compile -> run -> (No that's
>> not it) -> close app -> tweak UI again -> compile again -> run again ->
> (No
>> that's not it again) -> [repeat till infinity]
>> 
>> Also think about the potential for adding tools that build on top of this
>> feature. Tools like firebug or features from Chrome developer tools, etc,
>> that they use on the web to debug / tweak UIs during runtime.
>> 
>> Cheers,
>> 
>> 
>>> On 19-3-2021 14:29, Clement Levallois wrote:
 Hi all,
 
 I just came across this blog post which complains about a badly
>>> implemented stream reader in JavaFX. The general tone is not nice, but I
>>> figured this could be us

RFE: Shape Intersection

[Dirk Lemmermann]

I just noticed that there is no „intuitive“ API to check whether two shapes 
intersect with each other. The only way (I think) to do it is as follows:

Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth() != -1

If this is indeed the case I would like to propose that a method shall be added 
called „boolean Shape.intersects(Shape,Shape").

See also: 
https://stackoverflow.com/questions/15013913/checking-collision-of-shapes-with-javafx
 


Dirk

Re: Can't load fxml on Macos

[Dirk Lemmermann]

I worked with JavaFX on MacOS since 2013 and except for issues related to font 
rendering I never got the impression that MacOS is the black sheep. I also 
happen to know that many of the developers that are working on JavaFX use MacOS.

Dirk

> On Oct 20, 2020, at 12:28 PM, Davide Perini  
> wrote:
> 
> Hi all,
> this code works well on both Windows and Linux running Java 15 on JavaFX 15.
> 
> FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + 
> Constants.FXML)); return fxmlLoader.load();
> 
> 
> It doesn't work on Macos returning a nullpointer exception.
> 
> Any idea? Why Macos is always the black sheep?
> 
> Thanks
> Davide

Re: RFR: 8251241: macOS: iconify property doesn't change after minimize when resizable is false

[Dirk Lemmermann]

On Thu, 13 Aug 2020 12:52:37 GMT, Florian Kirmaier  
wrote:

>>> JDK-8251241: macOS: iconify property doesn't change after minimize when 
>>> resizable is false ⚠️ Title mismatch between PR
>>> and JBS.
>> 
>> Can you change the title to match the JBS title?
>
> Done! I've changed the title.

Thank you Florian!!! :-)

-

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

Re: TableView help

[Dirk Lemmermann]

Hi John,

the model class used by your TableView is called “SimpleImmutableEntry”. The 
middle part of this name should be enough to tell you what the problem is :-)

Solution: create your own custom model class and provide setters and getters 
for “key” and “value”. Then the TableView will write back into your POJO.

In other news: this mailing list is meant for "Technical discussion related to 
the OpenJFX Project”, so you might wanna find a different place for support 
questions like this one. In this mailing list we discuss things like bugs in 
OpenJFX and their potential fixes.

Dirk

> On 13 May 2020, at 02:05, John Scancella  wrote:
> 
> Hello All,
> 
> I am hoping to get some help with setting up a TableView. What I want is a
> simple two column table with each column containing Strings. I want to be
> able to double click to create a new row if I double clicked on empty
> space. And I want to be able to edit any cell already in the table.
> 
> Currently I am struggling with editing the data already in the table. I can
> click and edit, but then if I double click again on the cell it reverts
> back to the original value. If I try and get the value programmatically, it
> is still getting the original value, even though the display is showing the
> new value.
> 
> You can see my code here: https://github.com/jscancella/heirloom
> I am using java version "1.8.0_251"
> 
> Thank you in advance for any help!
> 
> 
> -- 
> ~John Scancella

Re: White box / window flicker upon launch

[Dirk Lemmermann]

I tried as you suggested. Problem is still there.

> On 23 Apr 2020, at 16:00, David Grieve  wrote:
> 
> Another possible workaround is to call Node#applyCss() before stage.show(). 
> There is an example in the Javadoc for the applyCss() method.
> 
> -Original Message-
> From: openjfx-dev  On Behalf Of Dirk 
> Lemmermann
> Sent: Wednesday, April 22, 2020 1:46 PM
> To: OpenJFX 
> Subject: [EXTERNAL] White box / window flicker upon launch
> 
> Hi everyone,
> 
> is it just me or did something change in the launch behaviour of JavaFX 
> applications? It seems we are back to the old “grey box” bug of Swing where 
> the window would appear first before filling its content. I noticed the same 
> (but white) effect now for my JavaFX apps, especially when running on mobile 
> devices via Gluon. Once I saw it there I paid attention to it and also 
> noticed it when running my desktop apps (on MacOS). I must admit that I am 
> also not certain if it has been different before. Maybe I simply notice it 
> now?
> 
> To verify run this little program. You have to pay close attention but if I 
> am not mistaken then the window first shows up with a white background before 
> showing its content, which is orange.
> 
> Can somebody confirm? If so, I will create a bug ticket.
> 
> Regards,
> 
> Dirk
> 
> 
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.layout.VBox;
> import javafx.stage.Stage;
> 
> public class BugDemo extends Application {
> 
>public void start(Stage stage) {
>VBox root = new VBox();
>root.setStyle("-fx-background-color: orange;");
>Scene scene = new Scene(root, 1000, 800);
>stage.setScene(scene);
>stage.show();
>}
> 
>public static void main(String[] args) {
>launch(args);
>}
> }

Re: White box / window flicker upon launch

[Dirk Lemmermann]

I notice the word “workaround” :-) So you would agree it is a bug? And if so …. 
regression? I never noticed it before.

> On 23 Apr 2020, at 16:00, David Grieve  wrote:
> 
> Another possible workaround is to call Node#applyCss() before stage.show(). 
> There is an example in the Javadoc for the applyCss() method.
> 
> -Original Message-
> From: openjfx-dev  On Behalf Of Dirk 
> Lemmermann
> Sent: Wednesday, April 22, 2020 1:46 PM
> To: OpenJFX 
> Subject: [EXTERNAL] White box / window flicker upon launch
> 
> Hi everyone,
> 
> is it just me or did something change in the launch behaviour of JavaFX 
> applications? It seems we are back to the old “grey box” bug of Swing where 
> the window would appear first before filling its content. I noticed the same 
> (but white) effect now for my JavaFX apps, especially when running on mobile 
> devices via Gluon. Once I saw it there I paid attention to it and also 
> noticed it when running my desktop apps (on MacOS). I must admit that I am 
> also not certain if it has been different before. Maybe I simply notice it 
> now?
> 
> To verify run this little program. You have to pay close attention but if I 
> am not mistaken then the window first shows up with a white background before 
> showing its content, which is orange.
> 
> Can somebody confirm? If so, I will create a bug ticket.
> 
> Regards,
> 
> Dirk
> 
> 
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.layout.VBox;
> import javafx.stage.Stage;
> 
> public class BugDemo extends Application {
> 
>public void start(Stage stage) {
>VBox root = new VBox();
>root.setStyle("-fx-background-color: orange;");
>Scene scene = new Scene(root, 1000, 800);
>stage.setScene(scene);
>stage.show();
>}
> 
>public static void main(String[] args) {
>launch(args);
>}
> }

Re: White box / window flicker upon launch

[Dirk Lemmermann]

Ticket created: ID 9064689

Dirk

> On 23 Apr 2020, at 13:40, Dirk Lemmermann  wrote:
> 
> I think this is a bug … I will create a ticket for it. When this behaviour 
> was fixed for Swing in Java 6 it made a huge difference in the perception of 
> the quality and performance of Java applications. Could do the same for 
> JavaFX.
> 
> Dirk
> 
> 
>> On 22 Apr 2020, at 20:17, Tom Schindl  wrote:
>> 
>> yes I do but I think this is by nature:
>> 
>> a) you use CSS so only after the first CSS-Pass the color could be set
>>  appropriately, this CSS pass could happen after the Native-Window is
>>  shown
>>  => you can mitigate that a bit using
>>  root.setBackground(new Background(new BackgroundFill(Color.ORANGE,
>> CornerRadii.EMPTY, Insets.EMPTY)));
>> 
>> b) if the above gives you short flash (IMHO shorter than with CSS) and
>>  you can see that by setting eg RED or GREEN as the Scene-Fill so then
>>  it gets more prominent
>> 
>> So the flash is gone if you put the same color to Scene.setFill() as your 
>> root-Pane but now something slightly unexpected happens. The trim is colored 
>> slighly in your scene-color ;-)
>> 
>> Tom
>> 
>> Am 22.04.20 um 19:46 schrieb Dirk Lemmermann:
>>> import javafx.application.Application;
>>> import javafx.scene.Scene;
>>> import javafx.scene.layout.VBox;
>>> import javafx.stage.Stage;
>>> public class BugDemo extends Application {
>>>public void start(Stage stage) {
>>>VBox root = new VBox();
>>>root.setStyle("-fx-background-color: orange;");
>>>Scene scene = new Scene(root, 1000, 800);
>>>stage.setScene(scene);
>>>stage.show();
>>>}
>>>public static void main(String[] args) {
>>>launch(args);
>>>}
>>> }
> 

Re: White box / window flicker upon launch

[Dirk Lemmermann]

I think this is a bug … I will create a ticket for it. When this behaviour was 
fixed for Swing in Java 6 it made a huge difference in the perception of the 
quality and performance of Java applications. Could do the same for JavaFX.

Dirk


> On 22 Apr 2020, at 20:17, Tom Schindl  wrote:
> 
> yes I do but I think this is by nature:
> 
> a) you use CSS so only after the first CSS-Pass the color could be set
>   appropriately, this CSS pass could happen after the Native-Window is
>   shown
>   => you can mitigate that a bit using
>   root.setBackground(new Background(new BackgroundFill(Color.ORANGE,
>  CornerRadii.EMPTY, Insets.EMPTY)));
> 
> b) if the above gives you short flash (IMHO shorter than with CSS) and
>   you can see that by setting eg RED or GREEN as the Scene-Fill so then
>   it gets more prominent
> 
> So the flash is gone if you put the same color to Scene.setFill() as your 
> root-Pane but now something slightly unexpected happens. The trim is colored 
> slighly in your scene-color ;-)
> 
> Tom
> 
> Am 22.04.20 um 19:46 schrieb Dirk Lemmermann:
>> import javafx.application.Application;
>> import javafx.scene.Scene;
>> import javafx.scene.layout.VBox;
>> import javafx.stage.Stage;
>> public class BugDemo extends Application {
>> public void start(Stage stage) {
>> VBox root = new VBox();
>> root.setStyle("-fx-background-color: orange;");
>> Scene scene = new Scene(root, 1000, 800);
>> stage.setScene(scene);
>> stage.show();
>> }
>> public static void main(String[] args) {
>> launch(args);
>> }
>> }

White box / window flicker upon launch

[Dirk Lemmermann]

Hi everyone,

is it just me or did something change in the launch behaviour of JavaFX 
applications? It seems we are back to the old “grey box” bug of Swing where the 
window would appear first before filling its content. I noticed the same (but 
white) effect now for my JavaFX apps, especially when running on mobile devices 
via Gluon. Once I saw it there I paid attention to it and also noticed it when 
running my desktop apps (on MacOS). I must admit that I am also not certain if 
it has been different before. Maybe I simply notice it now?

To verify run this little program. You have to pay close attention but if I am 
not mistaken then the window first shows up with a white background before 
showing its content, which is orange.

Can somebody confirm? If so, I will create a bug ticket.

Regards,

Dirk


import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class BugDemo extends Application {

public void start(Stage stage) {
VBox root = new VBox();
root.setStyle("-fx-background-color: orange;");
Scene scene = new Scene(root, 1000, 800);
stage.setScene(scene);
stage.show();
}

public static void main(String[] args) {
launch(args);
}
}

Re: ComboBox keypress discrepancy

[Dirk Lemmermann]

Regarding expected behaviour: in native combo boxes / dropdowns on Mac the TAB 
key is doing nothing when the popup is open. If you want to select an item you 
need to use the arrow keys. So I guess that is what I would expect for 
navigating the element. But that does not mean that the key event can’t fire, 
right? Some subclass / custom control might have a need for it.

Dirk



> Am 06.03.2020 um 05:59 schrieb Abhinay Agarwal :
> 
> Hi Dirk,
> 
> Thanks for reaching out. As stated earlier, I want to know what exactly is 
> causing this change in behaviour. I also want to know what is the expected 
> behaviour in this case: should TAB key press trigger when the popupwindow is 
> showing?
> 
> -- Abhinay
> From: Dirk Lemmermann 
> Sent: Thursday, March 5, 2020 6:39 PM
> To: Abhinay Agarwal 
> Cc: openjfx-dev@openjdk.java.net 
> Subject: Re: ComboBox keypress discrepancy
>  
> So what info do you need? What test do you want us to run?
> 
> I ran it on MacOS X with Java 14ea and I DO NOT see the „TAB“ output.
> 
> Dirk
> 
>> Am 05.03.2020 um 11:43 schrieb Abhinay Agarwal > <mailto:abhinay_agar...@live.com>>:
>> 
>> import javafx.application.Application;
>> import javafx.scene.Scene;
>> import javafx.scene.control.ComboBox;
>> import javafx.scene.input.KeyEvent;
>> import javafx.scene.layout.BorderPane;
>> import javafx.stage.Stage;
>> 
>> public class Main extends Application {
>> 
>>@Override
>>public void start(Stage primaryStage) {
>>final ComboBox stringComboBox = new ComboBox<>();
>>stringComboBox.getItems().addAll("John", "Jacob", "Schmidt");
>>stringComboBox.addEventHandler(KeyEvent.KEY_PRESSED, kp -> 
>> System.out.println(kp.getCode()));
>> 
>>final Scene scene = new Scene(new BorderPane(stringComboBox), 300, 
>> 275);
>>primaryStage.setScene(scene);
>>primaryStage.show();
>>}
>> 
>>public static void main(String[] args) {
>>launch(args);
>>}
>> }

Re: ComboBox keypress discrepancy

[Dirk Lemmermann]

So what info do you need? What test do you want us to run?

I ran it on MacOS X with Java 14ea and I DO NOT see the „TAB“ output.

Dirk

> Am 05.03.2020 um 11:43 schrieb Abhinay Agarwal :
> 
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.control.ComboBox;
> import javafx.scene.input.KeyEvent;
> import javafx.scene.layout.BorderPane;
> import javafx.stage.Stage;
> 
> public class Main extends Application {
> 
>@Override
>public void start(Stage primaryStage) {
>final ComboBox stringComboBox = new ComboBox<>();
>stringComboBox.getItems().addAll("John", "Jacob", "Schmidt");
>stringComboBox.addEventHandler(KeyEvent.KEY_PRESSED, kp -> 
> System.out.println(kp.getCode()));
> 
>final Scene scene = new Scene(new BorderPane(stringComboBox), 300, 
> 275);
>primaryStage.setScene(scene);
>primaryStage.show();
>}
> 
>public static void main(String[] args) {
>launch(args);
>}
> }

No screen coordinates for DRAG_DONE events

[Dirk Lemmermann]

Need some help: I noticed that the DRAG_DONE event does not tell me the 
location of the event. I am working on a docking framework and the fact that I 
am receiving a DRAG_DONE event but not a DRAG_DROPPED tells me that the user 
dragged a docking item out of the docking container. If that is the case I 
would like to show a new stage at the event location but it turns out that the 
x and y fields are always set to 0 / 0 on the event object. Is this intentional 
or a bug?

Dirk

Difference in CSS styling / rendering.

[Dirk Lemmermann]

Hi,

I just noticed that the timeline in FlexGanttFX does not get rendered correctly 
anymore after updating to 14-ea+4. The borders around the date cells 
disappeared.

I assume that this must be somehow related to the CSS fix that made it into 
this version. 

This is just a heads-up. If possible I will try to create a standalone example 
for this issue, but considering the complexity of this control it might be 
difficult to do so.

Dirk

Re: JavaFX-Bugs on GraalVM 19.3 (Java 11)

[Dirk Lemmermann]

OK, I understand. But a real world application that already consists of say 
10 lines of code with tons of dependencies would require an enormous amount 
of work before the list of classes that need to be added to the reflections 
list is complete. This would be a trial and error approach. Launch …. “oh, that 
is missing” …. launch …. “oh that is missing” …. etc …. correct?

Dirk

> On 21 Nov 2019, at 19:24, Johan Vos  wrote:
> 
> Please file issues if you run into them:
> * JavaFX related: http://bugs.openjdk.java.net/ 
> <http://bugs.openjdk.java.net/>
> * GraalVM related: https://github.com/oracle/graal/issues/ 
> <https://github.com/oracle/graal/issues/>
> * Substrate related: https://github.com/gluonhq/substrate/issues 
> <https://github.com/gluonhq/substrate/issues>
> 
> Keep in mind that with these new approaches come new docs, so make sure to 
> read them.
> 
> What you're saying sounds like you're not specifying the classes that are 
> accessed via Reflection. (Integer.parseInt for example). In the future, 
> agents will automatically add these for you, but for now you specify them 
> (e.g. via the client-maven-plugin by specifying it in the reflectionlist 
> property).
> The GraalVM native-image docs are pretty good in explaining the reasons 
> behind this.
> All reflection/JNI required by the JavaFX framework should be handled by 
> Substrate already. But if you use e.g. injection frameworks, you'll have to 
> add the classes. See 
> https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md 
> <https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md> and 
> see the code in e.g. 
> https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95
>  
> <https://github.com/gluonhq/client-maven-plugin/blob/master/src/main/java/com/gluonhq/NativeBaseMojo.java#L95>
>  how this can be done with Substrate.
> 
> - Johan
> 
> 
> 
> On Thu, Nov 21, 2019 at 6:30 PM Dirk Lemmermann  <mailto:dlemmerm...@gmail.com>> wrote:
> After experimenting a lot today with the Gluon client plugin I must assume 
> that currently not all of Java is supported via the substrate / GraalVM duo.
> For example I was unable to use the java.util.Preferences API. I also got an 
> error that said Integer.parseInt() does not exist.
> 
> Is that correct?
> 
> > On 21 Nov 2019, at 18:26, Johan Vos  > <mailto:johan@gluonhq.com>> wrote:
> > 
> > We have samples showing how to build and run JavaFX applications using
> > GraalVM. See our blog post [1] with samples [2].
> > 
> > Keep in mind that JavaFX has some characteristics that make it non-trivial
> > to apply native-image out of the box (reflection/jni configuration,
> > platform-specific static libraries, including resources and bundles...).
> > This is why we created Gluon Substrate [3], which does most of this work:
> > Developers use a maven plugin [4] (gradle will be ready soon too) and this
> > is used in the samples [2].
> > 
> > If you use GraalVM native-image without all the parameters that Gluon
> > Substrate adds, you will most likely create a "fallback-image" that still
> > require a JVM and some other resources to be available at runtime, and this
> > can give strange results. While I don't exclude JavaFX bugs will surface
> > using this approach, I think it's more likely you're seeing issues due to
> > this "mixed mode".
> > 
> > - Johan
> > 
> > [1]
> > https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/
> >  
> > <https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/>
> > [2] https://github.com/gluonhq/client-samples 
> > <https://github.com/gluonhq/client-samples>
> > [3]  https://github.com/gluonhq/substrate 
> > <https://github.com/gluonhq/substrate>
> > [4] https://github.com/gluonhq/client-maven-plugin 
> > <https://github.com/gluonhq/client-maven-plugin>
> > 
> > On Wed, Nov 20, 2019 at 10:22 PM Michael Paus  > <mailto:m...@jugs.org>> wrote:
> > 
> >> Hi,
> >> 
> >> I would just like to know where JavaFX problems or bugs should be reported
> >> which are strictly related to running on the just released GraalVM 19.3
> >> with
> >> Java 11 support. Should they go into the regular JBS or should they be
> >> reported
> >> elsewhere?
> >> 
> >> For example: I have observed that a large JavaFX application seems to work
> >> correctly at first but then suddenly all text on all controls turns
> >> white and
> >> white on white or light grey is not really readable anymore. I've never
> >> observed
> >> such a behaviour on any other VM before. There is also no error message or
> >> warning associated with this. It just happens.
> >> 
> >> There even seem to be more issues when you try to use native-image.
> >> 
> >> --Michael
> >> 
> >> 
> 

Re: JavaFX-Bugs on GraalVM 19.3 (Java 11)

[Dirk Lemmermann]

After experimenting a lot today with the Gluon client plugin I must assume that 
currently not all of Java is supported via the substrate / GraalVM duo.
For example I was unable to use the java.util.Preferences API. I also got an 
error that said Integer.parseInt() does not exist.

Is that correct?

> On 21 Nov 2019, at 18:26, Johan Vos  wrote:
> 
> We have samples showing how to build and run JavaFX applications using
> GraalVM. See our blog post [1] with samples [2].
> 
> Keep in mind that JavaFX has some characteristics that make it non-trivial
> to apply native-image out of the box (reflection/jni configuration,
> platform-specific static libraries, including resources and bundles...).
> This is why we created Gluon Substrate [3], which does most of this work:
> Developers use a maven plugin [4] (gradle will be ready soon too) and this
> is used in the samples [2].
> 
> If you use GraalVM native-image without all the parameters that Gluon
> Substrate adds, you will most likely create a "fallback-image" that still
> require a JVM and some other resources to be available at runtime, and this
> can give strange results. While I don't exclude JavaFX bugs will surface
> using this approach, I think it's more likely you're seeing issues due to
> this "mixed mode".
> 
> - Johan
> 
> [1]
> https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/
> [2] https://github.com/gluonhq/client-samples
> [3]  https://github.com/gluonhq/substrate
> [4] https://github.com/gluonhq/client-maven-plugin
> 
> On Wed, Nov 20, 2019 at 10:22 PM Michael Paus  wrote:
> 
>> Hi,
>> 
>> I would just like to know where JavaFX problems or bugs should be reported
>> which are strictly related to running on the just released GraalVM 19.3
>> with
>> Java 11 support. Should they go into the regular JBS or should they be
>> reported
>> elsewhere?
>> 
>> For example: I have observed that a large JavaFX application seems to work
>> correctly at first but then suddenly all text on all controls turns
>> white and
>> white on white or light grey is not really readable anymore. I've never
>> observed
>> such a behaviour on any other VM before. There is also no error message or
>> warning associated with this. It just happens.
>> 
>> There even seem to be more issues when you try to use native-image.
>> 
>> --Michael
>> 
>> 

Re: JavaFX-Bugs on GraalVM 19.3 (Java 11)

[Dirk Lemmermann]

I am also observing issues related to text color. All of my  labels show up in 
blue instead of the color defined globally in my css file.

> On 20 Nov 2019, at 22:20, Michael Paus  wrote:
> 
> Hi,
> 
> I would just like to know where JavaFX problems or bugs should be reported
> which are strictly related to running on the just released GraalVM 19.3 with
> Java 11 support. Should they go into the regular JBS or should they be 
> reported
> elsewhere?
> 
> For example: I have observed that a large JavaFX application seems to work
> correctly at first but then suddenly all text on all controls turns white and
> white on white or light grey is not really readable anymore. I've never 
> observed
> such a behaviour on any other VM before. There is also no error message or
> warning associated with this. It just happens.
> 
> There even seem to be more issues when you try to use native-image.
> 
> --Michael
> 

jpackage maven plugin

[Dirk Lemmermann]

Does anyone know if somebody has started work on a Maven plugin for jpackage?

Dirk

Custom Fonts in User Agent Stylesheets

[Dirk Lemmermann]

I noticed today that the custom fonts I defined in a user agent stylesheet of a 
custom control are not being used. It only started working when I “manually” 
added the stylesheet to the control via getStylesheets().add() instead of 
overriding getUserAgentStylesheet(). 

Does anyone know if this is intentional or a bug? Are there certain things that 
JavaFX does not support depending on the “type” of stylesheet?

Dirk

Changes to layout behavior?

[Dirk Lemmermann]

Hi,

I recently noticed that some of my frameworks constantly run the 
layoutChildren() method of their skins when they are being executed with Java 
11+. I assume the reason is that I am adding nodes to the scenegraph INSIDE the 
layoutChildren() method. This used to work very well, but now it causes an 
infinite loop. The controls are still responsive, but I can see high CPU and 
memory usage because of it.

Does anyone know what has changed between 8 and 11 that could have caused this 
change in behavior? 

—Dirk
jfx-days.com 

JavaFX Conference

[Dirk Lemmermann]

Hi y’all,

just a quick notice that we are having a second “JFX Days” event in Zurich on 
December 2nd - 4th (jfx-days.com ). We have sessions and 
workshops and additionally a seminar on using open source software in line with 
their licensing agreements. Johan Vos will be there and tell us about the 
OpenJFX roadmap. Bruno Borges will show us how to do CI/CD of JavaFX apps via 
the Azure pipeline, Michael Hoffer will present his new project “NativeFX” for 
native rendering / writable image, etc….

Dirk

Re: Bad DropShadow performance

[Dirk Lemmermann]

Yes, I also noticed that DropShadow causes severe performance degradation.

Dirk

> On 4 Oct 2018, at 13:10, Tom Schindl  wrote:
> 
> Hi,
> 
> Why does applying a DropShadow on a large region cause problem when
> animating nodes contained in that region?
> 
>> package fxbugs;
>> 
>> import javafx.animation.ScaleTransition;
>> import javafx.application.Application;
>> import javafx.geometry.Insets;
>> import javafx.scene.Node;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.effect.BlurType;
>> import javafx.scene.effect.DropShadow;
>> import javafx.scene.layout.BorderPane;
>> import javafx.scene.layout.GridPane;
>> import javafx.scene.paint.Color;
>> import javafx.stage.Stage;
>> import javafx.util.Duration;
>> 
>> public class DropShadowPerformance extends Application {
>> 
>>@Override
>>public void start(Stage primaryStage) throws Exception {
>>BorderPane p = new BorderPane();
>>p.setPadding(new Insets(30));
>> 
>>GridPane container = new GridPane();
>>container.setHgap(10);
>>container.setVgap(10);
>>container.setStyle("-fx-background-color: green; -fx-padding: 10;");
>>container.setEffect(new DropShadow(BlurType.GAUSSIAN, Color.rgb(0, 0, 
>> 0, 0.3), 10, 0.5, 0, 0));
>>for( int i = 0; i < 8; i++ ) {
>>for( int j = 0; j < 14; j++ ) {
>>container.add(createButton(), i, j);
>>}
>>}
>>p.setCenter(container);
>> 
>>Scene s = new Scene(p, 800, 600);
>>primaryStage.setScene(s);
>>primaryStage.show();
>>}
>> 
>>private Node createButton() {
>>Button button = new Button("hello world");
>>button.hoverProperty().addListener((ob,ol,ne) -> {
>>ScaleTransition t = new ScaleTransition(Duration.millis(500), 
>> button);
>> 
>>if( ne ) {
>>t.setFromX(1);
>>t.setFromY(1);
>>t.setToX(1.2);
>>t.setToY(1.2);
>>} else {
>>t.setFromX(1.2);
>>t.setFromY(1.2);
>>t.setToX(1);
>>t.setToY(1);
>>}
>> 
>>t.play();
>>});
>>return button;
>>}
>> 
>>public static void main(String[] args) {
>>launch(args);
>>}
>> }
> 
> 
> If you run the following application:
> * Maximize the window
> * Hover over a button (eg the one in the right lower corner)
> 
> You'll notice that the animation is not smooth, setting cache flags on
> the container does not improve the situation, nor does using a ONE_PASS_BOX.
> 
> Removing the effect on the container node "fixes" the problem.
> 
> This is on a MacBook Pro and Windows Surface both having a Intel Iris
> Plus 650 graphics card.
> 
> Tom
> 
> -- 
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

JavaFX Days Zurich

[Dirk Lemmermann]

With all this activity going on in the JavaFX space right now, I thought it is 
a good idea to inform people on this list that we are currently organizing a 
“JavaFX-Only” conference in Zurich on Dec. 3rd until Dec. 5. More info on: 
javafx-days.com 

The first day will have a beginners and an expert training class (Anton Epple, 
Hendrik Ebbers).
The second day will be filled with presentations from various JavaFX experts: 
Johan Vos, Hendrik Ebbers, Gerrit Grunwald, …. me ( ** blushing **)
The third day will be a “JavaFX on Mobile” day with a Gluon Workshop.

Hope to see you there …

Dirk

Re: JavaFX 11 is released

[Dirk Lemmermann]

Johan, Kevin,

a big "thank you!" from someone who has based his company and career on JavaFX. 
This release will put an end to all of the „JavaFX is dead“ speculations / 
rumors out there and it will hopefully also mark the beginning of ongoing and 
accelerated development of this fantastic piece of technology.

Dirk

http://www.dlsc.com 
http://javafx-days.com 


> Am 18.09.2018 um 15:08 schrieb Johan Vos :
> 
> Adding to what Kevin already said (huge thanks to Kevin and Oracle for all
> they did), I want to thank everyone on this list for being part of this
> release. The JavaFX 11 release is a huge milestone, and there are many
> people who contributed, some of them who have been working with JavaFX from
> day 1, some who just started working.
> 
> As for the site http://openjfx.io: this is something we created with Gluon,
> but we really want it to be a community-organised site. Therefore, it is
> all available via github, and open for PR's:
> https://github.com/openjfx/hugo-site.
> 
> Thanks again,
> 
> - Johan
> 
> On Tue, Sep 18, 2018 at 3:02 PM Kevin Rushforth 
> wrote:
> 
>> I am pleased to announce the final release of JavaFX 11 as well as the
>> launch of a new OpenJFX community site at:
>> 
>> http://openjfx.io/
>> 
>> The GA version of JavaFX 11 is now live and can be downloaded by going
>> to the openjfx.io site or by accessing javafx modules from maven central
>> at openjfx:javafx-COMPONENT:11 (where COMPONENT is one of base,
>> graphics, controls, and so forth).
>> 
>> This is the first standalone release of JavaFX 11. It runs with JDK 11,
>> which is available as a release candidate now and will be shipped as a
>> GA version next week, or on JDK 10 (OpenJDK build only).
>> 
>> A big thank you to all who have contributed to OpenJFX make this release
>> possible! I especially thank Johan Vos, both for taking on the role as
>> Co-Lead of the OpenJFX Project and for the work that Gluon as done to
>> build and host the JavaFX 11 release.
>> 
>> I look forward to working with you all on JavaFX 12 and beyond.
>> 
>> -- Kevin
>> 
>> 

Scroll Event Delta Values

[Dirk Lemmermann]

Hi,

I noticed in my application that the delta values of the ScrollEvent seem to be 
incorrect at the end of the scroll event sequence.
Values should first increase and then decrease: smooth-in / smooth-out style. 
But when I print out the values I noticed that at the end I receive a few 
non-linear values:

   9.91552734375
   8.30517578125
   7.0001220703125
   6.6103515625
   8.30517578125
   10.0
   10.0
   9.91552734375
   9.91552734375
   9.91552734375
   8.30517578125
   7.0001220703125
   7.0001220703125
   6.6103515625
   6.6103515625
   6.6103515625
   5.0
   5.0
   5.0
   16.6103515625< here, too big
   13.30517578125  < here, too big
   13.30517578125  < here, too big

Question: is this the intended way? I am running on a Mac.

A video showing the result can be seen here: https://youtu.be/KOEQatiCMns 


The problem with these values is that it results in „stuttering" of the 
timeline control of my app. 

—Dirk

Re: Canvas Content Shift

[Dirk Lemmermann]

I have submitted the RFE.

— Dirk

> Am 10.04.2017 um 16:54 schrieb Kevin Rushforth :
> 
> Please file an Enhancement request and we can consider this for JDK 10.
> 
> Dirk Lemmermann wrote:
>> 
>> +1 on Java 8/9 update. But I have a feeling that will be hard to accomplish.
>>   
> 
> Indeed it will be. We have a general policy against further enhancements for 
> JDK 8uNN. I suspect the same is likely for JDK 9.x, but I can't say that for 
> sure until there is a JDK 9 updates project.
> 
> -- Kevin
> 
>>   
>>> Am 10.04.2017 um 11:20 schrieb Michael Paus  
>>> <mailto:m...@jugs.org>:
>>> 
>>> I also have that on my wishlist. Actually I would like to see that in some 
>>> update release for Java 8/9 too
>>> because Java 10 is still very far away at the horizon.
>>> Michael
>>> 
>>> Am 10.04.17 um 10:32 schrieb Dirk Lemmermann:
>>> 
>>>> HI there,
>>>> 
>>>> I was wondering if there is any chance that Java 10 could implement some 
>>>> sort of „content shifting“ for the Canvas API?
>>>> 
>>>> I would love to have this feature for supporting faster horizontal 
>>>> scrolling in my Gantt Chart framework FlexGanttFX. Currently when the user 
>>>> scrolls then the entire content of each canvas in each row of the chart 
>>>> will be redrawn. This could be optimized by only drawing the time range 
>>>> that has been moved into the „viewport“ and by shifting or copying the 
>>>> remaining time range graphics. E.g. the user currently looks at one week 
>>>> and scrolls one day to the right then the data / graphics of 6 days would 
>>>> stay the same and could just be reused. Only one day worth of data would 
>>>> need to be redrawn.
>>>> 
>>>> I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport.
>>>> 
>>>> Dirk
>>>> 
>>>>   
>> 
>>   

Re: Canvas Content Shift

[Dirk Lemmermann]

+1 on Java 8/9 update. But I have a feeling that will be hard to accomplish.

> Am 10.04.2017 um 11:20 schrieb Michael Paus :
> 
> I also have that on my wishlist. Actually I would like to see that in some 
> update release for Java 8/9 too
> because Java 10 is still very far away at the horizon.
> Michael
> 
> Am 10.04.17 um 10:32 schrieb Dirk Lemmermann:
>> HI there,
>> 
>> I was wondering if there is any chance that Java 10 could implement some 
>> sort of „content shifting“ for the Canvas API?
>> 
>> I would love to have this feature for supporting faster horizontal scrolling 
>> in my Gantt Chart framework FlexGanttFX. Currently when the user scrolls 
>> then the entire content of each canvas in each row of the chart will be 
>> redrawn. This could be optimized by only drawing the time range that has 
>> been moved into the „viewport“ and by shifting or copying the remaining time 
>> range graphics. E.g. the user currently looks at one week and scrolls one 
>> day to the right then the data / graphics of 6 days would stay the same and 
>> could just be reused. Only one day worth of data would need to be redrawn.
>> 
>> I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport.
>> 
>> Dirk
>> 
> 

Canvas Content Shift

[Dirk Lemmermann]

HI there,

I was wondering if there is any chance that Java 10 could implement some sort 
of „content shifting“ for the Canvas API? 

I would love to have this feature for supporting faster horizontal scrolling in 
my Gantt Chart framework FlexGanttFX. Currently when the user scrolls then the 
entire content of each canvas in each row of the chart will be redrawn. This 
could be optimized by only drawing the time range that has been moved into the 
„viewport“ and by shifting or copying the remaining time range graphics. E.g. 
the user currently looks at one week and scrolls one day to the right then the 
data / graphics of 6 days would stay the same and could just be reused. Only 
one day worth of data would need to be redrawn.

I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport.

Dirk

Re: Planning for JavaFX.next

[Dirk Lemmermann]

I have these priorities regarding the items mentioned by Jonathan:

“Put the pedal to the metal” section:
  +1 CSS performance improvements
  +1 TableView performance
  +1 Marlin renderer enabled by default

“The rest” section:
  +1 TableView improvements (cell spanning, row / column freezing, etc)
  +1 Focus traversal API
  +1 A JavaFX equivalent of the AWT Desktop APIs

—Dirk

http://www.dlsc.com

Re: Planning for JavaFX.next

[Dirk Lemmermann]

I would like to see support in Canvas for hardware accelerated shift of its 
current content. 
Something similar to the JViewport “blitting” feature in Swing.

Dirk