Re: current state of gradle script for Android?
Hi Tobi, shouldn't be necessary to patch android.gradle file or set ANDROID_CROSS_TOOLS_VER anymore. The latest changes resolve path to a toolchain taking into account variants of NDK. Thank you for testing it. -Tomas On 08/01/2013 11:41 PM, Tobias Bley wrote: Thanks Tomas, after changing android.gradle script line defineProperty(ANDROID_CROSS_TOOLS_VER, arm-linux-androideabi-4.4.3“)“ to defineProperty(ANDROID_CROSS_TOOLS_VER, arm-linux-androideabi-4.6“)“ and def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? macosx : linux-x86““ to „def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? darwin-x86_64 : linux-x86““ I could successfully build OpenJFX for Android von Mac OS X 10.9! So now I’m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in „com.oracle.dalvik“ package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? Best regards, Tobi Am 01.08.2013 um 16:00 schrieb tomas.brandalik tomas.branda...@oracle.com: The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. http://developer.android.com/sdk/index.html http://developer.android.com/tools/sdk/ndk/index.html -Tomas On 08/01/2013 03:41 PM, Tobias Bley wrote: Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? Thanks! Tobi Am 31.07.2013 um 16:42 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Tobi, it works on linux only right now. Set properties for cross build and android sdk/ndk. -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true Closed source parts web and font-t2k will be missing. -Tomas On 07/29/2013 11:22 PM, Tobias Bley wrote: Hi, can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? Best regards, Tobi
Re: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
Hi Pedro, on CSS as a spec: You are right the spec does not only hold a language definition but also the definition of e.g. the box-model, ... who simply can not be applied to FX unless you completely revamp how it works on CSS: The grammer of the CSS-Language is at http://www.w3.org/TR/CSS2/grammar.html with a descrption at http://www.w3.org/TR/CSS2/syndata.html with updates in later specs and CSS can not only be applied to HTML-Doms but e.g. also to SVG where you have completely different attributes. See www.w3.org/TR/2011/REC-SVG11-20110816/styling.html how few properties SVG and HTML-CSS share! So to me it looks like the authors of SVG see CSS in the same way the JavaFX-Team does it as a styleing DSL leaving out things like the Box-Model, ... on SASS: I see no reason it can not be used. Like I said SASS is simply syntatic sugar above the CSS Language, but it does not really care about how the properties are named! I've attached you a sample of scss file derived from the projects website using JavaFX properties and to me the output looks correct, maybe there are advanced features I'm not aware of - I haven't used SASS at all on Compass: This one does not work with FX because it somehow deals with the properties on reusing CSS-HTML-Properties: I think the confusion would be getting worse if we'd start mixing HTML-CSS-Property names with -fx ones (which we need in any case) - even if we can get them 100% HTML-CSS compliant. I don't see me blindly copying a HTML-CSS which assumes the Box-Model, element-types who are not existing in FX at all Tom On 08.08.13 02:58, Pedro Duque Vieira wrote: Go to the CSS W3C website and read the spec, you'll see that it's not only a language. No SASS can't be used with JavaFX unless you make a SASS of your own that works like the original but with JavaFX CSS files. Thanks, regards, On Thu, Aug 8, 2013 at 1:38 AM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: SASS can be used as well in fx, it is simply a preprocessor, like LESS, and for CSS the language and selectors there is a grammer! CSS is simply a DSL and its most important part are the selectors and its cascading nature. Tom Von meinem iPhone gesendet Am 08.08.2013 um 02:11 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com mailto:pedro.duquevie...@gmail.com: I might have jumped the gun when talking about LESS, I'm not actually familiar with it and thought it would be along the same lines like SASS. But still you can't use SASS or Compass with JavaFX CSS. Cheers, On Thu, Aug 8, 2013 at 1:05 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com mailto:pedro.duquevie...@gmail.com wrote: So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. +1 to this idea (in a 3rd party lib). The issue I see is that JavaFX CSS significantly differs from W3C CSS It surprises me that this issue comes up so rarely in JavaFX forums (almost never) - perhaps it is because JavaFX developers tend to be Java developers rather than designers. A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 need to reconcile JavaFX CSS with W3C CSS3 0 votes (no interest at all?). In terms of conversion of existing html css resources to javafx css, you may be interested in a QA with a developer who converted the Foundation look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from his point of view the conversion process was quite straight-forward - though perhaps that was partially luck of the draw. Below is a copy and paste from an earlier JavaFX forum post on this topic: You know, sometimes I find JavaFX's lack of certain css features refreshing. It is nice to have all, well, almost all, of the JavaFX CSS documented on one page. I think if you were to do the same thing for w3c css then it would end up with a much larger, more difficult to understand document and even what the contents of that document should be would probably be pretty controversial, in the same kind of way that the HTML5 specification ended up being. Microsoft contributed over 7000
hg: openjfx/8/graphics/rt: Android: Implement loadContent() on webview. Use default encoding set to null instead base64.
Changeset: 158e4ee0658a Author:tb115823 tomas.branda...@oracle.com Date: 2013-08-08 11:17 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/158e4ee0658a Android: Implement loadContent() on webview. Use default encoding set to null instead base64. ! modules/graphics/src/android/java/com/oracle/dalvik/InternalWebView.java ! modules/web/src/android/native/native_webview.c
hg: openjfx/8/graphics/rt: RT-31966 Null-screen error on WebEngine.print()
Changeset: 1d7e167d5300 Author:peterz Date: 2013-08-08 14:15 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1d7e167d5300 RT-31966 Null-screen error on WebEngine.print() ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java
Re: current state of gradle script for Android?
Hi, I have hardly any info about the project jfx78 backport and its status. I've just had a look at it and saw that last sync happened in beginning of July. It's good if somebody is willing to put his effort into that. In order to run on dalvik we need to compile jfx with jdk1.6 (I suppose 1.7 would do as well). Then there will be some packages missing for example java.beans or sun.misc but it could be fixed somehow. -Tomas On 08/08/2013 10:05 AM, Tobias Bley wrote: Hi Tomas, yes, I was able to build JavaFX for Android, but I would like to start JavaFX on Dalvik…You said its necessary to update the jfx78 backport to the latest openjfx code changes…? btw: I just saw your very interesting JavaOne track ;) Am 08.08.2013 um 09:59 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Tobi, shouldn't be necessary to patch android.gradle file or set ANDROID_CROSS_TOOLS_VER anymore. The latest changes resolve path to a toolchain taking into account variants of NDK. Thank you for testing it. -Tomas On 08/01/2013 11:41 PM, Tobias Bley wrote: Thanks Tomas, after changing android.gradle script line defineProperty(ANDROID_CROSS_TOOLS_VER, arm-linux-androideabi-4.4.3“)“ to defineProperty(ANDROID_CROSS_TOOLS_VER, arm-linux-androideabi-4.6“)“ and def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? macosx : linux-x86““ to „def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? darwin-x86_64 : linux-x86““ I could successfully build OpenJFX for Android von Mac OS X 10.9! So now I’m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in „com.oracle.dalvik“ package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? Best regards, Tobi Am 01.08.2013 um 16:00 schrieb tomas.brandalik tomas.branda...@oracle.com: The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. http://developer.android.com/sdk/index.html http://developer.android.com/tools/sdk/ndk/index.html -Tomas On 08/01/2013 03:41 PM, Tobias Bley wrote: Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? Thanks! Tobi Am 31.07.2013 um 16:42 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Tobi, it works on linux only right now. Set properties for cross build and android sdk/ndk. -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true Closed source parts web and font-t2k will be missing. -Tomas On 07/29/2013 11:22 PM, Tobias Bley wrote: Hi, can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? Best regards, Tobi
Rowsorting of TableView with SortedList/FilteredList
Hi guys, I'm working on a business application that makes use of TableView and I'm working with JDK 8 build b101. Displaying the data works like a charm. Row sorting for ordinary ObservableLists is fine too. Then I've set TableView.items to FilteredList and row sorting was disabled. replacing TableView.item with SortedList does not allow row sorting as well. Binding the comparator of SortedList to the TableView.comparator has no effect either. // row sorting possible //final TableViewInteger tableView = new TableView(FXCollections.observableArrayList(2, 1, 3)); // row sorting not possible (SortedList) // create a TableView with the sorted list set as the items it will show // bind the sortedList comparator to the TableView comparator //SortedListInteger sortedList = new SortedList(FXCollections.observableArrayList(2, 1, 3)); //sortedList.comparatorProperty().bind(tableView.comparatorProperty()); //final TableViewInteger tableView = new TableView(sortedList); // row sorting not possible (FilteredList) //FilteredListInteger filteredList = new FilteredList(FXCollections.observableArrayList(2, 1, 3), (e) - true); //final TableViewInteger tableView = new TableView(filteredList ); // Don't forget to define columns! final TableColumnInteger, Number integerColumn = new TableColumn(Integer); final TableColumnInteger, String hexColumn = new TableColumn(Integer Hex); integerColumn.setCellValueFactory(javaClass - new SimpleLongProperty(javaClass.getValue())); hexColumn.setCellValueFactory(javaClass - new SimpleStringProperty(Integer.toHexString(javaClass.getValue(; tableView.getColumns().addAll(integerColumn, hexColumn); Any pointers on what I'm doing wrong or where I have to adapt my expectations. Is it correct that row sorting in a TableView is only possible for ordinary ObservableLists? With Regards Martin
Re: Swing and JavaFX thread merge
On 8/8/2013 1:45 AM, Jeff Martin wrote: I thought I was getting this automatically - when I run on my desktop, I can bring up a JOptionPane from a Swing thread and JFXPanels (correctly) block. But when I run from Java Web Start, they don't, and I end up with sporadic SwingUtilities.computeIntersection NullPointerException. Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). Is there a secret setting that has a different default with JAWS? NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? Thanks, Artem jeff On Aug 7, 2013, at 5:06 AM, Artem Ananiev artem.anan...@oracle.com wrote: Hi, Pedro Duque Vieira, this is in progress. JDK part is tracked in 8015477: http://bugs.sun.com/view_bug.do?bug_id=8015477 JavaFX part is described in RT-30694: https://javafx-jira.kenai.com/browse/RT-30694 Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. Thanks, Artem On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance,
hg: openjfx/8/graphics/rt: RT-31861: Examine commented-out thread checks in Glass
Changeset: 1d86b2b314e3 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-08-08 15:52 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1d86b2b314e3 RT-31861: Examine commented-out thread checks in Glass Reviewed-by: anthony, art ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java ! modules/graphics/src/main/java/com/sun/glass/ui/View.java ! modules/graphics/src/main/java/com/sun/glass/ui/Window.java
hg: openjfx/8/graphics/rt: RT-30694: Add support for a single threaded mode for FX/AWT interop
Changeset: c122b03b13e5 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-08-08 16:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c122b03b13e5 RT-30694: Add support for a single threaded mode for FX/AWT interop Reviewed-by: anthony, art, ant, snorthov ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java ! modules/swing/src/main/java/javafx/embed/swing/JFXPanel.java ! modules/swing/src/main/java/javafx/embed/swing/SwingFXUtils.java
Re: Swing and JavaFX thread merge
Hello. I've just pushed the fix to the repo, so it should be available in a couple of builds. However, it is an experimental feature, so we lack the documentation or examples on it. If you experience any issues with it - please contact me. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true) It's -Djavafx.embed.singleThread=true With best regards. Petr. On Aug 8, 2013, at 3:50 PM, Artem Ananiev wrote: On 8/8/2013 1:45 AM, Jeff Martin wrote: I thought I was getting this automatically - when I run on my desktop, I can bring up a JOptionPane from a Swing thread and JFXPanels (correctly) block. But when I run from Java Web Start, they don't, and I end up with sporadic SwingUtilities.computeIntersection NullPointerException. Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). Is there a secret setting that has a different default with JAWS? NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? Thanks, Artem jeff On Aug 7, 2013, at 5:06 AM, Artem Ananiev artem.anan...@oracle.com wrote: Hi, Pedro Duque Vieira, this is in progress. JDK part is tracked in 8015477: http://bugs.sun.com/view_bug.do?bug_id=8015477 JavaFX part is described in RT-30694: https://javafx-jira.kenai.com/browse/RT-30694 Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. Thanks, Artem On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance,
Re: Swing and JavaFX thread merge
It looks like this is specific to MacOSX 7u25+, if you run Java Inventor from the JAWS link on MacOSX (I'm using JVM 1.7.0_25 or 40-ea): prompt javaws http://reportmill.com/javi/javi1/JavaInventor1.jnlp Here are the steps: 1. Create New Project and Open 2. Click on large, animated New Java Starter File to bring up JOptionPane Then if you move the mouse around, you should see the other buttons on the screen still animate or illuminate in the FX thread. Whereas on 7u20 or Windows or non-JAWS launch, the JavaFX effects are not triggered while the modal panel is up. If you dismiss the option pane with the escape key and quickly re-click the New Starter File button repeatedly, eventually the SwingUtilities.computeIntersection NPE will manifest (sooner if you are doing a sales demo). Any thoughts on what would make the FX thread ignore the modal state in this configuration? jeff On Aug 8, 2013, at 6:50 AM, Artem Ananiev artem.anan...@oracle.com wrote: On 8/8/2013 1:45 AM, Jeff Martin wrote: I thought I was getting this automatically - when I run on my desktop, I can bring up a JOptionPane from a Swing thread and JFXPanels (correctly) block. But when I run from Java Web Start, they don't, and I end up with sporadic SwingUtilities.computeIntersection NullPointerException. Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). Is there a secret setting that has a different default with JAWS? NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? Thanks, Artem jeff On Aug 7, 2013, at 5:06 AM, Artem Ananiev artem.anan...@oracle.com wrote: Hi, Pedro Duque Vieira, this is in progress. JDK part is tracked in 8015477: http://bugs.sun.com/view_bug.do?bug_id=8015477 JavaFX part is described in RT-30694: https://javafx-jira.kenai.com/browse/RT-30694 Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. Thanks, Artem On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance,
Re: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
Richard, John and Tom thanks for your input. Also one more advantage I see if JavaFX complies with w3c CSS (on the things that count) is that CSS is a continuously evolving technology with a lot of people already working on it and evolving it (for instance, the broken layout system is being rewritten with things like the box model), if JavaFX follows along it will benefit from that web of knowledge. One misconception here is that there is any way for us to follow along for free. There is not an existing CSS engine that we can reuse. They are all heavily tied to their native C/C++ browser implementations and are all based on DOM nodes, not scene graph nodes. When the W3C or WhatWG adds new CSS capabilities, we don't get those for free, regardless of the syntax that we were to use. That's not what I meant. What I meant is that you build on the existing knowledge surrounding a technology that is meant to define the appearance of applications. Of course, unfortunately you can not build on the implementation. As for following the standard, we do intend to do that (and always have), at least insofar as it makes sense. But some things in Web CSS just don't make sense in the FX scene graph (layout being an obvious example, but some of the CSS selectors that allow you to insert dynamic nodes into the system don't directly map unless we were to implement it via FXML instead of HTML). Yes I would discard layout and inserting dynamic nodes as well. I'm talking about what already exists in JavaFX CSS and that does not follow the CSS specification. For instance: margins, effects, the -fx- prefix everywhere, etc.. There are clearly some decisions being made that go against the spec and not because it would be hard or more work to follow the spec. With others I can agree that it can be difficult to follow. @Tom Schindl: I'm not talking about only the CSS language, there is no such thing That is not correct. There is a CSS language (syntax) which is independent of the various specific pseudo-classes or declarations supported by a specific target (node type). You can find grammars on the internet. There is no CSS as language. You can talk about it, but CSS does not define only a language but also a bunch of properties: font, background and foreground colors, text properties, margins, etc, etc. Look at any CSS spec and you will find these. One of the problems is that JavaFX adds a -fx- prefix to every keyword, the use of this prefix was meant to distinguish experimental browser new specific features during their testing, experimentation period. This was during an experimental phase, and was meant to be dropped as soon as all browser implementations of that new feature work the same. As a practical matter, it is hard for the browsers to ever drop the extension syntax, they just add in the new standard (dropping the existing syntax breaks untold millions of websites).The same is true for FX, we can't drop the -fx- prefix. And in fact we *added* the -fx- prefix at the last minute before we shipped 2.0 (iirc). We didn't used to have the -fx- prefix for everything. The problem was the the CSS standard was a moving target, and we have to maintain compatibility, so we just put -fx- in front of everything to make sure that we wouldn't be burned (as we already had been once or twice) when the at-the-time unfinished CSS 3 backgrounds and borders specification changed out from under us. That's not correct. Vendor prefixes are meant to be temporary as they fragment the web (each browser having there own prefix and implementation of a property), there have already been prefixes that were dropped. Taken from the W3C CSS specification 3 ( http://www.w3.org/TR/css3-syntax/#vendor-specific): Although proprietary extensions should be avoided in general, there are situations (experiments, implementations of W3C drafts that have not yet reached Candidate Recommendation, intra-nets, debugging, etc.) where it is convenient to add some nonstandard, i.e., proprietary identifiers to a CSS style sheet. It is often hard to predict how long these proprietary extensions will be in use and hard to avoid that their names clash with new, standard properties or with other proprietary properties. Therefore the CSS Working Group proposes the following simple naming convention. A proprietary name should have a prefix consisting of... In fact, the reason we put in -fx- was *exactly* to allow us to have CSS-compliant non-fx- rules later on. Are you positively sure that your CSS implementation is compliant? I have serious doubts. In JavaFX by contrast, this was added for the purposes of being able to write in the same stylesheet file both web w3c css and JavaFX css without the 2 clashing into each other. That isn't really the reason why. It was so that we could be standards compliant. We shipped before the CSS 3 spec was completed, so we needed to use the vender extension prefix to
Re: Glass thread checks
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
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: Swing and JavaFX thread merge
Addendum: it turns out that the JOptionPane is not blocking any of the UI (Swing included). So maybe this isn't strictly a JavaFX problem. jeff On Aug 8, 2013, at 8:17 AM, Jeff Martin j...@reportmill.com wrote: It looks like this is specific to MacOSX 7u25+, if you run Java Inventor from the JAWS link on MacOSX (I'm using JVM 1.7.0_25 or 40-ea): prompt javaws http://reportmill.com/javi/javi1/JavaInventor1.jnlp Here are the steps: 1. Create New Project and Open 2. Click on large, animated New Java Starter File to bring up JOptionPane Then if you move the mouse around, you should see the other buttons on the screen still animate or illuminate in the FX thread. Whereas on 7u20 or Windows or non-JAWS launch, the JavaFX effects are not triggered while the modal panel is up. If you dismiss the option pane with the escape key and quickly re-click the New Starter File button repeatedly, eventually the SwingUtilities.computeIntersection NPE will manifest (sooner if you are doing a sales demo). Any thoughts on what would make the FX thread ignore the modal state in this configuration? jeff On Aug 8, 2013, at 6:50 AM, Artem Ananiev artem.anan...@oracle.com wrote: On 8/8/2013 1:45 AM, Jeff Martin wrote: I thought I was getting this automatically - when I run on my desktop, I can bring up a JOptionPane from a Swing thread and JFXPanels (correctly) block. But when I run from Java Web Start, they don't, and I end up with sporadic SwingUtilities.computeIntersection NullPointerException. Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). Is there a secret setting that has a different default with JAWS? NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? Thanks, Artem jeff On Aug 7, 2013, at 5:06 AM, Artem Ananiev artem.anan...@oracle.com wrote: Hi, Pedro Duque Vieira, this is in progress. JDK part is tracked in 8015477: http://bugs.sun.com/view_bug.do?bug_id=8015477 JavaFX part is described in RT-30694: https://javafx-jira.kenai.com/browse/RT-30694 Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. Thanks, Artem On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance,
Re: current state of gradle script for Android?
Summer vacation stuff with my family is sucking up all my free time. School starts in two weeks so I should be off the hook soon. On Aug 8, 2013 5:14 AM, tomas.brandalik tomas.branda...@oracle.com wrote: Hi, I have hardly any info about the project jfx78 backport and its status. I've just had a look at it and saw that last sync happened in beginning of July. It's good if somebody is willing to put his effort into that. In order to run on dalvik we need to compile jfx with jdk1.6 (I suppose 1.7 would do as well). Then there will be some packages missing for example java.beans or sun.misc but it could be fixed somehow. -Tomas On 08/08/2013 10:05 AM, Tobias Bley wrote: Hi Tomas, yes, I was able to build JavaFX for Android, but I would like to start JavaFX on Dalvik…You said its necessary to update the jfx78 backport to the latest openjfx code changes…? btw: I just saw your very interesting JavaOne track ;) Am 08.08.2013 um 09:59 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Tobi, shouldn't be necessary to patch android.gradle file or set ANDROID_CROSS_TOOLS_VER anymore. The latest changes resolve path to a toolchain taking into account variants of NDK. Thank you for testing it. -Tomas On 08/01/2013 11:41 PM, Tobias Bley wrote: Thanks Tomas, after changing android.gradle script line defineProperty(ANDROID_**CROSS_TOOLS_VER, arm-linux-androideabi-4.4.3“)**“ to defineProperty(ANDROID_**CROSS_TOOLS_VER, arm-linux-androideabi-4.6“)“ and def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? macosx : linux-x86““ to „def toolsPlatform = IS_WINDOWS ? windows : IS_MAC ? darwin-x86_64 : linux-x86““ I could successfully build OpenJFX for Android von Mac OS X 10.9! So now I’m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in „com.oracle.dalvik“ package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? Best regards, Tobi Am 01.08.2013 um 16:00 schrieb tomas.brandalik tomas.branda...@oracle.com: The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. http://developer.android.com/**sdk/index.htmlhttp://developer.android.com/sdk/index.html http://developer.android.com/**tools/sdk/ndk/index.htmlhttp://developer.android.com/tools/sdk/ndk/index.html -Tomas On 08/01/2013 03:41 PM, Tobias Bley wrote: Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? Thanks! Tobi Am 31.07.2013 um 16:42 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Tobi, it works on linux only right now. Set properties for cross build and android sdk/ndk. -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-**sdk-linux -PANDROID_NDK=/opt/android-**ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true Closed source parts web and font-t2k will be missing. -Tomas On 07/29/2013 11:22 PM, Tobias Bley wrote: Hi, can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? Best regards, Tobi
hg: openjfx/8/graphics/rt: Adding vi .swp files to .hgignore
Changeset: d045f3d461de Author:ddhill Date: 2013-08-08 13:23 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d045f3d461de Adding vi .swp files to .hgignore ! .hgignore
hg: openjfx/8/graphics/rt: RT-31962: Window Display all black and can't restore
Changeset: c3890f1ae2a1 Author:kcr Date: 2013-08-08 10:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c3890f1ae2a1 RT-31962: Window Display all black and can't restore ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PresentingPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java
hg: openjfx/8/graphics/rt: RT-30449 FX 8 3D: Need to handle mirror transformation (flip culling)
Changeset: ae7b09388ec2 Author:Yao Wang yao.w.w...@oracle.com Date: 2013-08-08 11:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ae7b09388ec2 RT-30449 FX 8 3D: Need to handle mirror transformation (flip culling) ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/prism/es2/ES2Context.java
Re: Swing and JavaFX thread merge
So I found a workaround, though I don't understand the why of the problem or
workaround.
What I found was that on MacOSX 7u25+, my app mainSwing() (executed via
invokeLater() from main()) was being called on AWT-EventQueue-2 from the JAWS
startup thread (javawsApplicationMain) instead of AWT-EventQueue-0. So I added
code to force JavaFX init, switch over to the FX thread, and switch back to
Swing, which is then AWT-EventQueue-0:
if(Thread.currentThread().getName().equals(AWT-EventQueue-2)) {
new JFXPanel();
Platform.runLater(new Runnable() { public void run() {
SwingUtilities.invokeLater(new Runnable() { public void
run() {
mainSwing(args); }}); }});
return;
}
And now my JOptionPane correctly blocks events outside of the dialog!
jeff
On Aug 8, 2013, at 9:56 AM, Jeff Martin j...@reportmill.com wrote:
Addendum: it turns out that the JOptionPane is not blocking any of the UI
(Swing included). So maybe this isn't strictly a JavaFX problem.
jeff
On Aug 8, 2013, at 8:17 AM, Jeff Martin j...@reportmill.com wrote:
It looks like this is specific to MacOSX 7u25+, if you run Java Inventor
from the JAWS link on MacOSX (I'm using JVM 1.7.0_25 or 40-ea):
prompt javaws http://reportmill.com/javi/javi1/JavaInventor1.jnlp
Here are the steps:
1. Create New Project and Open
2. Click on large, animated New Java Starter File to bring up
JOptionPane
Then if you move the mouse around, you should see the other buttons on the
screen still animate or illuminate in the FX thread. Whereas on 7u20 or
Windows or non-JAWS launch, the JavaFX effects are not triggered while the
modal panel is up. If you dismiss the option pane with the escape key and
quickly re-click the New Starter File button repeatedly, eventually the
SwingUtilities.computeIntersection NPE will manifest (sooner if you are
doing a sales demo).
Any thoughts on what would make the FX thread ignore the modal state in this
configuration?
jeff
On Aug 8, 2013, at 6:50 AM, Artem Ananiev artem.anan...@oracle.com wrote:
On 8/8/2013 1:45 AM, Jeff Martin wrote:
I thought I was getting this automatically - when I run on my
desktop, I can bring up a JOptionPane from a Swing thread and
JFXPanels (correctly) block. But when I run from Java Web Start, they
don't, and I end up with sporadic SwingUtilities.computeIntersection
NullPointerException.
Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you
described will work. As I wrote, it won't work by default in JDK8, you'll
need to run your app with certain system property (something like
-Djavafx.swing.singlethreaded=true).
Is there a secret setting that has a different default with JAWS?
NPEs look like a bug, either in AWT/FX, or in your application. I really
doubt it's related to Java Web Start. Could you provide a test to reproduce
the exceptions, please?
Thanks,
Artem
jeff
On Aug 7, 2013, at 5:06 AM, Artem Ananiev artem.anan...@oracle.com wrote:
Hi, Pedro Duque Vieira,
this is in progress. JDK part is tracked in 8015477:
http://bugs.sun.com/view_bug.do?bug_id=8015477
JavaFX part is described in RT-30694:
https://javafx-jira.kenai.com/browse/RT-30694
Note that in JDK8/JavaFX8 single-threaded mode will not be a part of
public API, it will be an experimental feature.
Thanks,
Artem
On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote:
Hi,
Some time ago there was a patch submitted which for all purposes merged
the
swing and javafx thread, making it easier for developers working on a
swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX
Is this available now (I was under the impression it is)? How do I use
it?
Thanks in advance,
hg: openjfx/8/graphics/rt: RT-32224: restore Window.add/remove methods needed by Lens native
Changeset: e916bc90eb67 Author:ddhill Date: 2013-08-08 15:32 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e916bc90eb67 RT-32224: restore Window.add/remove methods needed by Lens native ! modules/graphics/src/main/java/com/sun/glass/ui/Window.java
Re: Rowsorting of TableView with SortedList/FilteredList
Funny you should ask about this - I just blogged about SortedList and TableView the other day, over at FXExperience: http://fxexperience.com/2013/08/returning-a-tableview-back-to-an-unsorted-state-in-javafx-8-0 Of course, I can see that you've already read that post (I see a comment from the code in my post in your code below). What might have been missed is that I noted earlier on in the blog post I had to make a few small changes to properly get SortedList support in TableView, so you'll want to try again in b102 (or b103). Regarding your use of FilteredList as well - I've not tried this at all, but I'll add it to my todo list to investigate today. I imagine there might be a bug somewhere. Whatever I find will probably make for a good post at FXExperience, so keep an eye out there too. Thanks, and if you do run into further issues, please don't hesitate to file bugs. In general, if TableView isn't sorting then something is going really wrong! -- Jonathan On 8/08/2013 11:17 p.m., Martin Klähn wrote: Hi guys, I'm working on a business application that makes use of TableView and I'm working with JDK 8 build b101. Displaying the data works like a charm. Row sorting for ordinary ObservableLists is fine too. Then I've set TableView.items to FilteredList and row sorting was disabled. replacing TableView.item with SortedList does not allow row sorting as well. Binding the comparator of SortedList to the TableView.comparator has no effect either. // row sorting possible //final TableViewInteger tableView = new TableView(FXCollections.observableArrayList(2, 1, 3)); // row sorting not possible (SortedList) // create a TableView with the sorted list set as the items it will show // bind the sortedList comparator to the TableView comparator //SortedListInteger sortedList = new SortedList(FXCollections.observableArrayList(2, 1, 3)); //sortedList.comparatorProperty().bind(tableView.comparatorProperty()); //final TableViewInteger tableView = new TableView(sortedList); // row sorting not possible (FilteredList) //FilteredListInteger filteredList = new FilteredList(FXCollections.observableArrayList(2, 1, 3), (e) - true); //final TableViewInteger tableView = new TableView(filteredList ); // Don't forget to define columns! final TableColumnInteger, Number integerColumn = new TableColumn(Integer); final TableColumnInteger, String hexColumn = new TableColumn(Integer Hex); integerColumn.setCellValueFactory(javaClass - new SimpleLongProperty(javaClass.getValue())); hexColumn.setCellValueFactory(javaClass - new SimpleStringProperty(Integer.toHexString(javaClass.getValue(; tableView.getColumns().addAll(integerColumn, hexColumn); Any pointers on what I'm doing wrong or where I have to adapt my expectations. Is it correct that row sorting in a TableView is only possible for ordinary ObservableLists? With Regards Martin
hg: openjfx/8/graphics/rt: SWT glass: trivial fix to enable menu bar on mac
Changeset: 3371ead571da Author:snorthov Date: 2013-08-08 16:34 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3371ead571da SWT glass: trivial fix to enable menu bar on mac ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTApplication.java
RE: JavaFX Media issues
JavaFX 2.2 does http live streaming: http://docs.oracle.com/javafx/2/media/overview.htm HTTP Live Streaming Support With the addition of HTTP live streaming support, you can now download the playlist file and playback video or audio segments using JavaFX Media. Media players are now able to switch to alternate streams, as specified in the playlist file and based on network conditions. For a given stream, there is a playlist file and a set of segments into which the stream is broken. The stream can be either an MP3 raw stream or an MPEG-TS containing multiplexed AAC audio and H.264 video. The stream can be played on demand when the stream is a static file or played live when the stream is actually a live feed. In both cases, the stream can adjust its bit rate and for video, its resolution can be adjusted. More info on HTTP Live Streaming: http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/Introduction/Introduction.html Your other questions, the JavaFX media devs can answer. -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Felix Bembrick Sent: Thursday, August 08, 2013 1:32 PM To: openjfx-dev@openjdk.java.net List Subject: JavaFX Media issues I am having a look at JavaFX media support and have a couple of questions: 1. It seems that the only way to load media files is by specifying a source such as a file path etc. This is not going to work well for me as all of my application's content (which includes data, digital assets, media etc.) is stored in a database on the server and is loaded through an IO stream. Why doesn't Media support loading of files through a stream? That would seem like a common use case to me! 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for JDK 8 which I found here: http://download.java.net/jdk8/jfxdocs/index.html Is this just a glitch? 3. Is buffering of media something planned for the future in JavaFX? 4. What about live streaming of media content? Thanks, Felix
Re: JavaFX Media issues
I am having a look at JavaFX media support and have a couple of questions: 1. It seems that the only way to load media files is by specifying a source such as a file path etc. This is not going to work well for me as all of my application's content (which includes data, digital assets, media etc.) is stored in a database on the server and is loaded through an IO stream. Why doesn't Media support loading of files through a stream? That would seem like a common use case to me! I will have to let the media guys chime in, I don't know why we don't support a stream. At one time Image had the same limitation but we added stream support for it, so it might just be oversight. One thing to suggest is that you can install your own URL content handlers / protocols in Java. So if your URL said myapp://nameofvideo.mov or whatever, you can install a myapp protocol handler with Java which is responsible for creating the InputStream. This way you can still had us a url and we can get back your input stream, even from a custom source such as a Database. 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for JDK 8 which I found here: http://download.java.net/jdk8/jfxdocs/index.html Is this just a glitch? Probably got blown up during the gradle switch. Can you please file a bug (in the build component) 3. Is buffering of media something planned for the future in JavaFX? 4. What about live streaming of media content? Kirill should have more information here. Thanks! Richard
RE: JavaFX Media issues
One thing to suggest is that you can install your own URL content handlers / protocols in Java. That won't help in this case unless you replaced the http, file or jar protocol handlers, which would be weird. Only HTTP, FILE, and JAR URLs are supported. http://docs.oracle.com/javafx/2/api/javafx/scene/media/Media.html#Media%28java.lang.String%29 -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Richard Bair Sent: Thursday, August 08, 2013 1:57 PM To: Felix Bembrick Cc: openjfx-dev@openjdk.java.net List Subject: Re: JavaFX Media issues I am having a look at JavaFX media support and have a couple of questions: 1. It seems that the only way to load media files is by specifying a source such as a file path etc. This is not going to work well for me as all of my application's content (which includes data, digital assets, media etc.) is stored in a database on the server and is loaded through an IO stream. Why doesn't Media support loading of files through a stream? That would seem like a common use case to me! I will have to let the media guys chime in, I don't know why we don't support a stream. At one time Image had the same limitation but we added stream support for it, so it might just be oversight. One thing to suggest is that you can install your own URL content handlers / protocols in Java. So if your URL said myapp://nameofvideo.mov or whatever, you can install a myapp protocol handler with Java which is responsible for creating the InputStream. This way you can still had us a url and we can get back your input stream, even from a custom source such as a Database. 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for JDK 8 which I found here: http://download.java.net/jdk8/jfxdocs/index.html Is this just a glitch? Probably got blown up during the gradle switch. Can you please file a bug (in the build component) 3. Is buffering of media something planned for the future in JavaFX? 4. What about live streaming of media content? Kirill should have more information here. Thanks! Richard
Re: Developing controls based on Canvas?
Felix, As you are restricted in what you can say, that also restricts how I can help. However, your example of a spreadsheet not being a control that can be implemented in a scenegraph-based manner suggests that you might want to re-evaluate your assumptions. A spreadsheet would be able to be implemented in a scenegraph approach quite nicely - the TableView control comes quite close to that already (especially in JavaFX 8.0 where it can virtualise in both vertical and horizontal directions). In fact, I know of at least two spreadsheet implementations that already exist in JavaFX based on a scenegraph approach. As I've said elsewhere, the issues you are facing are because of merging two approaches (retained and immediate modes) into one control. What you are hoping to do is have your cake and eat it too, which unfortunately I don't think will end up too well for you :-) My advice is to recheck your assumptions - the scenegraph approach, in my opinion, should suit your requirements far more than an immediate mode approach (given that your requirement is to reuse existing scenegraph-based controls). I'm not sure why you think controls must be defined in a static, structured way. You could put all nodes of a control into a single Pane (or Region, etc) layout and layout all the nodes using absolute positioning. You can be as dynamic as you want to be. Unfortunately, without more information I am really unable to give any further advice, but I wish you good luck in whichever approach you decide to take. -- Jonathan On 9/08/2013 9:02 a.m., Felix Bembrick wrote: Hi Jonathan, Thanks for your reply. I am a little restricted in exactly what I can reveal about my plans for this control but I can say that it is one in which its very appearance could change quite significantly in a dynamic way at runtime. The control also needs to support panning and zooming in a very performant way. There will likely be a lot of graphics being draw in a manner which (to me at least) fits the immediate mode of rendering better than a scenegraph because their positions and attributes are most readily defined programmatically rather than declaratively. Though not directly analogous, consider your typical spreadsheet application like Excel where the user is able to pan to the right effectively without limits and that grid lines are constantly being rendered as the panning takes place. Given that screens can be very large these days it is conceivable that a complex spreadsheet will be displaying hundreds of lines to define the cells in a grid at any one time and that it is way more concise to programmatically define how this grid is rendered rather than having a scenegraph containing a node for each line etc. Also, the panning and zooming responses are much simpler to implement programmatically than continually fiddling around with the scenegraph. Then there's the whole issue of virtualisation and keeping the actual number of active nodes to a minimum if it were to be done using a scenegraph. I am just not convinced that the costs of memory usage and processing cycles to maintain a retained mode representation of a visual structure like this can be justified or made performant when all you really need is a simple algorithm that draws lines on the screen according to the properties of your cell model. Then consider that the *actual* control will be significantly more complex and graphically rich than this simplistic spreadsheet analogy. To me this is the sort of control that really lends itself to an immediate mode rendering component such as Canvas but there just seem to be so many impediments in the way of actually building a professional control with Canvas at its base. If we continue with the spreadsheet analogy then obviously cells would contain other controls etc. and we have discussed the limitations on embedding other controls within a Canvas that seems to suggest it's not practical. I think in the end it gets down to the nature of the control itself and whether its appearance is best defined by data or by an algorithm just like the way certain types of knowledge are best defined by nouns whereas others are best defined procedurally. At this stage it is looking very much as though JavaFX really only supports controls most appropriately defined in a static, structured way like a scenegraph. This in turns limits its applicability to a whole range of software applications. Felix On 6 August 2013 10:10, Jonathan Giles jonathan.gi...@oracle.com mailto:jonathan.gi...@oracle.com wrote: I think it would pay to take a step back and understand why you think a 'traditional' scenegraph-based (or retained mode) control is not sufficient for your needs? Unfortunately you've not detailed your use case, so it is hard to give any specific advice. Are you able to give any details about what it is you're trying to build and why you
Re: Developing controls based on Canvas?
Though not directly analogous, consider your typical spreadsheet application like Excel where the user is able to pan to the right effectively without limits and that grid lines are constantly being rendered as the panning takes place. Given that screens can be very large these days it is conceivable that a complex spreadsheet will be displaying hundreds of lines to define the cells in a grid at any one time and that it is way more concise to programmatically define how this grid is rendered rather than having a scenegraph containing a node for each line etc. Also, the panning and zooming responses are much simpler to implement programmatically than continually fiddling around with the scenegraph. Then there's the whole issue of virtualisation and keeping the actual number of active nodes to a minimum if it were to be done using a scenegraph. Actually I would have thought that panning / zooming would be very simple with a scene graph based approach. The difficult part is the virtualization. Although if you were building a spreadsheet like control it seems like you could build it on top of the ListView, which would give you vertical virtualization for free. You're then left with horizontal virtualization. I suppose you could use horizontal list views for that as well if you didn't want to implement your own virtualization (which might be much more efficient with domain knowledge). If you know that you're grid will always be drawn underneath the other controls, then it seems reasonable to use a Canvas (or MeshView) to implement the grid, and then position controls on top of the grid as appropriate. I don't really see it as being any more difficult than immediate mode, really. YOu have a pool of Labels or whatever, grab one from the pool, position it where you want it, do the next one, etc. Heck, you could have a GraphicsContext interface with drawString(x, y, String) that handles all this behind an abstraction. All you're doing is positioning and defining content, right? Richard
PrefWidth/Height calculations only works if stage is shown
Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
Re: PrefWidth/Height calculations only works if stage is shown
Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. Richard On Aug 8, 2013, at 2:26 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
Re: Developing controls based on Canvas?
T hanks Jonathan. I'll have to check out the virtualisation that you refer to that's going on in JavaFX8 with TableView., it sounds very interesting. I am not saying that controls such as what I am proposing are *impossible* to implement using a scenegraph; it just seems natural to implement them in a more procedural/programmatic way but this could very possibly just be because I do not have a full grasp of the capabilities of the scenegraph and what can be achieved by manipulating it. To me it seems that the costs of repeatedly creating nodes (or hopefully reusing them), potentially restructuring the hierarchy of nodes in the scenegraph and adjusting each node's properties to enable a truly dynamic control would logically be much greater than just cycling through a render loop and rendering each graphic element in its correct location but, again, you seem very confident that these costs are not significant enough to prevent such a control performing well. In the end if I can get away with a scenegraph representation of this control and that massaging said scenegraph is performant enough then I am in a happy place. I have already observed that some nice stuff can happen just by playing around the scenegraph so it is quite possible that I am worrying about performance and memory issues that will never actually eventuate in practice. Felix On 9 August 2013 07:16, Jonathan Giles jonathan.gi...@oracle.com wrote: Felix, As you are restricted in what you can say, that also restricts how I can help. However, your example of a spreadsheet not being a control that can be implemented in a scenegraph-based manner suggests that you might want to re-evaluate your assumptions. A spreadsheet would be able to be implemented in a scenegraph approach quite nicely - the TableView control comes quite close to that already (especially in JavaFX 8.0 where it can virtualise in both vertical and horizontal directions). In fact, I know of at least two spreadsheet implementations that already exist in JavaFX based on a scenegraph approach. As I've said elsewhere, the issues you are facing are because of merging two approaches (retained and immediate modes) into one control. What you are hoping to do is have your cake and eat it too, which unfortunately I don't think will end up too well for you :-) My advice is to recheck your assumptions - the scenegraph approach, in my opinion, should suit your requirements far more than an immediate mode approach (given that your requirement is to reuse existing scenegraph-based controls). I'm not sure why you think controls must be defined in a static, structured way. You could put all nodes of a control into a single Pane (or Region, etc) layout and layout all the nodes using absolute positioning. You can be as dynamic as you want to be. Unfortunately, without more information I am really unable to give any further advice, but I wish you good luck in whichever approach you decide to take. -- Jonathan On 9/08/2013 9:02 a.m., Felix Bembrick wrote: Hi Jonathan, Thanks for your reply. I am a little restricted in exactly what I can reveal about my plans for this control but I can say that it is one in which its very appearance could change quite significantly in a dynamic way at runtime. The control also needs to support panning and zooming in a very performant way. There will likely be a lot of graphics being draw in a manner which (to me at least) fits the immediate mode of rendering better than a scenegraph because their positions and attributes are most readily defined programmatically rather than declaratively. Though not directly analogous, consider your typical spreadsheet application like Excel where the user is able to pan to the right effectively without limits and that grid lines are constantly being rendered as the panning takes place. Given that screens can be very large these days it is conceivable that a complex spreadsheet will be displaying hundreds of lines to define the cells in a grid at any one time and that it is way more concise to programmatically define how this grid is rendered rather than having a scenegraph containing a node for each line etc. Also, the panning and zooming responses are much simpler to implement programmatically than continually fiddling around with the scenegraph. Then there's the whole issue of virtualisation and keeping the actual number of active nodes to a minimum if it were to be done using a scenegraph. I am just not convinced that the costs of memory usage and processing cycles to maintain a retained mode representation of a visual structure like this can be justified or made performant when all you really need is a simple algorithm that draws lines on the screen according to the properties of your cell model. Then consider that the *actual* control will be significantly more complex and graphically rich than this simplistic spreadsheet analogy. To me this
Re: PrefWidth/Height calculations only works if stage is shown
No same result! BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); g.impl_reapplyCSS(); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); Could it be that this does not work because if a stage is not yet shown the peers have not been created? Tom On 08.08.13 23:29, Richard Bair wrote: Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. Richard On Aug 8, 2013, at 2:26 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
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?
Automatic virtualisation (was Developing controls based on Canvas?)
With all this talk of node virtualisation, I am wondering how feasible it would to build some kind of automatic virtualiser such that you pass it your real-world model and then it automagically works out the actual nodes and pools required and manages them seamlessly to maximise rendering performance and responsiveness? That is, it determines how many nodes will be visible at any one time and just manages all that stuff for you completely under the hood. Maybe Jonanthan you have come some way to building such a beast with your work on bidirectional virtualisation in FX 8 TableView or other controls? Felix On 9 August 2013 07:31, Felix Bembrick felix.bembr...@gmail.com wrote: T hanks Jonathan. I'll have to check out the virtualisation that you refer to that's going on in JavaFX8 with TableView., it sounds very interesting. I am not saying that controls such as what I am proposing are *impossible* to implement using a scenegraph; it just seems natural to implement them in a more procedural/programmatic way but this could very possibly just be because I do not have a full grasp of the capabilities of the scenegraph and what can be achieved by manipulating it. To me it seems that the costs of repeatedly creating nodes (or hopefully reusing them), potentially restructuring the hierarchy of nodes in the scenegraph and adjusting each node's properties to enable a truly dynamic control would logically be much greater than just cycling through a render loop and rendering each graphic element in its correct location but, again, you seem very confident that these costs are not significant enough to prevent such a control performing well. In the end if I can get away with a scenegraph representation of this control and that massaging said scenegraph is performant enough then I am in a happy place. I have already observed that some nice stuff can happen just by playing around the scenegraph so it is quite possible that I am worrying about performance and memory issues that will never actually eventuate in practice. Felix On 9 August 2013 07:16, Jonathan Giles jonathan.gi...@oracle.com wrote: Felix, As you are restricted in what you can say, that also restricts how I can help. However, your example of a spreadsheet not being a control that can be implemented in a scenegraph-based manner suggests that you might want to re-evaluate your assumptions. A spreadsheet would be able to be implemented in a scenegraph approach quite nicely - the TableView control comes quite close to that already (especially in JavaFX 8.0 where it can virtualise in both vertical and horizontal directions). In fact, I know of at least two spreadsheet implementations that already exist in JavaFX based on a scenegraph approach. As I've said elsewhere, the issues you are facing are because of merging two approaches (retained and immediate modes) into one control. What you are hoping to do is have your cake and eat it too, which unfortunately I don't think will end up too well for you :-) My advice is to recheck your assumptions - the scenegraph approach, in my opinion, should suit your requirements far more than an immediate mode approach (given that your requirement is to reuse existing scenegraph-based controls). I'm not sure why you think controls must be defined in a static, structured way. You could put all nodes of a control into a single Pane (or Region, etc) layout and layout all the nodes using absolute positioning. You can be as dynamic as you want to be. Unfortunately, without more information I am really unable to give any further advice, but I wish you good luck in whichever approach you decide to take. -- Jonathan On 9/08/2013 9:02 a.m., Felix Bembrick wrote: Hi Jonathan, Thanks for your reply. I am a little restricted in exactly what I can reveal about my plans for this control but I can say that it is one in which its very appearance could change quite significantly in a dynamic way at runtime. The control also needs to support panning and zooming in a very performant way. There will likely be a lot of graphics being draw in a manner which (to me at least) fits the immediate mode of rendering better than a scenegraph because their positions and attributes are most readily defined programmatically rather than declaratively. Though not directly analogous, consider your typical spreadsheet application like Excel where the user is able to pan to the right effectively without limits and that grid lines are constantly being rendered as the panning takes place. Given that screens can be very large these days it is conceivable that a complex spreadsheet will be displaying hundreds of lines to define the cells in a grid at any one time and that it is way more concise to programmatically define how this grid is rendered rather than having a scenegraph containing a node for each line etc. Also, the panning and zooming responses are much
Re: PrefWidth/Height calculations only works if stage is shown
The peers don't impact the preferred sizes at all. Use this one instead of impl_reapplyCSS (wrong one) impl_processCSS(true) On Aug 8, 2013, at 2:35 PM, Tom Schindl tom.schi...@bestsolution.at wrote: No same result! BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); g.impl_reapplyCSS(); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); Could it be that this does not work because if a stage is not yet shown the peers have not been created? Tom On 08.08.13 23:29, Richard Bair wrote: Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. Richard On Aug 8, 2013, at 2:26 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
Re: PrefWidth/Height calculations only works if stage is shown
Prefect! Tom On 08.08.13 23:40, Richard Bair wrote: The peers don't impact the preferred sizes at all. Use this one instead of impl_reapplyCSS (wrong one) impl_processCSS(true) On Aug 8, 2013, at 2:35 PM, Tom Schindl tom.schi...@bestsolution.at wrote: No same result! BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); g.impl_reapplyCSS(); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); Could it be that this does not work because if a stage is not yet shown the peers have not been created? Tom On 08.08.13 23:29, Richard Bair wrote: Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. Richard On Aug 8, 2013, at 2:26 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
Re: How to raise JavaFX iOS bugs?
No, I didn't get a chance. Probably easier for you to just raise it now? 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?
Chart CategoryView - setLowerBound(...) and setUpperBound(...)
Hi, I already posted this question on the JavaFX forum but got no answer. I have a chart with a CategoryAxis for the x values and a NumberAxis for the y values. I want to enable zooming in this chart. For the NumberAxis I'm planing to use the setLowerBound(...) and setUpperBound(...) methods to zoom in the particular region the user has chosen. But for the CategoryAxis I don't see any method similar to these ones. How can I do this? (I'm using JavaFX8) Thanks in advance, -- Pedro Duque Vieira
Re: JavaFX Media issues
Scott, That JIRA issue doesn't make any mention of getting hooks into pixel data etc., it only refers to user defined codecs. Maybe you could open another issue to manage the wishlist of missing features such as the ones you referred to? I too would very much like to see greatly improved media support in JavaFX. Felix On 9 August 2013 10:10, Scott Palmer swpal...@gmail.com wrote: The Media APIs are mostly useless in their current state. Other than demoing that you can play a video, they don't go far enough to be of practical value. I tried to get someone to pay attention to them back in the JavaFX 1.0 days https://javafx-jira.kenai.com/browse/RT-2684 at least someone listened to the request to get H.264 support in there, but that is just a workaround. We need to be able to get our data into the media pipeline. This would allow those of us that have attempted to do a video window to have a fighting chance. Canvas can't keep up and will likely crash the app with out of memory errors. Support for drawing into a native surface (OpenGL or D3D context) has been talked about, but doesn't appear to be on the horizon yet. If we just had a hook to get the dang pixel data into the media pipeline so we could supply the next frame with whatever we want - either from any native codec via JNI, or dynamically generated from Java code, whatever... that would be just so dang useful... (to me at least) Regards, Scott On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn joe.mcgl...@oracle.com wrote: I don't know why FX Media isn't in the FX 8 API docs, but that's clearly an error. Please file a bug on that. In the meantime, you should look at the FX 2 media docs, there isn't a lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live Streaming) are both supported, as is playback from a URL. What is the strategy for codecs? I mean, now we have ImageIO (there is also JAI but it seems basically dead). ImageIO provides many image codecs and there's a SPI that can be used to support more formats. Will it be replaced by FX2 media or co-exist with it? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/**blog http://tidalwave.it/fabrizio/blog- fabrizio.giud...@tidalwave.it
Re: JavaFX Media issues
The Media APIs are mostly useless in their current state. Other than demoing that you can play a video, they don't go far enough to be of practical value. I tried to get someone to pay attention to them back in the JavaFX 1.0 days https://javafx-jira.kenai.com/browse/RT-2684 at least someone listened to the request to get H.264 support in there, but that is just a workaround. We need to be able to get our data into the media pipeline. This would allow those of us that have attempted to do a video window to have a fighting chance. Canvas can't keep up and will likely crash the app with out of memory errors. Support for drawing into a native surface (OpenGL or D3D context) has been talked about, but doesn't appear to be on the horizon yet. If we just had a hook to get the dang pixel data into the media pipeline so we could supply the next frame with whatever we want - either from any native codec via JNI, or dynamically generated from Java code, whatever... that would be just so dang useful... (to me at least) Regards, Scott On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn joe.mcgl...@oracle.com wrote: I don't know why FX Media isn't in the FX 8 API docs, but that's clearly an error. Please file a bug on that. In the meantime, you should look at the FX 2 media docs, there isn't a lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live Streaming) are both supported, as is playback from a URL. What is the strategy for codecs? I mean, now we have ImageIO (there is also JAI but it seems basically dead). ImageIO provides many image codecs and there's a SPI that can be used to support more formats. Will it be replaced by FX2 media or co-exist with it? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/**blog http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX Media issues
I don't want to detract from the issues around media stuff (they are significant), but if you are desperate (as I was), here's some code for doing video capture and streaming based on LTI-CIVIL and writing to JFX image to render the video: - https://code.google.com/p/jfxcamera/ It's a work around and not elegant at all, and media needs to have a lot done to be useful. I only include it here in case there is something useful you can take from it to hobble through. On Fri, Aug 9, 2013 at 10:10 AM, Scott Palmer swpal...@gmail.com wrote: The Media APIs are mostly useless in their current state. Other than demoing that you can play a video, they don't go far enough to be of practical value. I tried to get someone to pay attention to them back in the JavaFX 1.0 days https://javafx-jira.kenai.com/browse/RT-2684 at least someone listened to the request to get H.264 support in there, but that is just a workaround. We need to be able to get our data into the media pipeline. This would allow those of us that have attempted to do a video window to have a fighting chance. Canvas can't keep up and will likely crash the app with out of memory errors. Support for drawing into a native surface (OpenGL or D3D context) has been talked about, but doesn't appear to be on the horizon yet. If we just had a hook to get the dang pixel data into the media pipeline so we could supply the next frame with whatever we want - either from any native codec via JNI, or dynamically generated from Java code, whatever... that would be just so dang useful... (to me at least) Regards, Scott On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici fabrizio.giud...@tidalwave.it wrote: On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn joe.mcgl...@oracle.com wrote: I don't know why FX Media isn't in the FX 8 API docs, but that's clearly an error. Please file a bug on that. In the meantime, you should look at the FX 2 media docs, there isn't a lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live Streaming) are both supported, as is playback from a URL. What is the strategy for codecs? I mean, now we have ImageIO (there is also JAI but it seems basically dead). ImageIO provides many image codecs and there's a SPI that can be used to support more formats. Will it be replaced by FX2 media or co-exist with it? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/**blog http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: JavaFX Media issues
On 9/08/2013 02:10, Scott Palmer wrote:
The Media APIs are mostly useless in their current state. Other than
demoing that you can play a video, they don't go far enough to be of
practical value. I tried to get someone to pay attention to them back in
the JavaFX 1.0 days
https://javafx-jira.kenai.com/browse/RT-2684
Unfortunately, I have to agree here. I'd love to use the Media APIs of
JavaFX, but they are way to limited. At a minimum I'd need support for
MKV containers and some common audio formats used with these. Decoding
AVI containers would be rather important as well. Without those, JavaFX
video is basically limited to bring your own videos only and
completely unsuitable for playing back videos that end users might have...
Instead, I've been using VLC + VLCJ from day one while working with
JavaFX as a work-around.
at least someone listened to the request to get H.264 support in there, but
that is just a workaround. We need to be able to get our data into the
media pipeline. This would allow those of us that have attempted to do a
video window to have a fighting chance. Canvas can't keep up and will
likely crash the app with out of memory errors. Support for drawing into a
native surface (OpenGL or D3D context) has been talked about, but doesn't
appear to be on the horizon yet. If we just had a hook to get the dang
pixel data into the media pipeline so we could supply the next frame with
whatever we want - either from any native codec via JNI, or dynamically
generated from Java code, whatever... that would be just so dang useful...
(to me at least)
This would atleast allow me to decode the MKV container myself and
supply data... not looking forward to having to write all that code, but
I would if it meant I'd be able to go native JavaFX with video.
Canvas however is working for me even with HD video (copying 25
frames/sec of HD video from VLCJ to Canvas). Playback is smooth even
with 1920x1080 video for hours long video, and I can't tell the
difference with a native player or copying frame by frame using
pixelWriter anymore. There is some CPU penalty but on a my system it is
well below 5%. This is basically how that looks with VLCJ:
new RenderCallback() {
@Override
public void display(DirectMediaPlayer mp, Memory[] memory,
final BufferFormat bufferFormat) {
final ByteBuffer byteBuffer = memory[0].getByteBuffer(0,
memory[0].size());
Platform.runLater(new Runnable() {
@Override
public void run() {
pixelWriter.setPixels(0, 0, bufferFormat.getWidth(),
bufferFormat.getHeight(), byteBgraInstance, byteBuffer,
bufferFormat.getPitches()[0]);
}
});
}
}
However, the bug where Canvas keeps buffering data when off-screen
sometimes bites me, resulting in out of memory errors -- even slight
display delays can fairly easily cause this when video is running at 25
fps (takes about a second to go through 256 MB of memory).
--John
Regards,
Scott
On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici
fabrizio.giud...@tidalwave.it wrote:
On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynnjoe.mcgl...@oracle.com
wrote:
I don't know why FX Media isn't in the FX 8 API docs, but that's clearly
an error. Please file a bug on that.
In the meantime, you should look at the FX 2 media docs, there isn't a
lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live
Streaming) are both supported, as is playback from a URL.
What is the strategy for codecs? I mean, now we have ImageIO (there is
also JAI but it seems basically dead). ImageIO provides many image codecs
and there's a SPI that can be used to support more formats. Will it be
replaced by FX2 media or co-exist with it?
--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
We make Java work. Everywhere.
http://tidalwave.it/fabrizio/**bloghttp://tidalwave.it/fabrizio/blog -
fabrizio.giud...@tidalwave.it
Re: JavaFX Media issues
At minimum the Media Player must support H.264, MP3, AAC (so there is a
guarantee of a cross-platform format) and then defer to the default
platform media decoder for everything else. I.e. *anything* that the
standard OS provided media system can decode - I.e. QuickTime on Mac,
GStreamer on Linux, DirectShow on Windows. But all that is needed is the
hook and the community can make the bindings to QuickTime, VLC, etc.
The current implementation appears to be too unstable to rely on at the
moment anyway though: https://javafx-jira.kenai.com/browse/RT-31412
I have heard rumors of people being able to play HD video via Canvas. I
have tried everything and can't come close. (Yes, I have been careful about
the pixel format.) 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.
Is your app able to do *anything* else while the video is playing? The
slightest delay to the rendering and that Canvas buffering bug kills the
app. Not that it would matter if it could keep up, because the off-screen
thing is also a deal breaker.
Of course 25fps is well below the 60fps required for full-speed video. I
suspect it is the frame rate more than the frame size that matters here.
Plain old, standard definition, interlaced, 60 fields per second will
probably kill most apps with the current Canvas implementation.
We need something better. I proposed having at least a JNI method so we
could get native window handles from Stages but didn't get any traction
either. Security was brought up as a concern, which I totally do NOT
understand as the use of JNI means you are out of the Java sandbox already.
If we had native window handles we might be able get our own window for
rendering to at least interact nicely with the Stage. (We already did this
successfully in Swing via JAWT and a heavyweight component that we paint to
from native code)
Regards,
Scott
On Thu, Aug 8, 2013 at 9:06 PM, John Hendrikx hj...@xs4all.nl wrote:
On 9/08/2013 02:10, Scott Palmer wrote:
The Media APIs are mostly useless in their current state. Other than
demoing that you can play a video, they don't go far enough to be of
practical value. I tried to get someone to pay attention to them back in
the JavaFX 1.0 days
https://javafx-jira.kenai.com/**browse/RT-2684https://javafx-jira.kenai.com/browse/RT-2684
Unfortunately, I have to agree here. I'd love to use the Media APIs of
JavaFX, but they are way to limited. At a minimum I'd need support for MKV
containers and some common audio formats used with these. Decoding AVI
containers would be rather important as well. Without those, JavaFX video
is basically limited to bring your own videos only and completely
unsuitable for playing back videos that end users might have...
Instead, I've been using VLC + VLCJ from day one while working with JavaFX
as a work-around.
at least someone listened to the request to get H.264 support in there,
but
that is just a workaround. We need to be able to get our data into the
media pipeline. This would allow those of us that have attempted to do a
video window to have a fighting chance. Canvas can't keep up and will
likely crash the app with out of memory errors. Support for drawing into
a
native surface (OpenGL or D3D context) has been talked about, but doesn't
appear to be on the horizon yet. If we just had a hook to get the dang
pixel data into the media pipeline so we could supply the next frame
with
whatever we want - either from any native codec via JNI, or dynamically
generated from Java code, whatever... that would be just so dang useful...
(to me at least)
This would atleast allow me to decode the MKV container myself and supply
data... not looking forward to having to write all that code, but I would
if it meant I'd be able to go native JavaFX with video.
Canvas however is working for me even with HD video (copying 25 frames/sec
of HD video from VLCJ to Canvas). Playback is smooth even with 1920x1080
video for hours long video, and I can't tell the difference with a native
player or copying frame by frame using pixelWriter anymore. There is some
CPU penalty but on a my system it is well below 5%. This is basically how
that looks with VLCJ:
new RenderCallback() {
@Override
public void display(DirectMediaPlayer mp, Memory[] memory, final
BufferFormat bufferFormat) {
final ByteBuffer byteBuffer = memory[0].getByteBuffer(0,
memory[0].size());
Platform.runLater(new Runnable() {
@Override
public void run() {
pixelWriter.setPixels(0, 0, bufferFormat.getWidth(),
bufferFormat.getHeight(), byteBgraInstance, byteBuffer,
bufferFormat.getPitches()[0]);
}
hg: openjfx/8/graphics/rt: RT-30650: SwingNode is not Resizable
Changeset: 29a56291f75e Author:ant anton.tara...@oracle.com Date: 2013-08-09 09:38 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/29a56291f75e RT-30650: SwingNode is not Resizable Reviewed-by: anthony, art ! build.properties ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java + tests/graphics/SwingInterop/test/javafx/embed/swing/RT30650GUI.java + tests/graphics/SwingInterop/test/javafx/embed/swing/RT30650Test.java
