RT-36146: request to reopen
As can be seen in the issue notes, I do not believe this issue is Not an issue and really needs to be fixed. https://javafx-jira.kenai.com/browse/RT-36146 I hope everyone concerned about the quality of font rendering on Windows with JavaFX looks at this issue and adds their comments. Felix
Re: Monocle in 8u25
Hi Sean, I've put the Monocle sources directly in my code directories for testing purposes. Putting it into a separate Jar is possible and I thought that pre-compiled jars could be provided via Maven. I didn't do a complete OpenJFX build, because I was only interested in the Headless component of Monocle, i.e. I didn't needed the platform-dependent dynamic libraries. Rough instructions were given in a previous mail. There were some request to provide the pre-compoile jars so I will additionally set up a public repository with detailed instructions when I'm back home. --Benjamin On 11/5/14, Sean True sean.t...@gmail.com wrote: Did you build the glass/ui/monocle sources into a separate jar, or did you do a complete OpenJFX build? If you did a separate build, a recipe would be extremely helpful. -- Sean On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com wrote: I managed to run Monocle/Headless on Windows with 8u25. This will allow users to run headless tests. All what is needed is to copy all files from com/sun/glass/ui/monocle of javafx-src.zip and add the cursor resource files from modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the related hg tag in the OpenJFX repository [1]. Before Application#launch() is called we need to manually set the Glass and Monocle platforms: accessStaticField(com.sun.glass.ui.PlatformFactory.class, instance, new com.sun.glass.ui.monocle.MonoclePlatformFactory()); accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, platform, new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); The directory structure in 8u40 is a bit different, but there could be added version checks. Checking for the JVM vars glass.platform and monocle.platform might be also added to this code. [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus hasteb...@gmail.com wrote: Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory won't retrieve externally defined PlatformFactorys. So I will try to set the PlatformFactory.instance field manually, before the Application/Tookit/FX-Thread is launched. On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus hasteb...@gmail.com wrote: Thank you. That makes it clearer. :) Is it possible to supply the headless part of Monocle in an external Jar for desktop platforms? As far as I know the only possibility to run TestFX tests with Hudson/Jenkins is in headless mode. TestFX's tests itself can only run with the X virtual framebuffer on Linux test clients for the Travis CI so far. So far the only advice I could give TestFX users who like to run headless tests is to use 1.8.0_20-ea-b05.
Re: Questions about Platform.runLater() and Application.start()
Steve, Thank you for that important addition. Is it true that this, also, is not a special case? In other words, is this how it works? - the input queue contains both Events and Runnables (from runLater() and the first one containing a call to Application.start()) - one item is processed from the input queue at a time - if the processing of that item does a Dialog.showAndWait(), then: - - the processing of that item is suspended (the thread blocks?) until showAndWait() returns and - - a new item processor picks the next item off of the input queue starts processing it It looks like the JavaFX Application Thread is the item processor. Neil From: Stephen F Northover steve.x.northo...@oracle.com To: ngalarn...@abinitio.com, openjfx-dev@openjdk.java.net, Date: 11/03/2014 09:58 AM Subject: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: Questions about Platform.runLater() and Application.start()
Hi Neal, You are correct. The JavaFX Application Thread is the event thread for JavaFX. It processes input events, pulses, animations, and Runnables that are submitted via runLater. Other than the special case when a nested event loop is spun up (e.g., showAndWait()) a new runnable or event will not be processed until the current one has returned to the event loop. -- Kevin ngalarn...@abinitio.com wrote: Steve, Thank you for that important addition. Is it true that this, also, is not a special case? In other words, is this how it works? - the input queue contains both Events and Runnables (from runLater() and the first one containing a call to Application.start()) - one item is processed from the input queue at a time - if the processing of that item does a Dialog.showAndWait(), then: - - the processing of that item is suspended (the thread blocks?) until showAndWait() returns and - - a new item processor picks the next item off of the input queue starts processing it It looks like the JavaFX Application Thread is the item processor. Neil From: Stephen F Northover steve.x.northo...@oracle.com To: ngalarn...@abinitio.com, openjfx-dev@openjdk.java.net, Date: 11/03/2014 09:58 AM Subject: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: Monocle in 8u25
Setting this up in a repo with instructions for the slow and the lazy :-) would be really helpful. Thank you. -- Sean On Wed, Nov 5, 2014 at 10:57 AM, Benjamin Gudehus hasteb...@gmail.com wrote: Hi Sean, I've put the Monocle sources directly in my code directories for testing purposes. Putting it into a separate Jar is possible and I thought that pre-compiled jars could be provided via Maven. I didn't do a complete OpenJFX build, because I was only interested in the Headless component of Monocle, i.e. I didn't needed the platform-dependent dynamic libraries. Rough instructions were given in a previous mail. There were some request to provide the pre-compoile jars so I will additionally set up a public repository with detailed instructions when I'm back home. --Benjamin On 11/5/14, Sean True sean.t...@gmail.com wrote: Did you build the glass/ui/monocle sources into a separate jar, or did you do a complete OpenJFX build? If you did a separate build, a recipe would be extremely helpful. -- Sean On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com wrote: I managed to run Monocle/Headless on Windows with 8u25. This will allow users to run headless tests. All what is needed is to copy all files from com/sun/glass/ui/monocle of javafx-src.zip and add the cursor resource files from modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the related hg tag in the OpenJFX repository [1]. Before Application#launch() is called we need to manually set the Glass and Monocle platforms: accessStaticField(com.sun.glass.ui.PlatformFactory.class, instance, new com.sun.glass.ui.monocle.MonoclePlatformFactory()); accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, platform, new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); The directory structure in 8u40 is a bit different, but there could be added version checks. Checking for the JVM vars glass.platform and monocle.platform might be also added to this code. [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus hasteb...@gmail.com wrote: Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory won't retrieve externally defined PlatformFactorys. So I will try to set the PlatformFactory.instance field manually, before the Application/Tookit/FX-Thread is launched. On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus hasteb...@gmail.com wrote: Thank you. That makes it clearer. :) Is it possible to supply the headless part of Monocle in an external Jar for desktop platforms? As far as I know the only possibility to run TestFX tests with Hudson/Jenkins is in headless mode. TestFX's tests itself can only run with the X virtual framebuffer on Linux test clients for the Travis CI so far. So far the only advice I could give TestFX users who like to run headless tests is to use 1.8.0_20-ea-b05.
Re: Monocle in 8u25
This is extremely good news. I have no problem to drag that library along in the JFXtras project (project name seems to be a good match for this usage ;-) and release it to maven - if that is allowed by the JavaFX license. Tom On 5-11-2014 16:57, Benjamin Gudehus wrote: Hi Sean, I've put the Monocle sources directly in my code directories for testing purposes. Putting it into a separate Jar is possible and I thought that pre-compiled jars could be provided via Maven. I didn't do a complete OpenJFX build, because I was only interested in the Headless component of Monocle, i.e. I didn't needed the platform-dependent dynamic libraries. Rough instructions were given in a previous mail. There were some request to provide the pre-compoile jars so I will additionally set up a public repository with detailed instructions when I'm back home. --Benjamin On 11/5/14, Sean True sean.t...@gmail.com wrote: Did you build the glass/ui/monocle sources into a separate jar, or did you do a complete OpenJFX build? If you did a separate build, a recipe would be extremely helpful. -- Sean On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com wrote: I managed to run Monocle/Headless on Windows with 8u25. This will allow users to run headless tests. All what is needed is to copy all files from com/sun/glass/ui/monocle of javafx-src.zip and add the cursor resource files from modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the related hg tag in the OpenJFX repository [1]. Before Application#launch() is called we need to manually set the Glass and Monocle platforms: accessStaticField(com.sun.glass.ui.PlatformFactory.class, instance, new com.sun.glass.ui.monocle.MonoclePlatformFactory()); accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, platform, new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); The directory structure in 8u40 is a bit different, but there could be added version checks. Checking for the JVM vars glass.platform and monocle.platform might be also added to this code. [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus hasteb...@gmail.com wrote: Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory won't retrieve externally defined PlatformFactorys. So I will try to set the PlatformFactory.instance field manually, before the Application/Tookit/FX-Thread is launched. On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus hasteb...@gmail.com wrote: Thank you. That makes it clearer. :) Is it possible to supply the headless part of Monocle in an external Jar for desktop platforms? As far as I know the only possibility to run TestFX tests with Hudson/Jenkins is in headless mode. TestFX's tests itself can only run with the X virtual framebuffer on Linux test clients for the Travis CI so far. So far the only advice I could give TestFX users who like to run headless tests is to use 1.8.0_20-ea-b05.
