hg: openjfx/8u-dev/rt: {IDE ONLY] Fix IDE files for Eclipse, NetBeans and IntelliJ
Changeset: 65b41355c1af
Author:snorthov
Date: 2014-09-11 10:19 -0400
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/65b41355c1af
{IDE ONLY] Fix IDE files for Eclipse, NetBeans and IntelliJ
! .idea/fxpackager.iml
! modules/fxpackager/.classpath
! netbeans/fxpackager/nbproject/build-impl.xml
! netbeans/fxpackager/nbproject/genfiles.properties
! netbeans/fxpackager/nbproject/project.properties
! netbeans/fxpackager/nbproject/project.xml
hg: openjfx/8u-dev/rt: [Javadoc only] Reword a11y enum documentation
Changeset: 5e4e957c51a6 Author:snorthov Date: 2014-08-15 14:36 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5e4e957c51a6 [Javadoc only] Reword a11y enum documentation ! modules/graphics/src/main/java/javafx/scene/AccessibleAction.java ! modules/graphics/src/main/java/javafx/scene/AccessibleAttribute.java ! modules/graphics/src/main/java/javafx/scene/AccessibleRole.java
hg: openjfx/8u-dev/rt: [Javadoc only] Fix type and replace etc with and others
Changeset: 971100792fac Author:snorthov Date: 2014-08-15 15:14 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/971100792fac [Javadoc only] Fix type and replace etc with and others ! modules/graphics/src/main/java/javafx/scene/AccessibleAttribute.java
hg: openjfx/8u-dev/rt: [Javadoc only] Reword Node a11y doc
Changeset: 971ac7490e25 Author:snorthov Date: 2014-08-15 15:15 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/971ac7490e25 [Javadoc only] Reword Node a11y doc ! modules/graphics/src/main/java/javafx/scene/Node.java
hg: openjfx/8u-dev/rt: ECLIPSE ONLY: fix .classpath
Changeset: a78fabe3d66a Author:snorthov Date: 2014-07-10 14:35 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a78fabe3d66a ECLIPSE ONLY: fix .classpath ! modules/jmx/.classpath
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: 6ade29ec8e2c Author:snorthov Date: 2014-06-24 15:08 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6ade29ec8e2c INTELLIJ ONLY: fix project files to use tests instead of rt-tests ! .idea/modules.xml ! .idea/rt-closed.iml - .idea/rt-tests.iml + .idea/tests.iml Changeset: e656dca9963e Author:snorthov Date: 2014-06-24 15:08 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e656dca9963e ECLIPSE ONLY: fix project files to use tests instead of rt-tests ! .project
hg: openjfx/8u-dev/rt: ECLIPSE ONLY: fix project files to use tests instead of rt-tests
Changeset: 55cd83185bb8 Author:snorthov Date: 2014-06-24 15:41 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/55cd83185bb8 ECLIPSE ONLY: fix project files to use tests instead of rt-tests ! tests/.project
hg: openjfx/8u-dev/rt: ECLIPSE ONLY: restore project file of rt
Changeset: 4fd65ab4dff8 Author:snorthov Date: 2014-06-24 15:43 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4fd65ab4dff8 ECLIPSE ONLY: restore project file of rt ! .project
Re: Enabling Glass thread checks
It's the JavaFX Application Thread. We tend to use the term event thread and UI thread to indicate that the thread is a distinguished UI thread that processes operating system events by running an event loop. Steve On 04/10/2013 2:45 PM, John Smith wrote: IllegalStateException(This operation is permitted on the event thread only) What is the event thread? Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): Exception in thread AWT-EventQueue-0 java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: JavaFX Application Thread The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: JavaFX application thread: This is the primary thread used by JavaFX application developers. Any live scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Petr Pchelko Sent: Friday, October 04, 2013 1:40 AM To: OpenJFX list Subject: Enabling Glass thread checks Hello, OpenJFX. FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. The following exception would mean that you've hit a thread check: IllegalStateException(This operation is permitted on the event thread only). In that case please check your threading and if everything seems correct - please contact the Glass team. Thank you. With best regards. Petr.
Re: Enabling Glass thread checks
We are BAD. It should really be FX Application Thread but the GUI, event nature of the thread is critical to what it is. That's why the terms keep getting added. Steve On 04/10/2013 3:36 PM, Richard Bair wrote: Ya, event thread, fx thread, ui thread, app thread, FX Application thread --- they're all the same thing. It would be better if we settled on one name. Richard On Oct 4, 2013, at 12:00 PM, steve.x.northo...@oracle.com wrote: It's the JavaFX Application Thread. We tend to use the term event thread and UI thread to indicate that the thread is a distinguished UI thread that processes operating system events by running an event loop. Steve On 04/10/2013 2:45 PM, John Smith wrote: IllegalStateException(This operation is permitted on the event thread only) What is the event thread? Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): Exception in thread AWT-EventQueue-0 java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: JavaFX Application Thread The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: JavaFX application thread: This is the primary thread used by JavaFX application developers. Any live scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Petr Pchelko Sent: Friday, October 04, 2013 1:40 AM To: OpenJFX list Subject: Enabling Glass thread checks Hello, OpenJFX. FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. The following exception would mean that you've hit a thread check: IllegalStateException(This operation is permitted on the event thread only). In that case please check your threading and if everything seems correct - please contact the Glass team. Thank you. With best regards. Petr.
Re: Bounds constructor validation
If not already up to date, we should update the Javadoc so that we don't have the conversation again. Steve On 01/10/2013 8:59 PM, Joseph Andresen wrote: Kevin and I had this exact conversation years ago. I believe our answer was that anything less than 0 meant uninitialized? Maybe he can remember better than I. -Joe On Oct 1, 2013, at 4:32 PM, Richard Bair richard.b...@oracle.com wrote: I see this is not going to work, since isEmpty() defines itself as where one component's max (maxX, maxY, maxZ) is less than the corresponding min. So we make sense, at least, out of -1 (although as far as the implementation is concerned, any negative value works just as well). On Oct 1, 2013, at 3:13 PM, Richard Bair richard.b...@oracle.com wrote: Hi, I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the argument is made that the width / height of a node (specifically, a Region's prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never be negative. While looking at this, I noticed that in Node, the prefWidth method relies on the layoutBounds.getWidth(). However, the Bounds class itself does not appear to do any validation of the parameters passed to the Bounds. There are no checks for NaN, and no checks for negative width, height, depth. Is there any reason why we should allow NaN, or negative width / height / depth for Bounds? Richard
com.sun.prism.tkal.Window
Hi FX developers, The class com.sun.prism.tkal.Window seems to have no references. Speak now if you know anybody who uses it, otherwise it will get deleted. Steve
Re: com.sun.prism.tkal.Window
.. going once ... Steve On 01/10/2013 1:42 PM, Artem Ananiev wrote: On 10/1/2013 8:27 PM, steve.x.northo...@oracle.com wrote: Hi FX developers, The class com.sun.prism.tkal.Window seems to have no references. Speak now if you know anybody who uses it, otherwise it will get deleted. This package was introduced as abstraction between Newt and Glass, so it's obsolete now. +1 to remove. Thanks, Artem Steve
Re: How to raise JavaFX iOS bugs?
On 08/08/2013 6:08 PM, Daniel Zwolenski wrote: No, I didn't get a chance. Probably easier for you to just raise it now? See https://javafx-jira.kenai.com/browse/RT-32237 It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
Re: Canvas blowing up (was Re: JavaFX Media issues)
This is a great idea. We should just enter a tweak and do it. If the area that is being cleared is larger than the current size of the canvas, we can throw away all pending draw commands. Steve On 09/08/2013 11:23 AM, Richard Bair wrote: I mean, it looks like it is working for a few seconds, but then as the memory fills with the Canvas backlog it can lead to the GC using a lot more CPU, thus reducing the ability for Canvas to process its command queue even further, well it just collapses in on itself and dies. Forking the thread. The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. BUT, if you issue a command to the canvas which will cause it to clear all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a clear method which is clearRect(0, 0, w, h) to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. If you're making use of manually operated dirty rects so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of liveness and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. Richard
Re: Canvas blowing up (was Re: JavaFX Media issues)
We would still do the fill but we could throw away any buffered commands that happened before the fill. Steve On 09/08/2013 12:16 PM, Dr. Michael Paus wrote: What would be the performance penalty for using this quick-fix? The clear/fill commands do not just clear the command buffer. They also fill the canvas area with a certain color. So in normal operation the canvas is always filled twice for each frame, isn't it? Am 09.08.13 17:23, schrieb Richard Bair: I mean, it looks like it is working for a few seconds, but then as the memory fills with the Canvas backlog it can lead to the GC using a lot more CPU, thus reducing the ability for Canvas to process its command queue even further, well it just collapses in on itself and dies. Forking the thread. The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. BUT, if you issue a command to the canvas which will cause it to clear all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a clear method which is clearRect(0, 0, w, h) to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. If you're making use of manually operated dirty rects so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of liveness and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. Richard
Re: How to raise JavaFX iOS bugs?
Please keep filing any bugs you see and add me to the watch list. I do run RoboVM and am able to test there. Thanks, Steve On 09/08/2013 1:54 PM, Daniel Zwolenski wrote: Is there going to be an answer on what JVM is going to be used for the JavaOne iOS demo? I'd also like to know what JVM you are testing on for these fixes? On 10/08/2013, at 12:46 AM, steve.x.northo...@oracle.com wrote: On 08/08/2013 6:08 PM, Daniel Zwolenski wrote: No, I didn't get a chance. Probably easier for you to just raise it now? See https://javafx-jira.kenai.com/browse/RT-32237 It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
Re: Glass thread checks
To give a little more context. JavaFX is apartment threaded with well documented rules for threaded. These rules were not enforced in code. Glass, the low level window component for FX is not enforcing apartment threading. Since Glass has no public API, the only way that an application can be affected is if it is coded such that it access Glass through FX from a non-UI thread. FX itself contained code some code that did this this code has been fixed. Thread checking is goodness and leads to consistent applications with repeatable behavior. Thread checking in Glass is a good first step forward in this area. Steve On 08/08/2013 9:33 AM, Petr Pchelko wrote: Hello, OpenJFX Team. As you know, the previous attempt to switch on the thread checks have failed. The problems were fixed, so I'm going to enable them again tomorrow morning if nobody objects. With best regards. Petr.
Re: Glass thread checks
Heavens .. typos! To give a little more context. JavaFX is apartment threaded with well documented rules for threading. These rules were not enforced in code. Glass, the low level window component for FX is now enforcing apartment threading for this component. Since Glass has no public API, the only way that an application can be affected is if it is coded such that it accesses Glass through FX from a non-UI thread. FX itself contained code some code that did this this code has been fixed. Thread checking is goodness and leads to consistent applications with repeatable behavior. Thread checking in Glass is a good first step forward towards finding and addressing thread bugs. Steve On 08/08/2013 9:48 AM, steve.x.northo...@oracle.com wrote: To give a little more context. JavaFX is apartment threaded with well documented rules for threaded. These rules were not enforced in code. Glass, the low level window component for FX is not enforcing apartment threading. Since Glass has no public API, the only way that an application can be affected is if it is coded such that it access Glass through FX from a non-UI thread. FX itself contained code some code that did this this code has been fixed. Thread checking is goodness and leads to consistent applications with repeatable behavior. Thread checking in Glass is a good first step forward in this area. Steve On 08/08/2013 9:33 AM, Petr Pchelko wrote: Hello, OpenJFX Team. As you know, the previous attempt to switch on the thread checks have failed. The problems were fixed, so I'm going to enable them again tomorrow morning if nobody objects. With best regards. Petr.
Re: How to raise JavaFX iOS bugs?
Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
Re: Thread checks in Glass
The first part of the checking is being done at the Glass level. More checking is under consideration but making native calls from the wrong thread can cause crashes and these are the most important things to fix first. Steve On 22/07/2013 12:08 PM, Pedro Duque Vieira wrote: You mean like checking every possible call to ensure it is made in the UI thread? Or just some? I think this is great! Regards, Hello all, FX is a single threaded UI toolkit. Well written FX applications should not access FX objects from outside the UI thread. There are exceptions to this rule and these are well documented. Documentation is great, but enforcing thread checks in code is better. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. This is goodness. Many threading issues in FX, Quantum and Prism have been found and fixed as a result of this change. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 Petr Steve
Re: [API Review]: Node validation
I don't agree. It's pretty clear that when you call applyCSS(), then CSS is applied. The rest of the JFX API works exactly as expected and as documented. The programmer has precise control over what happens, when it happens and where it happens. Can you summarize what validate does? Is it sent to a leaf or the root node or does it matter? Steve On 12/07/2013 6:36 AM, Martin Sladecek wrote: What you suggest would be quite hard to use. Actually I think most of the developers will not know how to use it properly in order to get the right measurement. Simple validate call would be more convenient and less error-prone. -Martin On 07/12/2013 12:02 AM, steve.x.northo...@oracle.com wrote: I don't think I understand the answer. Are you saying that what we are suggesting is wrong conceptually or hard to implement or ...? Steve On 11/07/2013 1:23 PM, Martin Sladecek wrote: No, I will change the dirty roots to dirty flags on every node. With them, it's possible to use it the way you suggest (applyCSS layout on nearest layout root), but it's much more convenient if we could identify the layout root of the subtree and apply the layout from there downwards. I think it's something most of the usecases would want (SB, snapshot) but it's not that simple to identify layout root (we have private flag for that in every Node, so internally it's just one boolean check). -Martin On 07/11/2013 05:15 PM, Richard Bair wrote: This might work for CSS, but won't for layout. The second example won't work because you'd just do layout of the node itself. It might get a different size from it's parent during the next layout pass (and the parent from it's parent, etc...). So the layout will look different after the next pulse. This is why we need more than layout() call and it's not just about adding the CSS. If I understand properly this would be the correct behavior. If I ask a subtree of nodes to layout after setting the size of the subtree root, then go farther up the tree to an ancestor, ensure the ancestor has a size and layout again, the original subtree might be layed out differently and I would expect that. If I need to take a snapshot of a child and it has to be in context of the entire tree, I do CC in the root, force layout in the root and then take a snapshot of the child. That was what I was thinking as well, I don't understand why we have to do more than provide a way to apply CSS in order to satisfy all the use cases? Note that the old implementation (with lists of dirty roots on the Scene, or is this still the way we do it?) might be problematic here, I don't know, but from an API point of view, it seems like this is exactly what you want. Richard
Re: [API Review]: Node validation
I don't think I understand the answer. Are you saying that what we are suggesting is wrong conceptually or hard to implement or ...? Steve On 11/07/2013 1:23 PM, Martin Sladecek wrote: No, I will change the dirty roots to dirty flags on every node. With them, it's possible to use it the way you suggest (applyCSS layout on nearest layout root), but it's much more convenient if we could identify the layout root of the subtree and apply the layout from there downwards. I think it's something most of the usecases would want (SB, snapshot) but it's not that simple to identify layout root (we have private flag for that in every Node, so internally it's just one boolean check). -Martin On 07/11/2013 05:15 PM, Richard Bair wrote: This might work for CSS, but won't for layout. The second example won't work because you'd just do layout of the node itself. It might get a different size from it's parent during the next layout pass (and the parent from it's parent, etc...). So the layout will look different after the next pulse. This is why we need more than layout() call and it's not just about adding the CSS. If I understand properly this would be the correct behavior. If I ask a subtree of nodes to layout after setting the size of the subtree root, then go farther up the tree to an ancestor, ensure the ancestor has a size and layout again, the original subtree might be layed out differently and I would expect that. If I need to take a snapshot of a child and it has to be in context of the entire tree, I do CC in the root, force layout in the root and then take a snapshot of the child. That was what I was thinking as well, I don't understand why we have to do more than provide a way to apply CSS in order to satisfy all the use cases? Note that the old implementation (with lists of dirty roots on the Scene, or is this still the way we do it?) might be problematic here, I don't know, but from an API point of view, it seems like this is exactly what you want. Richard
JDK 8 for ARM Early Access Releases (with JavaFX)
JDK 8 for ARM hard float is now part of the regular JDK 8 Early Access releases. You can get it athttps://jdk8.java.net/download.html; this page will be regularly updated with new builds. As in the previous Early Access release, this includes JavaFX for the Raspberry Pi. Daniel
Re: [API Review]: Node validation
Hi Martin, How about exposing the concept of applying CCS to the programmer? Let's say we add applyCSS() that does exactly what it says (applies CSS when called). Here are a few use cases: 1) Positioning a popup: node.applyCSS() node.autosize(); // width and height are now valid node.applyCSS(); // pref width and height are now valid 2) Taking a snapshot: node.applyCSS(); node.autosize(); node. layout() // take the snapshot (when talking multiple snapshots, don't need to reapply CSS) 3) Find the location of a child control: node.applyCSS(); node.autosize(); node.layout(); // find the child control by id, the bounds are valid Richard had talked about applying the CSS automatically so that when you ask for the width etc., if the width is not calculated, it gets calculated and returned. There is nothing in the applyCSS() API the precludes us from writing this automatic code in the future. In that case, applyCSS() would become a hint or a no-op. Steve On 10/07/2013 2:50 AM, Martin Sladecek wrote: +1 -Martin On 07/09/2013 05:06 PM, Pavel Safrata wrote: To me this sounds best so far. Perhaps updateVisuals() would be even better? Pavel On 8.7.2013 18:45, Scott Palmer wrote: validateVisuals() ? Or something with the word visual as it combines layout and other CSS information. Scott On Mon, Jul 8, 2013 at 12:31 PM, Richard Bair richard.b...@oracle.comwrote: OK, just throwing something wild out there. Right now we have a layout pass and a css pass. Can they be combined? Can we combine them just into something that happens during layout? And can the existing layout() method be the thing that kicks it all off? Wild and crazy but just throwing it out there (personally I'm uncomfortable conflating CSS and layout as I believe there will be use cases to do one and not the other at times). Richard On Jul 8, 2013, at 9:27 AM, Scott Palmer swpal...@gmail.com wrote: Since CSS is implicitly tied to layout, validateLayout() seems to be enough. I don't like verify or check - To me, these imply a method that is doing checks only and not changing state. A verify method would be something that returns a boolean or throws an exception. Scott On Mon, Jul 8, 2013 at 9:07 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.com wrote: just my suggestions: validation is a side effect free concept. but your validate contains css layout processing for Node, so validate is very poor name in this case. May be better use computeBounds instead. But alternates for validate( if method is a side effect free): verify() verfifyNode() verifyBounds() checkNode() checkBounds() best Regards Ali Ebrahimi On Mon, Jul 8, 2013 at 4:50 PM, Martin Sladecek martin.slade...@oracle.comwrote: The plan is to have a final validate() method. Anyway, does anybody have a better suggestion? The validate should do both CSS and layout and I would like to avoid method name that's too descriptive (like validateLayoutAndCSS()) if possible. I think the most important thing about the method is that it validates the bounds/metrics of the Node, so maybe validateBounds() ? -Martin On 07/08/2013 01:52 PM, Anthony Petrov wrote: +1 The validate()/isValid() in AWT/Swing are often overridden by user apps for tasks that have nothing to do with the layout. And this causes a lot of problems. -- best regards, Anthony On 07/08/13 15:20, Pavel Safrata wrote: Hello, one more discussion topic: perhaps the validate name is too general? Maybe we can come up with more descriptive name? There are all kinds of nodes and sometimes this name can be misleading (not ringing the layout bell at all). For example TextField.validate() may look like validating the input. Also I wouldn't be surprised if users run into problems with custom nodes having their validate methods for different purposes. Pavel On 3.7.2013 14:33, Martin Sladecek wrote: Hi, JIRA: https://javafx-jira.kenai.com/**browse/RT-31133 https://javafx-jira.kenai.com/browse/RT-31133 I propose a single method public final void validate() to be added to Node class. The validate method would ensure that the metrics (layout bounds) of the Node are valid with regards to the current scenegraph (CSS layout). Together with this change, Parent.layout() will be deprecated. In my current implementation, validate() method works only if the Node is in a Scene. To make it work without a Scene, we'd need to do do some small adjustments to CSS (doesn't work with getScene() == null). But I'm not sure if such feature would be useful. Regards, -Martin
Re: iOS: current state of RoboVM 0.0.2 + latest gradle based OpenJFX on iOS
Hi Tobias, CoreText has been supported on iOS since 3.2. The code that is released was compiled and tested on OS X only but most of it should be applicable to iOS. I have not investigated the differences between CoreText on iOS and on OS X to find out where the rough edges are but the code should be close. Nobody has really tried it much except Felipe so I'll let him provide the details. I can confirm that coretext.c is wired into the gradle build and that uncommenting the #if will compile the source and get compile errors on iOS. There is a bug in the gradle incremental compiler for native code () so you will need this line to make sure your changes to native files get picked up: gradle -PCOMPILE_TARGETS=ios clean sdk I suggest we use this list to coordinate. Steve On 03/07/2013 5:31 AM, Tobias Bley wrote: Hi, I tried to use the latest gradle based OpenJFX on iOS using RoboVM. Current state: it fails: The reason why is the font rendering using CoreText which currently is not possible on iOS. Take a look here: coretext.c = #if TARGET_OS_MAC !(TARGET_OS_IPHONE) The alternative would be to use the T2K renderer, which is not available in OpenJFX. So currently we have to wait for an implementation of CoreText native code on iOS. Best regards, Tobi
Re: iOS: current state (Read: Who is Oracle's CoreText Guy?) :)
Hi all, Felipe Heidrich is the text guy. The focus has been on getting native text rendering working first on the desktop. That said, the code was written with iOS in mind and should not be far away. I suggest that you enter a JIRA to track the work. People who are interested in tracking the work and contributing patches can coordinate in the JIRA and on this list. Thanks, Steve On 03/07/2013 8:35 AM, cogmission1 . wrote: Hi, Respectfully, does anyone know who this is? And is a statement of the status of his work, possible? Burning ears would like to know :) Thanks, David On Wed, Jul 3, 2013 at 7:30 AM, Tobias Bley t...@ultramixer.com wrote: I don’t know what Oracle is doing We need a statement from the guy from Oracle who is working on the CoreText support for Mac / iOS... Am 03.07.2013 um 14:26 schrieb cogmission1 . cognitionmiss...@gmail.com: Hi, Is that being worked on or did we just hit a brick wall? David On Wed, Jul 3, 2013 at 4:31 AM, Tobias Bley t...@ultramixer.com wrote: Hi, I tried to use the latest gradle based OpenJFX on iOS using RoboVM. Current state: it fails: The reason why is the font rendering using CoreText which currently is not possible on iOS. Take a look here: coretext.c = #if TARGET_OS_MAC !(TARGET_OS_IPHONE) The alternative would be to use the T2K renderer, which is not available in OpenJFX. So currently we have to wait for an implementation of CoreText native code on iOS. Best regards, Tobi
Re: iOS: current state of RoboVM 0.0.2 + latest gradle based OpenJFX on iOS
You can change the includes to match iOS as follows: //#import ApplicationServices/ApplicationServices.h #import CoreGraphics/CoreGraphics.h #import CoreText/CoreText.h I can confirm that changing the includes compiles the code but the gradle build for iOS is shifting under out feet. I would let the dust setting for a few days and keep an eye on JIRA to track progress: https://javafx-jira.kenai.com/browse/RT-31420 Steve On 03/07/2013 9:11 AM, Tobias Bley wrote: Hi Steve, thanks for your answer. Yes I tried to replace the #if statement by „#if 1“ to compile the native code but it failed with several native errors. The main problem is that the ApplicationServices.framework used by coretext.c is only available on MacOSX but not on iOS SDK... Tobi Am 03.07.2013 um 14:32 schrieb steve.x.northo...@oracle.com: Hi Tobias, CoreText has been supported on iOS since 3.2. The code that is released was compiled and tested on OS X only but most of it should be applicable to iOS. I have not investigated the differences between CoreText on iOS and on OS X to find out where the rough edges are but the code should be close. Nobody has really tried it much except Felipe so I'll let him provide the details. I can confirm that coretext.c is wired into the gradle build and that uncommenting the #if will compile the source and get compile errors on iOS. There is a bug in the gradle incremental compiler for native code () so you will need this line to make sure your changes to native files get picked up: gradle -PCOMPILE_TARGETS=ios clean sdk I suggest we use this list to coordinate. Steve On 03/07/2013 5:31 AM, Tobias Bley wrote: Hi, I tried to use the latest gradle based OpenJFX on iOS using RoboVM. Current state: it fails: The reason why is the font rendering using CoreText which currently is not possible on iOS. Take a look here: coretext.c = #if TARGET_OS_MAC !(TARGET_OS_IPHONE) The alternative would be to use the T2K renderer, which is not available in OpenJFX. So currently we have to wait for an implementation of CoreText native code on iOS. Best regards, Tobi
Re: JavaFX8 on iPhone! It works!
Woot! Tobi, did you want to attach a patch to https://javafx-jira.kenai.com/browse/RT-31420 ? This would be much appreciated. Thanks, Steve On 03/07/2013 12:16 PM, John Moxley wrote: Congratulations Jack On 3 Jul 2013, at 17:03, Tobi t...@ultramixer.com wrote: It works! Latest JavaFX 8 (gradle based) with RoboVM on a real iPhone with native text rendering and JFX CSS rendering! Tobi
Moving to Gradle (finally)
Hello OpenJFX, It's no secret that we have been moving our build to gradle and reorganizing our source tree at the same time. Well, the time has come. If all goes according to plan, we will have moved to the gradle build starting this Friday morning. As part of a push to make developing for OpenJFX as easy as possible, we are working to support both command line and IDE developers better than we have before. Gradle builds are faster than our old build system and much more flexible. Many FX committers use an IDE and we are working to support your IDE of choice. We will be updating these instructions as soon as possible: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX If you have outstanding changes against the current build and source tree structure, you will need to update them when the build changes. We are hoping that the workspace reorganization and the new gradle build will make it much easier for everybody to be able to build test with JavaFX. This is just a step along that path. Additional work includes reorganizing all of the tests (white-box unit tests, black box functional tests, manual tests), integrating in the SQE tests, further code refactoring, updating the Wiki to refer to the different functional components, adding FindBugs and CheckStyle, adding code coverage analysis, exposing continuous builds on a binary repository, and so on. Lots more to do. Thanks Steve Richard
Re: Moving to Gradle (finally)
We are likely to be in flux for the rest of this week. Friday is the switch but he dust will have settled by Monday so that would be a good time to try things out. Of course, Monday is Canada Day so I will be eating pancakes with maple syrup, frying bacon, enjoying free health care, drinking beer and saying Eh. Steve On 25/06/2013 2:19 PM, Kevin Rushforth wrote: You cannot run gradle in the rt repo just yet. For now (i.e., until the switch to gradle with the accompanying repo reorg), you must run the generator.gradle script which reorganizes the repo to its new layout, and puts it, by default, in ../javafx Among other things it copies gradleBuildSrc to buildSrc but also copies the multiple mini projects (javafx-ui-common, javafx-ui-controls, prism-*, etc) to their new locations under modules/** -- Kevin Mario Torre wrote: On Tue, 2013-06-25 at 13:10 -0400,steve.x.northo...@oracle.com wrote: Hello OpenJFX, We are hoping that the workspace reorganization and the new gradle build will make it much easier for everybody to be able to build test with JavaFX. Hello Steve, Speaking of gradle, I have: [org.gradle.BuildExceptionReporter] A problem occurred evaluating root project 'rt'. [org.gradle.BuildExceptionReporter] Could not read script '/home/neugens/work_space/jdk/openjfx/master/rt/buildSrc/linux.gradle' as it does not exist. There is actually a linux.gradle, but it's in gradleBuildSrc: ./gradleBuildSrc/linux.gradle If I change all the occurrences of buildSrc to be gradleBuildSrc in the build file, I can get to this: [org.gradle.BuildExceptionReporter] * What went wrong: [org.gradle.BuildExceptionReporter] A problem occurred evaluating root project 'rt'. [org.gradle.BuildExceptionReporter] Could not find property 'JavaHeaderTask' on root project 'rt'. Any idea of what I may do wrong? Cheers, Mario
Re: Moving to Gradle (finally)
On 25/06/2013 4:20 PM, Mario Torre wrote: On Tue, 2013-06-25 at 15:14 -0400, steve.x.northo...@oracle.com wrote: We are likely to be in flux for the rest of this week. Right :) ] * What went wrong: 22:04:10.761 [ERROR] [org.gradle.BuildExceptionReporter] Could not resolve all dependencies for configuration ':graphics:compile'. 22:04:10.761 [ERROR] [org.gradle.BuildExceptionReporter] Could not find :plugin:. 22:04:10.762 [ERROR] [org.gradle.BuildExceptionReporter] Required by: 22:04:10.762 [ERROR] [org.gradle.BuildExceptionReporter] javafx:graphics:unspecified 22:04:10.791 [ERROR] [org.gradle.BuildExceptionReporter] The good news is that: gradle eclipse worked :) It is almost certain that we will not make use of the IDE support for gradle on the first go round. There are many moving part and it is critical that people be able to work right away after the switch over. The IDE's *worked* but there were issues with proxies, builds going away for a long time, strange exceptions etc. We'll revisit this after everyone is back working again. Well, importing the project basically nuked my Eclipse, but this is something I expected from Eclipse, nevertheless, it was able to import it before being stuck in a perennial compilation. Anyway, the ant build works fine. It is, however, still not able to compile itself: com.sun.javafx.accessible.providers.AccessibleProvider I though this was already released though (or I just misread some mails)? However, the big news is that running a JavaFX app seems to go way beyond what was possible just few weeks ago: Caused by: java.lang.ClassNotFoundException: com.sun.javafx.font.PrismFontLoader at java.net.URLClassLoader$1.run(URLClassLoader.java:365) at java.net.URLClassLoader$1.run(URLClassLoader.java:354) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:353) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 12 more I guess the font code didn't yet hit the main repository right? I'm waiting forward for it! By Monday we will ensure that contributors and committers can build and work in the open. It'll be a bit rough, but we'll all be better for it. Friday is the switch but he dust will have settled by Monday so that would be a good time to try things out. Of course, Monday is Canada Day so I will be eating pancakes with maple syrup, frying bacon, enjoying free health care, drinking beer and saying Eh. Eh! Enjoy it! Will also be patting beavers and playing hockey all day. Cheers, Mario
Re: JavaFX graphics performance and suitability for advanced animations
Hi John, Let's get very specific. Can you post a small example where the animation performs poorly? Then we can all get to the bottom of it. Thanks, Steve On 31/05/2013 8:30 AM, John C. Turnbull wrote: Hi Richard, Let me start by saying that on re-reading my last post I realised that it had a tone which was not intended and may have appeared overly critical or negative. If you or anyone on the JavaFX development team were offended in any way then I am sorry. All I can say in my defence was that it was posted after midnight at the end of a very long day... Anyway, I want you to know that I am not here to engage in gratuitous JavaFX bashing or trolling. In fact, I am one of the strongest supporters and proponents of JavaFX that there is. I am in the process of bringing JavaFX into my (large corporate) workplace and am involved in a private project which I take very seriously that will also be using JavaFX. Consequently I have more at stake and more interest in having JavaFX succeed than most. If everything goes according to plan, I will be focussing on Java and especially JavaFX for the next 10 years or so. From my perspective it is important to address the features or issues with JavaFX that the competitors perceive as weaknesses and reasons why the technology is a dead duck. The JavaFX community is vibrant with many well-known evangelists who are doing a very good job of promoting JavaFX and highlighting its many benefits but it is rare for them to say anything negative about it. Is this because there are no negatives with JavaFX or is just that they steer clear of them? I tend to think that they prefer to concentrate on the pros rather than the cons and that's fair enough, they are there to further the cause of JavaFX rather than detract from it. I am someone who has been told tends to say the things that other people think but are afraid to say. I am not out to win any popularity contests and will call a spade a spade. As I said, when it comes to JavaFX, I am doing this because we need a balanced argument that confronts the opposition head on. Many of the criticisms levelled at JavaFX by competitors have a valid foundation and as community we need to be able to respond to them. The issues I highlighted in my last post are real and I very much believe that if solutions are not found then JavaFX is going to struggle in the real world in the longer term. The market for graphics toolkits and cross-platform developer tools is extremely competitive and cut-throat and no one is going to give JavaFX a break. I am merely trying to bring these issues up within the JavaFX community so we can address them as soon as possible. As I said, I am very much *for* JavaFX. I both want it to succeed and *need* it to succeed. As Daniel Zwolenski has posted, animations which I have found to perform quite poorly in JavaFX work very well inside a web page with JavaScript (with or without Canvas) on the exact same machine. Clearly then there must be something fundamentally different in the way these competing technologies are handling animations. To me this says that it must be possible for JavaFX to achieve similar levels of performance as other technologies are able to extract better performance out of the same OS and hardware. This says to me that developers who are not necessarily tied to the Java language for any reason would obviously choose a technology that performs better. This is the concern. This is the kind of thing we need to redress. Whilst my comments may be seen to be unnecessarily critical, I am being far kinder than our competitors. New features can be added to JavaFX but if the core features are not working as well as the other products on the market then clearly there is a real problem. I made a comment along the lines that I feel the animations in the Ensemble demos do very little to promote JavaFX and, as harsh as it may sound, I stand by that. Scott Palmer has echoed those sentiments with his recent commentary on Brick Breaker. While obviously it's a lot of work, JavaFX needs at least one truly awesome demo that showcases everything it has to offer. If such a demo is not possible with JavaFX as it currently stands then that tells us something. My own personal feelings about JavaFX are that it is an absolutely awesome product with amazing potential. It is a vast improvement over Swing and, although not many people outside the Java community realise this, it has features and capabilities that other competing products simply don't have. If we can get the basics working better, JavaFX has the potential to be a very significant player and not just for developers who have traditionally programmed in Java. For me, they are the people we should really be targeting. Also, I think the JavaFX development team are doing a first class job. Even though I think I made this clear, none of my critical commentary is directed at them. I also acknowledge that my references to
