Re: Initial positioning of Dialog
Scott, When you say it works for you, which java are you running? - Java 8 (1.8u25) with openjfx-dialogs-1.0.2 like Pete - Java 8 update 40 pre-release - something else? Using the released 8u25 with openjfx-dialogs-1.0.2 I, too, have seen the dialog pop on the wrong display. Neil From: Scott Palmer swpal...@gmail.com To: Pete Moss peatmos...@gmail.com, Cc: openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net Date: 11/01/2014 11:00 AM Subject:Re: Initial positioning of Dialog Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net Ah, I the controlsFX code must be doing something to position the dialog. Perhaps you can step into the code and see what it is doing. The behaviour without a owner appears to be the standard behaviour - centre on the screen. Scott On Nov 1, 2014, at 9:39 AM, Pete Moss peatmos...@gmail.com wrote: I get different behavior. I am using JavaFX 8 (1.8u25) with openjfx-dialogs-1.0.2 which is part of controlsfx-8.20.8. Here is my show code: OptionsDlg dlg = new OptionsDlg(); // where OptionsDlg extends DialogT dlg.initOwner(mainWnd.getScene().getWindow()); dlg.showAndWait(); When I set the initOwner() as shown, if the main app is in my primary display, the dlg seems to be centered on the stage, which I am happy with. However, if I move my main app into my secondary display, the dlg pops up in the center of the main display. This seems like a bug. If I comment out the line that sets initOwner(), the dlg always seems to pop up in the center of the main display, regardless of where the main app is. On Sat, Nov 1, 2014 at 9:25 AM, Scott Palmer swpal...@gmail.com wrote: I was just addressing a bug in my application related to this. The behaviour you describe happens only in Java FX 2.x. In JavaFX 8 the dialog still appears in the centre of the display, but it chooses the correct display based on where the parent window is. I ended up adding a bit of code to reposition the dialog manually, but it was a little tricky to avoid having the dialog flash at the original position first. I had to set the opacity to 0, reposition it, and then wait a bit before setting the opacity to 1. Even that was done in a couple stages with runLater. Scott On Nov 1, 2014, at 8:03 AM, Pete Moss peatmos...@gmail.com wrote: Just getting started using the new openjfx-dialogs. One thing that annoys me is the default initial positioning of a popup dialog. The default seems to pop up in the center of the primary display screen. This is particularly annoying when the app is running in my secondary display. Where's the popup? Is there an option to have it centered on the stage, or a way to manually control the initial position? I tried to handle onShowing() but at this point X, Y, width and height are NaN. Thanks. NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.
Questions about Platform.runLater() and Application.start()
Hello, Is there documentation that describes somewhere how Platform.runLater() Application.start() interact? My impression is that (roughly speaking): - there is an EventQueue (to use the Swing terminology). - the EventQueue holds both UI events (like mouse click) as well as the Runnables enqueued by runLater(). - the first (?) event put in the EventQueue is a Runnable representing Application.start(). My impression is, therefore, that any Runnables enqueued during Application.start() won't be run until after start() completes. This behavior is the same as one runLater() not interrupting another runLater(). Is this sort of stuff documented somewhere? Is this the right way to think about this part of the system? (even if the implementation is different) Are there other special things to be aware of about Application.start()? Thanks, Neil P.S. I am using javafx.concurrent.Service Task and am hitting some issues. NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.
Re: Questions about Platform.runLater() and Application.start()
Hi there, If you en-queue a runnable in start() it will not run until start() completes unless you open a dialog in start() that waits for a result before proceeding. In that case, your runnable will run. You are correct about runnables and input events being part of the input queue for the application thread. Threads are not interrupted to run code. Steve On 2014-11-03, 8:49 AM, ngalarn...@abinitio.com wrote: Hello, Is there documentation that describes somewhere how Platform.runLater() Application.start() interact? My impression is that (roughly speaking): - there is an EventQueue (to use the Swing terminology). - the EventQueue holds both UI events (like mouse click) as well as the Runnables enqueued by runLater(). - the first (?) event put in the EventQueue is a Runnable representing Application.start(). My impression is, therefore, that any Runnables enqueued during Application.start() won't be run until after start() completes. This behavior is the same as one runLater() not interrupting another runLater(). Is this sort of stuff documented somewhere? Is this the right way to think about this part of the system? (even if the implementation is different) Are there other special things to be aware of about Application.start()? Thanks, Neil P.S. I am using javafx.concurrent.Service Task and am hitting some issues. NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.
Re: Initial positioning of Dialog
Hi Pete, If this is a bug in JFX dialogs that are part of 8u40, please enter a bug report with a small but complete code example and a set of steps. Thanks, Steve On 2014-11-01, 8:03 AM, Pete Moss wrote: Just getting started using the new openjfx-dialogs. One thing that annoys me is the default initial positioning of a popup dialog. The default seems to pop up in the center of the primary display screen. This is particularly annoying when the app is running in my secondary display. Where's the popup? Is there an option to have it centered on the stage, or a way to manually control the initial position? I tried to handle onShowing() but at this point X, Y, width and height are NaN. Thanks.
8u-dev unlocked following this week's sanity testing eom
Quick look at JavaFX methods above the HotSpot inlining threshold
Hi all, As part of the JITWatch[1] project I've written a tool called JarScan which counts the bytecode size of methods in a jar and logs those methods which are above HotSpot's 325 byte size threshold for inlining methods it determines are hot. In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774 methods above the threshold which I've listed in this gist: https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2 A lot of these won't be found in hot code but perhaps the methods under com.sun.javafx.geom and javafx.scene.transform could be candidates for examination with JIT compilation in mind? Has anybody on the list done any experiments in this area? If not I'll try and find some time to see if there are any gains to be made by trimming methods (in the OpenJFX source) to fit inside the inlining threshold. Cheers, Chris @chriswhocodes [1] https://github.com/AdoptOpenJDK/jitwatch
Re: Quick look at JavaFX methods above the HotSpot inlining threshold
Hi Chris, I’ve not seen any experiments or investigation along these lines, looking forward to what you find! Richard On Nov 3, 2014, at 3:42 PM, Chris Newland cnewl...@chrisnewland.com wrote: Hi all, As part of the JITWatch[1] project I've written a tool called JarScan which counts the bytecode size of methods in a jar and logs those methods which are above HotSpot's 325 byte size threshold for inlining methods it determines are hot. In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774 methods above the threshold which I've listed in this gist: https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2 A lot of these won't be found in hot code but perhaps the methods under com.sun.javafx.geom and javafx.scene.transform could be candidates for examination with JIT compilation in mind? Has anybody on the list done any experiments in this area? If not I'll try and find some time to see if there are any gains to be made by trimming methods (in the OpenJFX source) to fit inside the inlining threshold. Cheers, Chris @chriswhocodes [1] https://github.com/AdoptOpenJDK/jitwatch
