Re: Dead horse, Bindings spam when something is null
Hi John,
the reason why the logging was introduced is that when selectBinding is
evaluated and there's a null along the way, you don't know where the
actual (null) value comes from. E.g.
Bindings.selectString(insertedMedia, title) might be null if
insertedMedia.get() == null || insertedMedia.get().getTitle() == null.
The logging helps to identify the cause of the null.
But I understand that when the developer expects the null to be there,
the NPE logs are not legitimate. The plan is to remove the logging for
new select binding methods that will explicitly provide the default
value when some of the steps are null:
https://javafx-jira.kenai.com/browse/RT-26399.
Regards,
-Martin
On 12/13/2013 10:11 PM, John Hendrikx wrote:
Run the following code. It has a simple ObjectProperty that -can- be
null when there is no Media inserted. I want to make a binding that
displays this information to the user, but will display -no-media-
if nothing is inserted.
Is it really necessary to spam my logs with fake NPE's when
insertedMedia happens to be null ? This seems like a perfectly valid
use case, and one that has been working fine up until somewhere
halfway through the JavaFX 8 development cycle (and it still works
fine, but now it spams me).
This is not the only spot I have this in my Application almost
everything in my Application is dynamically loaded -- user interfaces
are shown to the user before all data is present, which means I have
lots and lots and lots of bindings that will be null for a short while
as they get loaded. Typically this loading occurs on background
threads in order not to choke the Event thread, nor force the user to
look at some waiting screen while Images get decoded, HTTP requests
complete and Database calls get done.
For the life of me I cannot figure out what could be wrong with an
ObjectProperty being null when evaluating a Binding. Either make it
catastrophically fail, so this use case is disallowed as it is
obviously somehow super (confusing|dangerous|morally wrong|politicaly
incorrect) or remove this logging which looks deceptively like a real
error, but is not.
The only reasonable workaround I've found is to just replace the
Bindings class with my own which is a bit more frugal with its logging.
I know about when/then/otherwise... it becomes unreadable at several
levels deep, not to mention being completely unnecessary.
--John
import javafx.application.Application;
import javafx.beans.binding.Bindings;
import javafx.beans.binding.StringBinding;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.SimpleObjectProperty;
import javafx.beans.property.SimpleStringProperty;
import javafx.beans.property.StringProperty;
import javafx.stage.Stage;
public class BindingTest extends Application {
public static void main(String[] args) {
Application.launch(args);
}
@Override
public void start(Stage primaryStage) {
ObjectPropertyMedia insertedMedia = new SimpleObjectProperty();
StringBinding x = new StringBinding() {
StringBinding selectString =
Bindings.selectString(insertedMedia, title);
{
bind(selectString);
}
@Override
protected String computeValue() {
return selectString.get() == null ? -no-media- :
selectString.get();
}
};
System.out.println(x = + x.get());
insertedMedia.set(new Media());
System.out.println(x = + x.get());
insertedMedia.get().titleProperty().set(B);
System.out.println(x = + x.get());
insertedMedia.get().titleProperty().set(B2);
System.out.println(x = + x.get() + vs. +
insertedMedia.get().titleProperty().get());
}
public static class Media {
private final StringProperty title = new SimpleStringProperty();
public StringProperty titleProperty() {
return title;
}
public String getTitle() {
return title.get();
}
public void setTitle(String title) {
this.title.set(title);
}
}
}
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: 74d25a72690f Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-01-03 09:28 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/74d25a72690f RT-35139 [Animation] Regression: Misbehavior of *Transition within ParallelTransition ! modules/graphics/src/main/java/javafx/animation/ParallelTransition.java ! modules/graphics/src/main/java/javafx/animation/SequentialTransition.java ! modules/graphics/src/test/java/javafx/animation/ParallelTransitionPlayTest.java Changeset: 3e0a4ea8e8f6 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-01-03 09:29 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3e0a4ea8e8f6 [TEST] typo fix in test name ! modules/graphics/src/test/java/javafx/animation/ParallelTransitionPlayTest.java
scenebuilder and migpane
Would it be possible to offer MigPane as a Container in SceneBuilder? Tom
custom FXML builders in SceneBuilder
I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
Re: scenebuilder and migpane
That would be great! We only using MigPane for all our layouts… Am 03.01.2014 um 10:10 schrieb Tom Eugelink t...@tbee.org: Would it be possible to offer MigPane as a Container in SceneBuilder? Tom
Re: scenebuilder and migpane
Well, I figure the helper lines will be a problem anyhow. But I was planning on just trying it. Tom On 2014-1-3 11:04, Eric Le Ponner wrote: I guess it's worth trying to drop MigPane JAR file in SB2 library panel and see. However SB2 makes some assumptions about containers. So that might not work straight away. Eric Le 3 janv. 2014 à 10:10, Tom Eugelink t...@tbee.org a écrit : Would it be possible to offer MigPane as a Container in SceneBuilder? Tom
Re: properties of custom controls in SceneBuilder
Yes, SB currently makes a filtering : for custom components, it displays: - properties that are inherited from JavaFX core classes - properties with basic java types (integer, double, string, boolean). We'll try to remove some of those limitations over the time. Eric Le 3 janv. 2014 à 11:01, Tom Eugelink t...@tbee.org a écrit : Adding the controls in JFXtras to SceneBuilder worked without a problem, but scene builder does not show all their properties. For example CalendarTextField has 5 properties like Locale, Calendar, DateFormat, but only promptText is shown by SceneBuilder.
Re: not all custom controls are usable in SceneBuilder
On 03/01/14 11:03, Tom Eugelink wrote: Not all JFXtras custom components are draggable from the library's custom tab to the scene. For example Agenda and CalendarTextField can be dragged, but CalendarPicker or ListSpinner cannot. Is there any way to determine why this is the case? SceneBuilder only shows a forbidden icon as the mouse pointer. Tom I've no trouble dragging all the one you list, CalendarPicker and ListSpinner included. I use a JFXtras jar stamped Nov. 24th and the latest promoted SceneBuilder 2 (b09). Note that in the coming b10 there's a way to read the jar analysis report, useful if you do not see coming up in the Library the expected custom item. Yves
Re: custom FXML builders in SceneBuilder
When Scene Builder 2.0 found a custom components, it instantiates it using FXMLLoader without making any specific builder setup. So FXMLLoader uses the default JavaFX builder factory. Since builders are deprecated, I'm not sure it make sense for SB to have dependency on them. Eric Le 3 janv. 2014 à 10:55, Tom Eugelink t...@tbee.org a écrit : I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
Re: custom FXML builders in SceneBuilder
I think there are two usages of builders: - construct compontents / controls programatically (ending in the build() call). - mapping of FXML attributes to node properties, because in FXML everything must be a string. For example, CalendarTextField has no builder class in the first sense (I used withers for that), but does have a class that converts the dateFormats (list of SimpleDateFormat strings) in an fxml file to an actual list of DateFormats instances. https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/fxml/CalendarTextFieldBuilder.java If you can explain to me how to do this without a builder, but also without polluting CalendarTextField with FXML aspects, then I'll change the code. Tom On 2014-1-3 11:44, Eric Le Ponner wrote: When Scene Builder 2.0 found a custom components, it instantiates it using FXMLLoader without making any specific builder setup. So FXMLLoader uses the default JavaFX builder factory. Since builders are deprecated, I'm not sure it make sense for SB to have dependency on them. Eric Le 3 janv. 2014 à 10:55, Tom Eugelink t...@tbee.org a écrit : I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
Re: not all custom controls are usable in SceneBuilder
On 2014-1-3 11:18, Yves JOAN wrote: On 03/01/14 11:03, Tom Eugelink wrote: Not all JFXtras custom components are draggable from the library's custom tab to the scene. For example Agenda and CalendarTextField can be dragged, but CalendarPicker or ListSpinner cannot. Is there any way to determine why this is the case? SceneBuilder only shows a forbidden icon as the mouse pointer. I've no trouble dragging all the one you list, CalendarPicker and ListSpinner included. I use a JFXtras jar stamped Nov. 24th and the latest promoted SceneBuilder 2 (b09). Note that in the coming b10 there's a way to read the jar analysis report, useful if you do not see coming up in the Library the expected custom item. Ok. I'll try newer versions of SceneBuilder. I'm using JFXtras 8.0-r1-SNAPSHOT. Problem remains that all the feedback I get is the forbidden mouse pointer, so I cannot diagnose the reason. Tom
Re: custom FXML builders in SceneBuilder
I will look at that and come back to you middle of next week. Eric Le 3 janv. 2014 à 12:12, Tom Eugelink t...@tbee.org a écrit : I think there are two usages of builders: - construct compontents / controls programatically (ending in the build() call). - mapping of FXML attributes to node properties, because in FXML everything must be a string. For example, CalendarTextField has no builder class in the first sense (I used withers for that), but does have a class that converts the dateFormats (list of SimpleDateFormat strings) in an fxml file to an actual list of DateFormats instances. https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/fxml/CalendarTextFieldBuilder.java If you can explain to me how to do this without a builder, but also without polluting CalendarTextField with FXML aspects, then I'll change the code. Tom On 2014-1-3 11:44, Eric Le Ponner wrote: When Scene Builder 2.0 found a custom components, it instantiates it using FXMLLoader without making any specific builder setup. So FXMLLoader uses the default JavaFX builder factory. Since builders are deprecated, I'm not sure it make sense for SB to have dependency on them. Eric Le 3 janv. 2014 à 10:55, Tom Eugelink t...@tbee.org a écrit : I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
Re: custom FXML builders in SceneBuilder
IIRC we agreed while talking about the annotation replacement for builders that we'll later add a possibility to set a converter on properties through annotations - back then we only talked about constructors but this could be expanded to any property. Tom On 03.01.14 12:12, Tom Eugelink wrote: I think there are two usages of builders: - construct compontents / controls programatically (ending in the build() call). - mapping of FXML attributes to node properties, because in FXML everything must be a string. For example, CalendarTextField has no builder class in the first sense (I used withers for that), but does have a class that converts the dateFormats (list of SimpleDateFormat strings) in an fxml file to an actual list of DateFormats instances. https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/fxml/CalendarTextFieldBuilder.java If you can explain to me how to do this without a builder, but also without polluting CalendarTextField with FXML aspects, then I'll change the code. Tom On 2014-1-3 11:44, Eric Le Ponner wrote: When Scene Builder 2.0 found a custom components, it instantiates it using FXMLLoader without making any specific builder setup. So FXMLLoader uses the default JavaFX builder factory. Since builders are deprecated, I'm not sure it make sense for SB to have dependency on them. Eric Le 3 janv. 2014 à 10:55, Tom Eugelink t...@tbee.org a écrit : I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
hg: openjfx/8u-dev/rt: RT-35168: Remove debug print statements from launchertest.MainLauncherTest
Changeset: c7e94937d287 Author:kcr Date: 2014-01-03 05:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c7e94937d287 RT-35168: Remove debug print statements from launchertest.MainLauncherTest ! tests/system/src/test/java/launchertest/TestAppNoMainThreadCheck.java ! tests/system/src/test/java/launchertest/TestAppThreadCheck.java ! tests/system/src/test/java/launchertest/TestNotApplicationThreadCheck.java ! tests/system/src/test/java/launchertest/TestPreloader.java
hg: openjfx/8u-dev/rt: RT-35169: Fix copyright header for files modified in 2014
Changeset: 703155c18442 Author:kcr Date: 2014-01-03 06:00 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/703155c18442 RT-35169: Fix copyright header for files modified in 2014 ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DDriverInformation.java ! modules/graphics/src/main/java/com/sun/scenario/effect/Effect.java ! modules/graphics/src/main/java/com/sun/scenario/effect/Reflection.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/PrFloodPeer.java ! modules/graphics/src/main/java/javafx/animation/ParallelTransition.java ! modules/graphics/src/main/java/javafx/animation/SequentialTransition.java ! modules/graphics/src/main/native-prism-d3d/D3DBadHardware.h ! modules/graphics/src/main/native-prism-d3d/D3DPipelineManager.cc ! modules/graphics/src/main/native-prism-d3d/D3DPipelineManager.h ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/GridDirtyRegionTest.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGTestBase.java ! modules/graphics/src/test/java/com/sun/scenario/effect/rt_5239/RT_5239Test.java ! modules/graphics/src/test/java/javafx/animation/ParallelTransitionPlayTest.java ! tests/system/src/test/java/launchertest/TestAppNoMainThreadCheck.java ! tests/system/src/test/java/launchertest/TestAppThreadCheck.java ! tests/system/src/test/java/launchertest/TestNotApplicationThreadCheck.java ! tests/system/src/test/java/launchertest/TestPreloader.java
Review request:RT-34928,Ensemble: Bouncing Balls leave tracks
Jim, please review JIRA: https://javafx-jira.kenai.com/browse/RT-34928 Webrev: http://cr.openjdk.java.net/~msladecek/rt-34928/webrev.00/ Thanks, -Martin
hg: openjfx/8/graphics/rt: Added tag 8.0-b122 for changeset dd789066e61e
Changeset: 26f87c5d3435 Author:hudson Date: 2014-01-03 06:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/26f87c5d3435 Added tag 8.0-b122 for changeset dd789066e61e ! .hgtags
Re: Regression: JavaFX 8 doesn't call listeners in Skin implementations
Hi Florian,
I would enter a JIRA with the steps to make the problem happen and the
smallest possible example code that shows it.
Thanks,
Steve
On 2014-01-02 5:10 PM, Florian Brunner wrote:
I also tried to add a listener directly to
control.getDockingSplitPaneChildren() in case the issue is with
Bindings.bindContent, but also this listener doesn't get called.
member:
private final ListChangeListenerDockingSplitPaneChildBase
dockingSplitPaneChildrenListener = new
ListChangeListenerDockingSplitPaneChildBase() {
@Override
public void onChanged(Change? extends DockingSplitPaneChildBase
change) {
System.out.println(Change!);
}
};
...
in constructor:
control.getDockingSplitPaneChildren().addListener(dockingSplitPaneChildrenListener);
-Florian
Am Donnerstag, 2. Januar 2014, 22.51:23 schrieb Florian Brunner:
Hi,
I'm in the process of upgrading Drombler FX to JavaFX 8 and hit another
regression issue: JavaFX 8 doesn't call listeners in my Skin implementation (it
used to work with JavaFX 2.x !)
Here is the Skin implementation:
https://sourceforge.net/p/drombler/drombler-fx/ci/default/tree/drombler-fx-core-docking/src/main/java/org/drombler/fx/core/docking/impl/skin/DockingSplitPaneSkin.java
When I add something to
control.getDockingSplitPaneChildren()
what should trigger the listeners, then with a debugger I can trace the call up
to the WeakListChangeListener where on line 87 the listener is null.
Note that I'm not using a WeakListChangeListener explicitly - JavaFX 8 must
have created this somewhere and for some reason the listener from the Skin got
lost!
I also tried to keep a reference to my listeners as a member variable in the
Skin implementation, but this didn't work either.
I haven't filed an issue yet because I guess there is already a new way how to
solve this.
Note that I would like to solve this first with this basic Skin
implementation and not with the new SkinBase class just yet, as I'm not familiar with
that new class yet. One refactoring step at a time. ;-)
-Florian
Re: General schedule/roadmap/status
Hi Kevin, Oracle builds Java 8 using the OpenJDK. OpenJFX is a part of the OpenJDK and is built into Oracle's Java 8 distribution. The rest of these questions are really for the various different Linux distributions that consume open source projects and produce their own builds. I suggest that you ping them and find out their plans. Thanks, Steve On 2014-01-02 7:24 PM, Kevin Smith wrote: Hi all, If my questions are answered by existing web pages or archived email threads, please point me to them. I looked, but could not find any. We are looking at committing to JavaFX for some major new UI work, and want to understand the likely availability of JavaFX for our OpenJDK users. My understanding is that JavaFX is/will be built into Java 8. That's true for OpenJDK 8 also, right? I am aware of Oracle's Java 8 build, and I found a Fedora OpenJDK 8 package. I don't see anything like that for Debian, and couldn't find any mention of any current or planned work on one. Does anyone know when a preview version of OpenJDK might be packaged for Debian? The scheduled release of Oracle Java 8 is in a few months. Will the OpenJDK release be simultaneous with that? Earlier? Based on past history, is there likely to be a long delay between the official Java 8 release, and when it is available in a public Debian (or Ubuntu) release? Do they tend to ship preview releases, or do they only release full public versions of OpenJDK? There were milestones in October and November related to ZBB and other quality levels? Have those been hit? How is Open JavaFX looking relative to the big release date? Has anyone packaged Open JavaFX for Java 7 (e.g. on Debian)? Thanks much, Kevin
Re: JavaFX versus AWT/Swing Hardware Acceleration
Hi Ryan, I'll let others describe hardware acceleration in AWT/Swing but in JavaFX, D3D and ES2 shaders are used to draw. These run directly on the graphics card and render data that is downloaded there. Because JavaFX has a scene graph, it has a notion of what has been changed and can render only a subset of the scene graph nodes. This is a very high level description of JavaFX but captures the essence of what is happening. Any other FX committers want to comment? Steve On 2014-01-01 1:39 PM, Ryan Cuprak wrote: What is the difference between hardware acceleration in JavaFX versus Swing/AWT? I heard a while back someone claim that Swing/AWT could never fully leverage hardware acceleration. However there are the usual mix of -D parameters (sun.java2.opengl/sun.java2d.d3d, etc.) for Swing/AWT. So I am just wondering how JavaFX’s acceleration differs from the hardware acceleration in Swing. When I was giving a talk at a JUG meeting someone called me out on the hardware acceleration bit and I realized I didn’t fully understand the differences between the two. I understand that JavaFX has a scene graph and Swing doesn’t etc. So I am assuming that the scene graph operations are optimized on the GPU whereas if you were trying to replicate a scene graph in Swing you would obviously be doing all the work on the CPU. So Swing’s hardware acceleration is more about buffers? I did come across this article: https://weblogs.java.net/blog/opinali/archive/2010/05/03/first-long-look-javafx-13-and-prism Specifically this line caught my attention Prism finally renders effects with full hardware acceleration and without the extra buffer copies that spoil effects on the Swing toolkit.” This article is a dated - brings up a second question about hardware acceleration with a hybrid Swing/JavaFX application - what happens? Thanks, -Ryan
Re: JavaFX versus AWT/Swing Hardware Acceleration
A couple other thoughts. 1) JavaFX doesn't use software loops for the actual rendering as long as the card is capable of supporting Prism. We do mix HW and SW in that we generate masks from a path in SW, but we cache that on the card and render it using shaders. 2) JavaFX can support Intel HD on Windows (something in the way Java2D uses D3D exposes a bug in Intel's driver so it is disabled). Jim can probably come up with more. -- Kevin Stephen F Northover wrote: Hi Ryan, I'll let others describe hardware acceleration in AWT/Swing but in JavaFX, D3D and ES2 shaders are used to draw. These run directly on the graphics card and render data that is downloaded there. Because JavaFX has a scene graph, it has a notion of what has been changed and can render only a subset of the scene graph nodes. This is a very high level description of JavaFX but captures the essence of what is happening. Any other FX committers want to comment? Steve On 2014-01-01 1:39 PM, Ryan Cuprak wrote: What is the difference between hardware acceleration in JavaFX versus Swing/AWT? I heard a while back someone claim that Swing/AWT could never fully leverage hardware acceleration. However there are the usual mix of -D parameters (sun.java2.opengl/sun.java2d.d3d, etc.) for Swing/AWT. So I am just wondering how JavaFX’s acceleration differs from the hardware acceleration in Swing. When I was giving a talk at a JUG meeting someone called me out on the hardware acceleration bit and I realized I didn’t fully understand the differences between the two. I understand that JavaFX has a scene graph and Swing doesn’t etc. So I am assuming that the scene graph operations are optimized on the GPU whereas if you were trying to replicate a scene graph in Swing you would obviously be doing all the work on the CPU. So Swing’s hardware acceleration is more about buffers? I did come across this article: https://weblogs.java.net/blog/opinali/archive/2010/05/03/first-long-look-javafx-13-and-prism Specifically this line caught my attention Prism finally renders effects with full hardware acceleration and without the extra buffer copies that spoil effects on the Swing toolkit.” This article is a dated - brings up a second question about hardware acceleration with a hybrid Swing/JavaFX application - what happens? Thanks, -Ryan
hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android
Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
Re: JavaFX versus AWT/Swing Hardware Acceleration
Prism. We do mix HW and SW in that we generate masks from a path in SW, but we cache that on the card and render it using shaders. Can you describe roughly how the caching works? I understand that the alpha mask is stored in OGL as a texture, but there are an infinite number of possible paths to be masked. How many textures can be stored at once (on say an iPhone)? I'm guessing JavaFX uses some sort of LRU caching algorithm for these textures? I ask this because I've been playing around directly with the Pisces C library directly to generate alpha masks and render them using shaders. I can see a performance increase of 4x in using alpha masks rather than full argb pixels (due to 1 byte per pixel instead of 4), but I'm curious about other savings that JavaFX makes with this method. (Hopefully this question doesn't take this thread too far off topic... my hope is that the answer to this question will help shed light on the original poster's question also). Steve
Post commit review: [Re: hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android]
Hi Alex, Samples were changed to support Android. Apparently, hitting escape twice should exit an application and this behavior was coded into EnsembleApp. I'm not an Android guy but if this is standard Android behavior, it should be part of JFX, not the example code. Anyhow, I'll let Stefan or Johan comment on this and they can enter a follow on JIRA. Steve On 2014-01-03 12:32 PM, hang...@oracle.com wrote: Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
Re: JavaFX versus AWT/Swing Hardware Acceleration
The Graphics Support section in this link has a detail information on the list of GPUs JavaFX can take advantage of: http://docs.oracle.com/javafx/2/system_requirements_2-2-5/jfxpub-system_requirements_2-2-5.htm Note: Linux and Mac should have the same support coverage except for Intel GMA 4500 which we haven't tested. - Chien On 01/03/2014 09:24 AM, Kevin Rushforth wrote: A couple other thoughts. 1) JavaFX doesn't use software loops for the actual rendering as long as the card is capable of supporting Prism. We do mix HW and SW in that we generate masks from a path in SW, but we cache that on the card and render it using shaders. 2) JavaFX can support Intel HD on Windows (something in the way Java2D uses D3D exposes a bug in Intel's driver so it is disabled). Jim can probably come up with more. -- Kevin Stephen F Northover wrote: Hi Ryan, I'll let others describe hardware acceleration in AWT/Swing but in JavaFX, D3D and ES2 shaders are used to draw. These run directly on the graphics card and render data that is downloaded there. Because JavaFX has a scene graph, it has a notion of what has been changed and can render only a subset of the scene graph nodes. This is a very high level description of JavaFX but captures the essence of what is happening. Any other FX committers want to comment? Steve On 2014-01-01 1:39 PM, Ryan Cuprak wrote: What is the difference between hardware acceleration in JavaFX versus Swing/AWT? I heard a while back someone claim that Swing/AWT could never fully leverage hardware acceleration. However there are the usual mix of -D parameters (sun.java2.opengl/sun.java2d.d3d, etc.) for Swing/AWT. So I am just wondering how JavaFX’s acceleration differs from the hardware acceleration in Swing. When I was giving a talk at a JUG meeting someone called me out on the hardware acceleration bit and I realized I didn’t fully understand the differences between the two. I understand that JavaFX has a scene graph and Swing doesn’t etc. So I am assuming that the scene graph operations are optimized on the GPU whereas if you were trying to replicate a scene graph in Swing you would obviously be doing all the work on the CPU. So Swing’s hardware acceleration is more about buffers? I did come across this article: https://weblogs.java.net/blog/opinali/archive/2010/05/03/first-long-look-javafx-13-and-prism Specifically this line caught my attention Prism finally renders effects with full hardware acceleration and without the extra buffer copies that spoil effects on the Swing toolkit.” This article is a dated - brings up a second question about hardware acceleration with a hybrid Swing/JavaFX application - what happens? Thanks, -Ryan
Re: JavaFX versus AWT/Swing Hardware Acceleration
Jim will probably has more to say about how the caching works. JavaFX has a unified texture resource management system for Prism. An aging algorithm is used to determine which native texture resource to be released when the system is low on VRAM or reached a system configurable VRAM threshold (for embedded). - Chien On 01/03/2014 09:40 AM, Steve Hannah wrote: Prism. We do mix HW and SW in that we generate masks from a path in SW, but we cache that on the card and render it using shaders. Can you describe roughly how the caching works? I understand that the alpha mask is stored in OGL as a texture, but there are an infinite number of possible paths to be masked. How many textures can be stored at once (on say an iPhone)? I'm guessing JavaFX uses some sort of LRU caching algorithm for these textures? I ask this because I've been playing around directly with the Pisces C library directly to generate alpha masks and render them using shaders. I can see a performance increase of 4x in using alpha masks rather than full argb pixels (due to 1 byte per pixel instead of 4), but I'm curious about other savings that JavaFX makes with this method. (Hopefully this question doesn't take this thread too far off topic... my hope is that the answer to this question will help shed light on the original poster's question also). Steve
Re: scenebuilder and migpane
Simply dropping the jars is not possible, because MigLayout is split into two jars; core and javafx. Core does not contain any JavaFX classes and thus SceneBuilder does not import it (button is disabled). After manually merging the two jars into one, MigPane is listed in SB as a custom control. Dropping nodes onto MigPane works; they are put next to each other, as the default layout logic of MigPane does things. But for each node there should be a possibility to specify a constraint string, the cc property is not listed in the inspector (unlike, for example, hgrow in a HBox). I've created a special FXML MigPane class to contain the FXML scaffolding, this class has a static void setCc(Node, String) method. What determines when such a static method is displayed in the inspector's layout tab? Missing are the helper lines to show the grid, like GridPane has. I'm assuming there is some kind of helper class to better embed the layouts in SB? MigLayout is a very popular layout engine in Swing and SWT (and also gaining ground on Android), I think it would be good for SceneBuilder to better support MigLayout. Tom On 2014-1-3 11:04, Eric Le Ponner wrote: I guess it's worth trying to drop MigPane JAR file in SB2 library panel and see. However SB2 makes some assumptions about containers. So that might not work straight away. Eric Le 3 janv. 2014 à 10:10, Tom Eugelink t...@tbee.org a écrit : Would it be possible to offer MigPane as a Container in SceneBuilder? Tom
Re: Very poor performance of JavaFX on iPhone - 6 months later
Hi Tobias, Sorry about that. Looking at the bug, it seems to me that we have gotten to the bottom of it. Some iOS devices are scrolling fine while others are slower. The difference seems to be that high dpi disables optimizations and this causes the slowness on iOS. The same optimizations are disabled on the desktop, but the desktop is much faster and people don't notice. There was some discussion about performance in the simulator, but we should ignore that. Performance on the device is what matters. iOS and Android are not currently supported platforms for JavaFX. We are looking towards the community to step up and submit patches to take these ports forward. Johan Vos and others are helping with Android. Are you interested in working on iOS? If so, please build on the patches in https://javafx-jira.kenai.com/browse/RT-31453 and take the work forward. The first step would be to prove that we can be fast (which I think we can if we run with the optimizations) then understand how to turn the optimizations back on. Steve On 2014-01-03 3:28 PM, Tobias Bley wrote: Hi, many months ago I reported the „poor performance on iOS“ issue (https://javafx-jira.kenai.com/browse/RT-31453). Now 6 months later the bug is already open and no one of Oracle answers me on Jira. What’s up? How can we fix this important bug? Best, Tobi
Re: Post commit review: [Re: hg: openjfx/8u-dev/rt: RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android]
If you feel that further work needs to be done here, please enter a JIRA and include this discussion. Thanks, Steve On 2014-01-03 2:43 PM, Stefan Fuchs wrote: Hi, well, the back button is always used to go back one dialog level, until the start screen has be reached. (Dialogs are canceled, browsers go to previous website, etc...) If you press the back button on the start screen of the app, I found three different strategies to handle the back button: 1. Exit the app on first button press (examples: WhatsApp, Google Maps) 2. Hide the app on first button press and let the system kill the application, if system memory is exhausted. (examples: FireFox, Chrome) 3. Exit the app on second button press (note that most apps using this strategy print a notice message, after the first key press, which is currently not implemented for Ensemble8) (examples: Samsungs App Store) Stefan Stephen F Northover wrote: Hi Alex, Samples were changed to support Android. Apparently, hitting escape twice should exit an application and this behavior was coded into EnsembleApp. I'm not an Android guy but if this is standard Android behavior, it should be part of JFX, not the example code. Anyhow, I'll let Stefan or Johan comment on this and they can enter a follow on JIRA. Steve On 2014-01-03 12:32 PM, hang...@oracle.com wrote: Changeset: 6f0901527ad0 Author:snorthov Date: 2014-01-03 12:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6f0901527ad0 RT-35147: [Android, Ensemble8] App should react to hardware buttons on Android Reviewed-by: snorthov Contributed-by: Stefan Fuchs snfu...@gmx.de ! apps/samples/Ensemble8/src/app/java/ensemble/EnsembleApp.java ! apps/samples/Ensemble8/src/app/java/ensemble/PlatformFeatures.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SourceTab.java ! apps/samples/Ensemble8/src/app/java/ensemble/util/FeatureChecker.java ! modules/base/src/main/java/com/sun/javafx/PlatformUtil.java
hg: openjfx/8/graphics/rt: RT-35171: Update the JDK 8 build number to b122 in rt/build.properties file in the JavaFX 8 Master forest.
Changeset: 44acc56c806e Author:mv157916 Date: 2014-01-03 13:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/44acc56c806e RT-35171: Update the JDK 8 build number to b122 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties
hg: openjfx/8u-dev/rt: RT-35172: Add unit test for batching large number of runLater operations
Changeset: acc894d665a6 Author:kcr Date: 2014-01-03 13:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/acc894d665a6 RT-35172: Add unit test for batching large number of runLater operations + tests/system/src/test/java/com/sun/javafx/application/RunLaterTest.java ! tests/system/src/test/java/util/Util.java
[8u] Post-commit review: RT-35172: Add unit test for batching large number of runLater operations
Anthony Steve, If you are interested, I added a unit test for batching large numbers of runLater operations (as a follow up to RT-21569 https://javafx-jira.kenai.com/browse/RT-21569), which in FX 8 works on Windows platforms only because of the InvokeLaterDispatcher. JIRA: https://javafx-jira.kenai.com/browse/RT-35172 Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/acc894d665a6 As I wrote in the JIRA: While instrumenting the code, a comment indicates that for SWT embedding, the InvokeLaterDispatcher is disabled, so this might be an issue on Windows in that mode. Perhaps a follow-up issue is in order, although in practice I'm not sure we have ever seen this failure. -- Kevin
Re: Very poor performance of JavaFX on iPhone - 6 months later
I noticed the high-dpi problem on a high-end MacBook Pro Retina. Took me by surprise for JavaOne demos since I usually use an external monitor (non-retina). I ended up switching to low dpi. jeff On Jan 3, 2014, at 3:59 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: Hi Tobias, Sorry about that. Looking at the bug, it seems to me that we have gotten to the bottom of it. Some iOS devices are scrolling fine while others are slower. The difference seems to be that high dpi disables optimizations and this causes the slowness on iOS. The same optimizations are disabled on the desktop, but the desktop is much faster and people don't notice. There was some discussion about performance in the simulator, but we should ignore that. Performance on the device is what matters. iOS and Android are not currently supported platforms for JavaFX. We are looking towards the community to step up and submit patches to take these ports forward. Johan Vos and others are helping with Android. Are you interested in working on iOS? If so, please build on the patches in https://javafx-jira.kenai.com/browse/RT-31453 and take the work forward. The first step would be to prove that we can be fast (which I think we can if we run with the optimizations) then understand how to turn the optimizations back on. Steve On 2014-01-03 3:28 PM, Tobias Bley wrote: Hi, many months ago I reported the „poor performance on iOS“ issue (https://javafx-jira.kenai.com/browse/RT-31453). Now 6 months later the bug is already open and no one of Oracle answers me on Jira. What’s up? How can we fix this important bug? Best, Tobi
Re: Very poor performance of JavaFX on iPhone - 6 months later
Hi Jeff, Please add your weight to the JIRA (indicate the hardware you are using). A fix for the desktop should also fix the problem on iOS. Steve On 2014-01-03 5:45 PM, Jeff Martin wrote: I noticed the high-dpi problem on a high-end MacBook Pro Retina. Took me by surprise for JavaOne demos since I usually use an external monitor (non-retina). I ended up switching to low dpi. jeff On Jan 3, 2014, at 3:59 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: Hi Tobias, Sorry about that. Looking at the bug, it seems to me that we have gotten to the bottom of it. Some iOS devices are scrolling fine while others are slower. The difference seems to be that high dpi disables optimizations and this causes the slowness on iOS. The same optimizations are disabled on the desktop, but the desktop is much faster and people don't notice. There was some discussion about performance in the simulator, but we should ignore that. Performance on the device is what matters. iOS and Android are not currently supported platforms for JavaFX. We are looking towards the community to step up and submit patches to take these ports forward. Johan Vos and others are helping with Android. Are you interested in working on iOS? If so, please build on the patches in https://javafx-jira.kenai.com/browse/RT-31453 and take the work forward. The first step would be to prove that we can be fast (which I think we can if we run with the optimizations) then understand how to turn the optimizations back on. Steve On 2014-01-03 3:28 PM, Tobias Bley wrote: Hi, many months ago I reported the „poor performance on iOS“ issue (https://javafx-jira.kenai.com/browse/RT-31453). Now 6 months later the bug is already open and no one of Oracle answers me on Jira. What’s up? How can we fix this important bug? Best, Tobi
Re: JavaFX versus AWT/Swing Hardware Acceleration
Some key points hidden in the shadows here... We have direct rendering shaders for simple objects like rects, ovals, roundrects, simple single lines. We can handle simple strokes on those with only the stroke width being customized (must use an expected join, cap, no dashing). Text is done with a grayscale bitmap cache. We also have LCD glyph caches as well on the GPU. I'd have to check to see how much we cache stroked text vs. using a default shape fill. These shaders can deal with most fills, except if you have too many colors in your gradients then we have to manually compute the colors, but I believe we still use a shader to merge the colors with the coverage and get the result on to the screen (I can dig in the code and check if it matters - I think the max colors are like 16). Besides those, we render other things like Polygons, Polylines, Path, SVGPath using a native version of Pisces and caching the masks on the GPU. The masks will be invalidated when the path changes in any way, and for any transform change other than a translate (I believe). This is done as a grayscale texture and is separate from the kind of caching done when you select a Node's cache hint (that hint will result in a full-color cache that will be rendered with a simple blit operation and can cache effects and other node attributes in addition to just shape coverage). On the table is for someone to create a mechanism similar to the NV_PATH rendering extension that lets us feed the path to the GPU and use stencils to render it at hardware speeds. Unfortunately, the nVidia extension requires an nVidia GPU and only works on OpenGL, but I believe that much of that is due to them accelerating path stroking on the GPU. We could probably at least use similar techniques to their extension to do fills and rely on our existing code to convert strokes to fill paths to couple with it. Their techniques require certain stencil modes that are not universal so some investigation needs to be done to see how widely any of these techniques could be supported on either/both of D3D and OGL (and embedded). Did you want a comparison to Java2D or were you more interested in just what FX can do? I'd have to do some digging to figure out what parts of this aren't handled in J2D... ...jim On 1/3/14 9:24 AM, Kevin Rushforth wrote: A couple other thoughts. 1) JavaFX doesn't use software loops for the actual rendering as long as the card is capable of supporting Prism. We do mix HW and SW in that we generate masks from a path in SW, but we cache that on the card and render it using shaders. 2) JavaFX can support Intel HD on Windows (something in the way Java2D uses D3D exposes a bug in Intel's driver so it is disabled). Jim can probably come up with more. -- Kevin Stephen F Northover wrote: Hi Ryan, I'll let others describe hardware acceleration in AWT/Swing but in JavaFX, D3D and ES2 shaders are used to draw. These run directly on the graphics card and render data that is downloaded there. Because JavaFX has a scene graph, it has a notion of what has been changed and can render only a subset of the scene graph nodes. This is a very high level description of JavaFX but captures the essence of what is happening. Any other FX committers want to comment? Steve On 2014-01-01 1:39 PM, Ryan Cuprak wrote: What is the difference between hardware acceleration in JavaFX versus Swing/AWT? I heard a while back someone claim that Swing/AWT could never fully leverage hardware acceleration. However there are the usual mix of -D parameters (sun.java2.opengl/sun.java2d.d3d, etc.) for Swing/AWT. So I am just wondering how JavaFX’s acceleration differs from the hardware acceleration in Swing. When I was giving a talk at a JUG meeting someone called me out on the hardware acceleration bit and I realized I didn’t fully understand the differences between the two. I understand that JavaFX has a scene graph and Swing doesn’t etc. So I am assuming that the scene graph operations are optimized on the GPU whereas if you were trying to replicate a scene graph in Swing you would obviously be doing all the work on the CPU. So Swing’s hardware acceleration is more about buffers? I did come across this article: https://weblogs.java.net/blog/opinali/archive/2010/05/03/first-long-look-javafx-13-and-prism Specifically this line caught my attention Prism finally renders effects with full hardware acceleration and without the extra buffer copies that spoil effects on the Swing toolkit.” This article is a dated - brings up a second question about hardware acceleration with a hybrid Swing/JavaFX application - what happens? Thanks, -Ryan
Re: JavaFX versus AWT/Swing Hardware Acceleration
Chien answered some of these, but here are my answers (inline)... On 1/3/14 9:40 AM, Steve Hannah wrote: Prism. We do mix HW and SW in that we generate masks from a path in SW, but we cache that on the card and render it using shaders. Can you describe roughly how the caching works? I understand that the alpha mask is stored in OGL as a texture, but there are an infinite number of possible paths to be masked. How many textures can be stored at once (on say an iPhone)? I'm guessing JavaFX uses some sort of LRU caching algorithm for these textures? As Chien mentioned, Lombard/JDK8 has a new texture management component that lets us purge textures as needed on a LRU basis. The caching tends to simply just validate the cached mask on every Shape node that has a cached mask on every frame and it sometimes finds that the texture needs to be recreated if we are running low. Worst case, the cached texture needs to be recreated on every frame. I ask this because I've been playing around directly with the Pisces C library directly to generate alpha masks and render them using shaders. I can see a performance increase of 4x in using alpha masks rather than full argb pixels (due to 1 byte per pixel instead of 4), but I'm curious about other savings that JavaFX makes with this method. Are you referring to the C version of Pisces in the FX sources? Actually, there are 2 currently in the FX source base. There is one version (which has both a Java and native port) of the Pisces renderer that historically came from OpenJDK which got its version from an embedded port of Java that didn't use Ductus. It is used by the D3D and OGL pipelines. The second version came in when the SW pipeline was added recently, it went back to the original source base that had Pisces integrated with a full set of rendering loops and it brought that whole package in to be a complete rendering solution. So there may be some divergence between the two versions of the rasterizer given the circuitous history of how the version used by D3D/OGL got into the FX source base and the fact that there was some work done on both versions since they diverged back in the OpenJDK early days. I'd be curious to see your work and how it might help us to have some tighter integration between the rasterizers and the OGL/D3D shaders... ...jim
Re: Very poor performance of JavaFX on iPhone - 6 months later
The following Jira is more precisely aimed at the scrolling optimizations that were disabled for Retina: https://javafx-jira.kenai.com/browse/RT-27959 ...jim On 1/3/14 4:04 PM, Stephen F Northover wrote: Hi Jeff, Please add your weight to the JIRA (indicate the hardware you are using). A fix for the desktop should also fix the problem on iOS. Steve On 2014-01-03 5:45 PM, Jeff Martin wrote: I noticed the high-dpi problem on a high-end MacBook Pro Retina. Took me by surprise for JavaOne demos since I usually use an external monitor (non-retina). I ended up switching to low dpi. jeff On Jan 3, 2014, at 3:59 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: Hi Tobias, Sorry about that. Looking at the bug, it seems to me that we have gotten to the bottom of it. Some iOS devices are scrolling fine while others are slower. The difference seems to be that high dpi disables optimizations and this causes the slowness on iOS. The same optimizations are disabled on the desktop, but the desktop is much faster and people don't notice. There was some discussion about performance in the simulator, but we should ignore that. Performance on the device is what matters. iOS and Android are not currently supported platforms for JavaFX. We are looking towards the community to step up and submit patches to take these ports forward. Johan Vos and others are helping with Android. Are you interested in working on iOS? If so, please build on the patches in https://javafx-jira.kenai.com/browse/RT-31453 and take the work forward. The first step would be to prove that we can be fast (which I think we can if we run with the optimizations) then understand how to turn the optimizations back on. Steve On 2014-01-03 3:28 PM, Tobias Bley wrote: Hi, many months ago I reported the „poor performance on iOS“ issue (https://javafx-jira.kenai.com/browse/RT-31453). Now 6 months later the bug is already open and no one of Oracle answers me on Jira. What’s up? How can we fix this important bug? Best, Tobi
Re: JavaFX versus AWT/Swing Hardware Acceleration
Are you referring to the C version of Pisces in the FX sources? Actually, there are 2 currently in the FX source base. I'm working with the native Pisces code located in modules/graphics/src/main/native-prism/* I'm just making a 2D graphics API similar in functionality to java.awt.Graphics2D, but using Open GL ES2 to do the rendering. That pisces code is nice because it is self-contained, and hence very portable. My target platform is iOS --- I've been spending quite a bit of time lately going through the JavaFX code to try to wrap my head around how it works. Your description of the caching mechanisms here is very helpful. It confirms some of my assumptions and sheds a little bit of new light for me on the subject. Best regards Steve
