Moving on (forked from Re: JavaOne roundup?)
a case for it, but if anyone wants to do this let me know and I can notify sonatype to give you access and save you some hassles. I think Niklas has the RoboVM Maven Plugin sorted now and can do enhancements on that but I'm sure if anyone wanted to help him out he wouldn't say no. Cheers, Dan On Mon, Sep 30, 2013 at 5:04 PM, Tobias Bley t...@ultramixer.com wrote: I don’t understand why „all“ this people who needs JavaFX on iOS/Android does not tell it Oracles management. And I don’t understand why all this people use their time to develop all this demos and Rasp.PI stuff. Who needs it? Why don’t we develop base stuff like iOS skins, Android skins, iOS/Android widgets, RoboVM for Android, RoboVM using OpenJDK, … I really love useful stuff like the „JavaFX maven plugin“ or the „AquaFX“ project. That kind of development we need! Best, Tobi Am 30.09.2013 um 08:50 schrieb Felix Bembrick felix.bembr...@gmail.com: No, you are *not* the only one. We *all* need it. In fact, without it happening soon, JavaFX is already dead. But let's not give up yet. Perhaps it's closer than we know. I am a glass half full kinda guy :-) On 30 Sep 2013, at 16:40, Tobias Bley t...@ultramixer.com wrote: I suppose „legal reasons“…. For me it’s very frustrating to see every year the same procedure: JavaFX-iOS/Android related tracks were canceled - „nerd“ stuff like Rasp.PI, DukePad Co were announced. Maybe I’m really the only one who needs JavaFX on mobile to use JavaFX on desktop as well… :( Am 29.09.2013 um 18:13 schrieb Jeff Martin j...@reportmill.com: It seems the JFX on iOS/Android were cancelled at the last moment. I tried to keep expectations low this year, but I admit I harbored secret hopes based on those sessions (a few embarrassingly optimistic conversations with clients notwithstanding). Last week Tomas offered this: about cancelled sessions please contact Mr. JavaOne stephen.c...@oracle.com I believe he will give satisfactory answer. I'd like to take him up on that satisfactory offer. Also, can we run the name DukePad by marketing again? :-) jeff On Sep 29, 2013, at 12:12 AM, Daniel Zwolenski zon...@gmail.com wrote: The sessions aren't up yet from the looks of it. It would be great to get an overall roundup of any new announcements or directions in any case. Given this is the developer community network it would make sense in my mind to highlight stuff like that in here. For me, I'd love it if someone could quickly sum up any announcements or sessions made about JavaFX for iOS, Android or in the deployment space? What happened at the sessions Tobi highlighted before ( http://blog.software4java.com/?p=97), did anyone go to these and able to give us some info? On 27/09/2013, at 7:07 AM, Richard Bair richard.b...@oracle.com wrote: The sessions, I think, are all being uploaded to Parley's ( http://www.parleys.com), although I don't see any content there yet (not sure how long it will take them to post-process, but usually it is pretty fast). Richard On Sep 26, 2013, at 2:00 PM, Daniel Zwolenski zon...@gmail.com wrote: Has anyone done or seen any good roundups (text or video) of the JavaOne sessions relating to javafx?
Re: JavaOne roundup?
The sessions aren't up yet from the looks of it. It would be great to get an overall roundup of any new announcements or directions in any case. Given this is the developer community network it would make sense in my mind to highlight stuff like that in here. For me, I'd love it if someone could quickly sum up any announcements or sessions made about JavaFX for iOS, Android or in the deployment space? What happened at the sessions Tobi highlighted before (http://blog.software4java.com/?p=97), did anyone go to these and able to give us some info? On 27/09/2013, at 7:07 AM, Richard Bair richard.b...@oracle.com wrote: The sessions, I think, are all being uploaded to Parley's (http://www.parleys.com), although I don't see any content there yet (not sure how long it will take them to post-process, but usually it is pretty fast). Richard On Sep 26, 2013, at 2:00 PM, Daniel Zwolenski zon...@gmail.com wrote: Has anyone done or seen any good roundups (text or video) of the JavaOne sessions relating to javafx?
JavaOne roundup?
Has anyone done or seen any good roundups (text or video) of the JavaOne sessions relating to javafx?
CNET: Google begins barring browser plug-ins from Chrome
Google begins barring browser plug-ins from Chrome: http://news.cnet.com/8301-1023_3-57604242-93/google-begins-barring-browser-plug-ins-from-chrome/?tag=mobile_social
Fwd: FW: [javafx-maven-plugin] Problems with Java SE Development Kit 7u40 (#44)
Has something changed? -- Forwarded message -- From: Daniel Zwolenski da...@hotmail.com Date: Fri, Sep 20, 2013 at 7:50 AM Subject: FW: [javafx-maven-plugin] Problems with Java SE Development Kit 7u40 (#44) To: Daniel Zwolenski zon...@googlemail.com -- Subject: Fwd: [javafx-maven-plugin] Problems with Java SE Development Kit 7u40 (#44) From: da...@hotmail.com Date: Fri, 20 Sep 2013 07:04:19 +1000 To: openjfx-dev@openjdk.java.net Begin forwarded message: *From:* Martin Burkhard notificati...@github.com *Date:* 19 September 2013 6:39:20 PM AEST *To:* zonski/javafx-maven-plugin javafx-maven-plu...@noreply.github.com *Subject:* *[javafx-maven-plugin] Problems with Java SE Development Kit 7u40 (#44)* *Reply-To:* zonski/javafx-maven-plugin reply+i-19739500-cdc2ce3c0bd4f0ffac0b484c2bb56ae6edc3954c-2133...@reply.github.com Due to changes in JDK 7u40, the javafx-maven-plugin seems to be unable to execute *jfx:run*. I successfully tested the javafx-maven-plugin using JDK 7u21. I received the following error message using jfx:run on Mac OS X: [INFO] --- javafx-maven-plugin:2.0:run (default-cli) @ Test --- [INFO] Running JavaFX Application [WARNING] java.lang.NoClassDefFoundError: javafx/application/Application at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:792) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:285) at java.lang.Thread.run(Thread.java:724) Caused by: java.lang.ClassNotFoundException: javafx.application.Application at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 13 more [ERROR] Failed to execute goal com.zenjava:javafx-maven-plugin:2.0:run (default-cli) on project Test: Unable to execute mojo: An exception occured while executing the Java class. javafx/application/Application: javafx.application.Application - [Help 1] I received the following error message using *jfx:run* on Windows: [INFO] Running JavaFX Application [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 59.989s [INFO] Finished at: Thu Sep 19 09:56:49 CEST 2013 [INFO] Final Memory: 15M/43M [INFO] [ERROR] Failed to execute goal com.zenjava:javafx-maven-plugin:2.0:run (default-cli) on project Test: Execution default-cli of goal com.zenjava:javafx-maven-plugin:2.0:run failed: An API incompatibility was encountered while executing com.zenjava:javafx-maven-plugin:2.0:run: java.lang.NoSuchMethodError: org.apache.maven.execution.MavenSession.getRepositorySession()Lorg/sonatype/aether/RepositorySystemSession; [ERROR] - [ERROR] realm =plugincom.zenjava:javafx-maven-plugin:2.0 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy [ERROR] urls[0] = file:/C:/Users/xyz/.m2/repository/com/zenjava/javafx-maven-plugin/2.0/javafx-maven-plugin-2.0.jar [ERROR] urls[1] = file:/C:/Users/xyz/.m2/repository/org/twdata/maven/mojo-executor/2.0/mojo-executor-2.0.jar [ERROR] urls[2] = file:/C:/Users/xyz/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar [ERROR] urls[3] = file:/C:/Users/xyz/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar [ERROR] urls[4] = file:/C:/Users/xyz/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar [ERROR] urls[5] = file:/C:/Users/xyz/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar [ERROR] urls[6] = file:/C:/Users/xyz/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar [ERROR] urls[7] = file:/C:/Users/xyz/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar [ERROR] urls[8] = file:/C:/Users/xyz/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
Re: [API Review] FXMLLoader's protected fields
Umm, what happened to backwards compatibility? On Wed, Sep 11, 2013 at 4:44 PM, Martin Sladecek martin.slade...@oracle.com wrote: Hello, FXMLLoader contains a number of protected (non-final) fields that were made 'protected' probably just by accident. I'm going to make these fields private. If there's somebody who is working on a FXMLLoader subclass, let me know if you need some of the fields, so we could turn them into getters or something. Here's the list of the fields: protected Object controller; protected Object root; protected ResourceBundle resources; protected URL location; Thanks, -Martin
Re: Static FXMLLoader load method deprecation
+1 On 31/08/2013, at 8:54 AM, John Smith john_sm...@symantec.com wrote: The static methods on FXMLLoader are very confusing. It is very easy to create errors by writing code that mixes static and instance FXMLLoader methods. Everything that can be done with static load methods, can be done with instance FXMLLoader methods. Other than confusion, the static load methods seem to provide little value to me. Is it possible to have the static FXMLLoader methods deprecated for Java 8?
JNLP Change?
I received the below issue on the JFX Maven plugin. I don't have
time/motivation to investigate - on the surface it looks like a JFX
packager problem.
Has JNLP changed and has JFX packager been updated to handle this change?
-
A couple of issues:
JSE1.7 u25+_ requires new attributes on jar signing meaning that running an
JNLP will give errors Missing Permissions manifest attribute for
{jarfile}. See
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/no_redeploy.html
Secondly, field values in the JNLP are missing in the jfx config e.g. .
Also, I'm not seeing migrate from the main .pom to the JNLP.
Thanks for this great plug in!
Re: How to raise JavaFX iOS bugs?
Wtf? Oracle guys, what JVM is this session going to use? https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=5517 On 09/08/2013, at 3:51 PM, Tobias Bley t...@ultramixer.com wrote: Daniel, the question is: Which surprise will Oracle show on JavaOne 2013 in september? Maybe there is something official concerning JavaFX and iOS and Android…? Please take a look a the planned tracks: http://blog.software4java.com/?p=97 One track talks about „JavaSE in AOT mode“…so maybe we do not need such a backport in the future? Because Oracle does not say anything about the future, we don’t know it at the moment ;) Best regards, Tobi Am 09.08.2013 um 00:08 schrieb Daniel Zwolenski zon...@gmail.com: 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?
Re: How to raise JavaFX iOS bugs?
Is there going to be an answer on what JVM is going to be used for the JavaOne iOS demo? I'd also like to know what JVM you are testing on for these fixes? On 10/08/2013, at 12:46 AM, steve.x.northo...@oracle.com wrote: On 08/08/2013 6:08 PM, Daniel Zwolenski wrote: No, I didn't get a chance. Probably easier for you to just raise it now? See https://javafx-jira.kenai.com/browse/RT-32237 It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
Re: 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?
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 and iOS - it will remain a dream
How did you go with using Maven for your iOS stuff Tobi? Did it work out for you? Has anyone else had a chance to get into it? I was hoping for more feedback on what works and what doesn't. Also hoping to see some open source demo iOS apps popup to start highlighting what works and what doesn't. http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/ We all know 'Oracle' has a stupid stance on this, and reading between the lines the 'JFX' team are more on our side of the fence but are hamstrung. My personal feel is that the only hope is for the community to get the momentum going and to use that to then pressure Oracle into doing more. I've done what I can on the Maven front, trying to make it easy for developers to build apps. It's taken a lot of late nights and burnt up a lot of weekends (I even had to go buy a friggen Mac). I've reached my max for investing at this stage and need to take a little time to catch up on slipping day job work before the next round of fixes and enhancements. It would be great to see a real community effort here and see some people take up the baton and run the next leg of the relay. Both Niklas and Danno have done massive contributions so far too and I don't think they can be expected to carry the load alone. If you want to help give jfx iOS an actual fighting chance then consider: - writing some demo apps using the maven stuff, blogging about it, feeding back problems and issues so we can start fixing them - helping Niklas get robovm performant and feature rich (eg build a bundle for deployment to the app store) - talk to Niklas about financially sponsoring his work - if a company or two were willing to pay for him to work on it an extra day or two a week I suspect we'd see rapid gains - help maintain the backport run by Danno. Every time there are changes to the main jfx code we need to merge these into the backport. This is no small task. - help document the Maven plugin and generate usage information including a getting started guide and show how to do things like use FXML, change the app icon, change plists, run on older versions of ios, etc. On 07/08/2013, at 5:19 PM, Tobias Bley t...@ultramixer.com wrote: Yes Felix, it *has* to be this year…. We do not port our swing based commercial apps if JavaFX does not run on tablets as well. Am 30.07.2013 um 21:06 schrieb Felix Bembrick felix.bembr...@gmail.com: Hi Tobi, I know how you feel. As much as I am impressed with JavaFX, clearly its long-term survival does depend on it being viable on mobiles and tablets. All I can say is don't give up yet. I am certainly not giving up. I really hope we see something at JavaOne this year that will please us all. It *has* to be this year! Felix On 31 July 2013 02:40, Tobias Bley t...@ultramixer.com wrote: Hi, after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I’m very frustrated because of the following things: Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently unoptimized RoboVM One big problem of RoboVM is it’s dependence of the Android library, it does not support the OpenJDK. That’s a big reason for many many problems when using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library… Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT compiling… we hade no success…too complicated build process…no demos available for iOS… So in my opinion „JavaFX on iOS“ will remain a dream…If there will be no big company like Oracle or IBM who actively develops a VM for iOS and Android, JavaFX will be useless, also on Desktop, then HTML5 or QT will be the big winner for the most use cases on Desktop and mobile… Best, Tobi
Performant Controls (hijacking Re: Developing controls based on Canvas?)
Sneaking in here, as you've given an opening with if implemented wisely, there is very little that a scenegraph-based approach can't do. The question I've been asking for a while is what does implemented wisely look like in JFX. This has come up in the performance conversations, the game conversations, the CAD conversations, and many other places. No one seems to have an answer, but you're building extremely complex stuff on a regular basis - what's your tips? When you say you only have 20 visible nodes out of 1000's in general are the other nodes: a) in the scenegraph and set to not visible b) in memory but not in the scenegraph - added/removed when scrolled into view and out of view c) not in memory, created, added and then removed, destroyed when scrolled into view and out of view d) something else? I know Table uses a rubber stamp approach, where it re-uses cell views where possible, but let's say every row in my 100,000 row Table was uniquely rendered using a different cell. What would happen under the covers? How do you work out the scroll range as well? Each cell can be a unique height right? How do you know the extents of the vertical scrolling without instantiating and rendering everything? Is this what you do? What if a cell is changing size (has a collapsable pane in it, etc) - what happens to the vertical scroll range? Do any of the controls have zooming on them? Have you had to deal with this and have you got a strategy for handling this with respect to scroll bounds, working out which nodes are in view, scaling fonts, etc? Could you hazard a guess at what you would do if you had to implement zooming on a Table for example? Maybe the Table is lucky with its restrictive grid like layout but imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general strategy? On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles jonathan.gi...@oracle.comwrote: 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 think the normal approach to building controls is not sufficient? We've built some fairly complex controls using this approach, and if implemented wisely, there is very little that a scenegraph-based approach can't do. Specifically, do you think your control will render all of the 'thousands of nodes' at once, or will many of these nodes be off screen or otherwise not visible at any one time? For things like the TableView we only render the nodes that are visible. This means that regardless of whether there are 100 or 1,000,000 rows of data, we only have visual nodes for the 20 visible rows, for example. Keeping your scenegraph as minimal as possible is always a very wise idea, if performance is a concern. As you note, the other problem is that you will run into issues if you want to mix canvas rendering with the scenegraph-based controls like Button. The best you're likely to achieve (having not tried it personally) is to position the control on top of the canvas, rather than attempting to render the control inside the canvas (and having to then deal with event handling, etc). This will likely prove to be finicky, and more cumbersome than simply using an entirely canvas-based or entirely scenegraph-based approach. -- Jonathan On 5/08/2013 10:11 p.m., Felix Bembrick wrote: I am investigating the feasibility of developing a JavaFX 8 control based on Canvas. I have chosen Canvas as the base class as this control is of a very dynamic nature and would not be easy to implement with a retained mode style ancestor (at least as far as I can tell). So is this feasible? While I can readily see how to render the visual aspects of the control, I am not sure how to best embed other controls within it should that become necessary (and almost certainly will). For example, how would I go about embedding a Button within my control? It looks to me like I would need to create an actual Button node somewhere else in the scenegraph and then perhaps render it within my control using gc.drawImage() passing in a snapshot of the Button node. That's OK but then I have to somehow handle events and I am not sure how best to do that. Another issue I see is that there seems to be no way to apply effects to individual graphic elements within the Canvas as the applyEffect() method applies to the entire Canvas. Finally, a significant obstacle is this issue: https://javafx-jira.kenai.com/**browse/RT-23822https://javafx-jira.kenai.com/browse/RT-23822 This issue relates to the lack of support
Re: Performant Controls (hijacking Re: Developing controls based on Canvas?)
Thanks Jonathan, it's good to get your insight. You did finish by muddying the waters again though - to do something complex with zooming and scrolling you'd be tempted to fall back into Java2D paint-style programming, and use Canvas for this, not the Scene graph? It's more a couldbe/maybe comment though and is in contrast to your earlier suggestion that there is very little that a scenegraph-based approach can't do. What's the trigger to switch from one approach to the other? Previously there have been comments about the Canvas not really being intended for highly dynamic stuff (that was my interpretation of comments on here when Canvas was first released), and Nodes should be used for most real things. Richard wanted to use Nodes in the TD game for sprites. To add to the confusion, Canvas currently has some drastic z-order bugs, and some clipping issues, so using it combined with Nodes is currently a no-go. I'm not expecting Jonathan to have an answer here really, just highlighting the fact that there is no clear answer on this. I'm still confused and I imagine many others are too. I think we'll see this question again. On Tue, Aug 6, 2013 at 11:00 AM, Jonathan Giles jonathan.gi...@oracle.comwrote: I don't think there is any particular secret sauce going on in what I do compared with the general guidelines that have been spelled out numerous times. It's the same old, same old: don't create more nodes than you need, don't modify the scenegraph needlessly, don't update the scenegraph multiple times in a single pulse, change state as little as possible, use as few listeners as possible, etc. I wish I had something more groundbreaking for you, but that is about it :-) With respect to TableView (and ListView, TreeView, and TreeTableView), they are all based on the same virtualisation code (VirtualFlow for those of you playing at home). We don't rubber stamp, we create separate cell instances for the visible area of the control, and reuse these exact same cells as the user scrolls. Therefore, if the visible area requires 20 cells, we may create ~22 cells, and as the user scrolls downwards we take the cells that disappear out the top of the view and place them at the bottom of the view, with their new content in place before it is shown on screen. Because all cells come from a single cell factory, and all cells can be used in any location, it is up to the cell to respond to the item placed into it and draw itself appropriately. Therefore, we don't have 1000's of types of cells in a single control, we only have one type of cell that needs to handle all the visual approaches required in the app. Realistically, there aren't 1000's of styles in a single control, normally there are only one, or two at most. All this takes place in the Cell.updateItem(T, boolean) method, and so people overriding this method need to be smart and not do heavy lifting in there. The biggest mistake I see people doing in updateItem(...) is throw away their entire cell scenegraph and recreate the nodes and update the scenegraph. This is unwise. If you have a ListView with 100 nodes, and they are all equally sized except for one (say the 50th), which is _significantly_ bigger, you will see the scrollbar jump in size and other weirdness happen when it is scrolled into view, precisely for the reason you state - we can't go off and measure every row as we'd be doing a lot of busy work. We only measure what is in the visual area, and we don't know where we are in the scroll range in terms of pixels but rather in terms of a 0.0 - 1.0 range (which is translated back to pixels when needed). Up to this point I've known about this issue but I've not spent the cycles to resolve it - it is a relatively rare use case (although it still happens). Priority #1 for these virtualised controls is always speed. If zooming were required on TableView, the implication (I presume) is that there would be that less cells that were visible at any one time, and so we would end up having less cells in the scenegraph. Other than that, things would work as above. In a past life I did a lot of work in Java 2D. This worked really well for use cases like you suggest at the end of your email, namely zooming and direct mouse manipulation of nodes on screen. If I were to write something like you show in the screenshot, I would be tempted to take a Canvas-based route nowadays, but of course that decision would also be driven by the requirements and use cases, and it is possible a scenegraph-based approach with absolute node positioning would work just as well. Hope that helps. -- Jonathan On 6/08/2013 12:38 p.m., Daniel Zwolenski wrote: Sneaking in here, as you've given an opening with if implemented wisely, there is very little that a scenegraph-based approach can't do. The question I've been asking for a while is what does implemented wisely look like in JFX. This has come up in the performance
Re: TD game (hijacking Re: Performant Controls (hijacking Re: Developing controls based on Canvas?))
I'm out for that one for the foreseeable future. I've burnt up any and all free time on getting the desktop and iOS workflows working with Maven. I'm big time behind on client work. Tell you what though, if you can get someone at Oracle to take over the deployment tools and iOS stuff, I'd very happily switch over to building games and gliffy-like demo apps :) On Tue, Aug 6, 2013 at 3:02 PM, Richard Bair richard.b...@oracle.comwrote: It really wasn't ever supposed to be my TD game, I keep trying to get you (and others interested in the community) to develop it. I'm up to my eyeballs in work already, as I'm sure you can relate :-) Richard On Aug 5, 2013, at 9:24 PM, Daniel Zwolenski zon...@gmail.com wrote: You should be able to check out they work in your TD game and continue development on that then. On Tue, Aug 6, 2013 at 2:16 PM, Richard Bair richard.b...@oracle.comwrote: To add to the confusion, Canvas currently has some drastic z-order bugs, and some clipping issues, so using it combined with Nodes is currently a no-go. I believe those have all been fixed in the last couple of weeks. Richard
JavaFX On IOS Using RoboVM And Maven
The RoboVM Maven plugin is now released with JFX support using Danno's backport, which is all in Maven Central. I talk about it in detail here: http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/ I'd greatly appreciate people here trying it out and letting me know fairly quickly if there are any steps I left out or if anything is not working (in terms of the hello world, not bigger issues at this stage). Every time I release or publish something I get a lot of I don't know how to code and couldn't get past step 2 type requests. These can be very time consuming to work through, since some are real and some are just stupid-user-exceptions. Anything I can head off at the pass is a boon. As per the post, yes, it's slow, yes, it's buggy, yes, it all looks pretty crap at the moment - but it's suppose to. The JFX code has barely been run by the people who wrote it and the RoboVM code is being developed by one guy part time and has not been optimised at all. The fact that it works at all is down right amazing. The point of releasing this code is so the above issues can start being addressed, it's not meant to be perfect. If you want it better, I'm sure Niklas, Danno and Richard are only too happy for you to help out in each of the respective areas where there are known issues. No one ever wants to help out with the build tools, that's a crap job that no sane person would do in their spare time :)
Modularisation and repositories (forked from Re: Building JavaDoc and Sources JARs)
On Fri, Jul 26, 2013 at 3:47 PM, Richard Bair richard.b...@oracle.comwrote:
I'm assuming here you're talking about publishing real builds (at least
OpenJFX ones) and not on a local developers machine ('cause there'd be no
advantage to that alone). But maybe you can help me understand another part
of this problem, which is that suppose we have two developers, A and B. A
is on some code two weeks old. B is completely up to date. B does some fix
and pushes it. The build server builds the artifacts and puts them in the
repo. The next time A does a build, it grabs the latest built artifacts for
the code A isn't building (WebView, for instance) and there is a
compile/link error because the new binaries from B are out of sync with the
2 week old code that A is building with.
Normally you version for things like this, but in this case we're talking
about shared libraries that are unversioned -- they're SNAPSHOT. But one
snapshot is not equal to another. How to handle this? Right now in the
closed builds we have an explicit ant update step you have to run to get
the latest binaries.
I've had similar situations to what you're facing, where I might have a
number of core/utility libraries in an organisation and then lots of
projects that use these. If one team changes the utilities but the other
team doesn't want those changes, it gets messy.
I'll give you the overview of solutions I've come up to this and you can
take from it what you like. I haven't used Gradle though so I'll have to
talk in terms of Maven. Since Maven is more restrictive than Gradle you can
hopefully extract what you need. Others might be able to chime in more or
different opinions (I'd love that personally).
In Maven, you would have each of your modules as a separate Maven module,
with it's own POM and it's own coordinates (where it is deployed to in the
repo). e.g. using groupId:artifactId:version you would have stuff like:
- net.java.openjfx:openjfx-base:8.0.1
- net.java.openjfx:openjfx-controls:8.0.1
- etc
Each of the native modules would also be their own modules with their own
POM files and coordinates, so you would have:
- net.java.openjfx:jsl-decora:8.0.1
- net.java.openjfx:jsl-prism:8.0.1
- net.java.openjfx:native-font:8.0.1
- etc
Maven typically works best when you group these in a folder hierarchy, with
parent POMs as needed. Gradle is more flexible, but I suspect it would
still benefit from a the standard hierarchy here, this could look something
like (cut down, just indicative):
- openjfx
- base
- controls
- graphics
- graphics-core
- jsl-decora
- jsl-prism
Each of those directories would have it's own POM and in the leaf cases a
src/main/java (or native equivalent such as src/main/c++). I've introduced
graphics-core, since currently graphics is one big blob of Java and native
artifacts, making it hard to work with and deploy, etc. It works better if
they are separate and in Maven a parent module (such as graphics) would not
typically have code in it as well.
This directory structure allows you to build each module, or group of
modules stand alone. You could go into the controls directory and run 'mvn
clean install' and it would build only that, or into the graphics directory
and build only the graphics child modules. The top level openjfx module
would have no source code but would just provide an uber parent where you
could just build all the sub-modules in one command mvn clean install
(maybe adding a -Pwin64 to trigger profiles to build the OS specific
versions).
Each of these modules would then be deployed to its own unique coordinates
in your Maven repo (your self-hosted artifactory or whatever). So
jsl-decora is in its own directory in the repo and is then referenced as a
dependency by graphics-core (or whatever needs to use it). Additionally the
JavaDoc and source code for each module would be deployed with each. Each
module is a totally stand-alone deliverable - even if it only exists to be
used inside a bigger module.
This is where it gets nice, since if jsl-decora is available in a repo I
have access to, I never need to build it, Maven will just pick up that one.
Similar for all the pure Java modules as well - if I just want to build
'controls' but not 'base', Maven will pick up base from the repo. This is
good modularisation - you have this on the code level now but not on your
build level as far as I can see.
Additionally you can open an individual POM file in IntelliJ or Eclipse as
its own project. So you could open just the 'controls' project and it
should be able to build and run the unit tests, etc, of just that module.
Or if you open the graphics parent module it would open all the child
projects as well. And opening the top level openjavafx POM, would open all
the child projects and descendants for everything. (As an aside, with Maven
I never check in my intellij project files, and tend to get my developers
to open the
Re: Modularisation and repositories (forked from Re: Building JavaDoc and Sources JARs)
And one other thing I forgot to mention on this topic, the practice of
having platform specific jars that contain both the non-platform specific
stuff (usually 90%+) and the platform specific stuff does not fit that well
into Maven repo deployment.
Maven would prefer to have something like
- jfxrt.jar - contains all the non-platform specific code
- jfxrt-win.jar - only contains the additional bits for windows
- jfxrt-osx.jar - only contains the additional bits for OSx
- etc
You would then deploy these all under net.java.openjfx:jfxrt:8.0.1 but the
main jar would have no classifier and the other jars would have a
classifier for their platform. The source (and javadoc) however would be
one zip for all them (deployed under the same coordinates but with the
classifier 'source' or 'javadoc').
Currently I'm stuck in the deployment of the 78 backport as Sonatype won't
let me close a release without a non-classified JAR but we have only
operating specific ones that I am deploying with a classifier. I'm waiting
to hear from Sonatype what they recommend in this case,
On Mon, Jul 29, 2013 at 11:34 PM, Daniel Zwolenski zon...@gmail.com wrote:
On Fri, Jul 26, 2013 at 3:47 PM, Richard Bair richard.b...@oracle.comwrote:
I'm assuming here you're talking about publishing real builds (at least
OpenJFX ones) and not on a local developers machine ('cause there'd be no
advantage to that alone). But maybe you can help me understand another part
of this problem, which is that suppose we have two developers, A and B. A
is on some code two weeks old. B is completely up to date. B does some fix
and pushes it. The build server builds the artifacts and puts them in the
repo. The next time A does a build, it grabs the latest built artifacts for
the code A isn't building (WebView, for instance) and there is a
compile/link error because the new binaries from B are out of sync with the
2 week old code that A is building with.
Normally you version for things like this, but in this case we're talking
about shared libraries that are unversioned -- they're SNAPSHOT. But one
snapshot is not equal to another. How to handle this? Right now in the
closed builds we have an explicit ant update step you have to run to get
the latest binaries.
I've had similar situations to what you're facing, where I might have a
number of core/utility libraries in an organisation and then lots of
projects that use these. If one team changes the utilities but the other
team doesn't want those changes, it gets messy.
I'll give you the overview of solutions I've come up to this and you can
take from it what you like. I haven't used Gradle though so I'll have to
talk in terms of Maven. Since Maven is more restrictive than Gradle you can
hopefully extract what you need. Others might be able to chime in more or
different opinions (I'd love that personally).
In Maven, you would have each of your modules as a separate Maven module,
with it's own POM and it's own coordinates (where it is deployed to in the
repo). e.g. using groupId:artifactId:version you would have stuff like:
- net.java.openjfx:openjfx-base:8.0.1
- net.java.openjfx:openjfx-controls:8.0.1
- etc
Each of the native modules would also be their own modules with their own
POM files and coordinates, so you would have:
- net.java.openjfx:jsl-decora:8.0.1
- net.java.openjfx:jsl-prism:8.0.1
- net.java.openjfx:native-font:8.0.1
- etc
Maven typically works best when you group these in a folder hierarchy,
with parent POMs as needed. Gradle is more flexible, but I suspect it would
still benefit from a the standard hierarchy here, this could look something
like (cut down, just indicative):
- openjfx
- base
- controls
- graphics
- graphics-core
- jsl-decora
- jsl-prism
Each of those directories would have it's own POM and in the leaf cases a
src/main/java (or native equivalent such as src/main/c++). I've introduced
graphics-core, since currently graphics is one big blob of Java and native
artifacts, making it hard to work with and deploy, etc. It works better if
they are separate and in Maven a parent module (such as graphics) would not
typically have code in it as well.
This directory structure allows you to build each module, or group of
modules stand alone. You could go into the controls directory and run 'mvn
clean install' and it would build only that, or into the graphics directory
and build only the graphics child modules. The top level openjfx module
would have no source code but would just provide an uber parent where you
could just build all the sub-modules in one command mvn clean install
(maybe adding a -Pwin64 to trigger profiles to build the OS specific
versions).
Each of these modules would then be deployed to its own unique coordinates
in your Maven repo (your self-hosted artifactory or whatever). So
jsl-decora is in its own directory
Putting the JavaFX 78 backport into Maven Central
As I mentioned, I'm in the process of deploying the iOS version of Danno's 78 backport (https://bitbucket.org/narya/jfx78) to Maven Central. This is a summary of a couple of decisions I'm taking. *78 Backport Coordinates * I previously proposed deploying with these coordinates: - groupId=net.java.openjfx - artifactId=openjfx-78-backport - version=1.8.0-ea-b96.1 - classifier=ios The native files would use the same coordinates, except with an artifactId of openjfx-78-backport-native. Given the backport is quite different to the official stuff, in order to keep things clean down the road, I'm now thinking of using a specific group for the backport, so: - groupId=net.java.openjfx.backport - artifactId=openjfx-78-backport - version=1.8.0-ea-b96.1 - classifier=ios If there are any objections or better ideas, shout out as soon as possible. *Classifiers for OS and default JARs* I hit a problem in that in order to pass the rules for submitting, I need to have an unclassified (default) JAR file. There is no such JAR in jfx since all JARs are platform dependent. Sonatype have recommended I pick one of the OS dependent JARs and use that as the default (yuck). In the case of the backport I am only building the ios one, so this is going to be the easiest default JAR for me to deploy. If anyone has any objections to that, or better ideas - shout out as soon as possible. If we ever get to the stage of deploying the official openjfx modules then we will be faced with the decision of which one is the 'default'. I'll leave that alone at the moment, but Richard, if you are looking at using repos, this might be something to keep in mind (ideal would be to do the split I mentioned in a previous email). * Compatibility classes* JavaFX 8 is using classes in the JDK that are not available in Java7. For the backport to work there were two choices, either edit the JFX code to not use these classes, or make these classes available to the backport. Danno and Niklas decided to go for the second option, and there is now another mini-project containing these classes so they can run on Java7. https://github.com/robovm/robovm-jfx78-compat I am also going to push these into Maven (I need to do some work on the POM in this first). The coordinates are a little tough for this, but I'm thinking of using: - groupId=net.java.openjfx.backport - artifactId=openjfx-78-backport-compat - version=1.8.0.1 The version is tricky. It's unlikely this compatibility stuff will change much with each release of JFX, so I don't really want to tie it into the version number of that (e.g. 1.8.0-ea-b96.1) and then have to redeploy an identical JAR each time. At the same time, we will likely want to add things over time that we missed, etc, so we do need a version number we can increment. I'm using the .1 on the end for this. This versioning is not overly intuitive, but it's the best I can come up with. Objections, suggestions, shout out. *POM file info* To deploy to Sonatype and pass their checks, I have to fill in various sections of the POM such as licencing information, URLs, list of developers, etc. I've attached the POMs which are fleshed out as best I can and should pass the checks. If anyone wants anything different or sees any problems, shout. The developer section I have stuck in Danno as Project Owner and myself as Maven Deployer. The idea of this section is that it provides a reference point to the people working on the project so someone could track them down later. I don't really care who or what goes in here.
Re: Building JavaDoc and Sources JARs
Thanks guys - the source target worked like a charm so that's that bit
sorted. I don't need platform specific separations of source or javadoc
just the simple stuff - although technically I should put the source for
the native libs alongside the native files when I deploy them too. I don't
suppose anyone has a task that zips/jars up all the native code?
For the JavaDoc: there were a few issues on my end. I had java8 set as my
home, switching to java7 made some of the weirder errors go away. Then
adding the JDK doc to my JDK home got rid of a bunch more (I think). I
didn't have to set any properties just extract the doc into the JDK home.
Then I had to remove the 'web' module from the javadoc task as this was
referencing com.sun.webkit stuff that isn't there. I'm using the *Java78
backport* here.
Now I just have a whole lot of errors from the Ensemble stuff, along these
lines:
/Users/zonski/Development/openjdk/jfx78/jfx78/jfx78/apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/stage/advancedstage/AdvancedStageApp.java:72:
error: cannot find symbol
public class AdvancedStageApp extends Application {
^
symbol: class Application
Not sure why but don't really care as easiest for me would be to just to
exclude all samples from the javadoc task. I assume I need to do something
with this line in the javadoc task:
exclude(com/**/*, javafx/scene/ParentDesignInfo*, Compile*,
javafx/builder/**/*);
I'm sure it's simple but I've run out of time at the moment (moving
house/states) so I'll have to work this out later but if anyone knows off
the top of their head, that would help me.
Richard, I'll definitely respond to your question on module separation and
versioning when I get a chance. Might take a few days though.
On Fri, Jul 26, 2013 at 6:05 PM, Robert Fisher rfis...@tesis.de wrote:
For a source jar/zip I added the following top-level task to my
build.gradle file:
task jfxrtSources(type: Zip) {
group = Basic;
description = Packs all sources for jfxrt.jar into a zip file;
archiveName = build/javafx-src.zip;
includeEmptyDirs = false;
from(modules/base/src/main/java,
modules/builders/src/main/java,
modules/controls/src/main/java,
modules/designTime/src/main/java,
modules/fxml/src/main/java,
modules/fxpackager/src/main/java,
modules/graphics/src/main/java,
modules/web/src/main/java,
modules/swing/src/main/java,
modules/swt/src/main/java);
include(**/*.java);
}
If you want to exclude sources that are irrelevant for your target
platform (e.g. android-specific sources in a windows build), you can just
declare the task at top-level and put the implementation underneath
complileTargets { , exactly as it is done for the jfxrt task for
instance.
Cheers,
Rob
-Ursprüngliche Nachricht-
Von: openjfx-dev-boun...@openjdk.java.net [mailto:
openjfx-dev-boun...@openjdk.java.net] Im Auftrag von Richard Bair
Gesendet: Freitag, 26. Juli 2013 06:39
An: Daniel Zwolenski
Cc: openjfx-dev@openjdk.java.net
Betreff: Re: Building JavaDoc and Sources JARs
You gotta set the BUILD_JAVADOC flag. Look in gradle.properties.template
-- all the different flags are pretty well documented there.
For sources, somebody else posted a message about wanting to do that, and
I think that's great. Just need to get a patch to the gradle build to
create a source zip (per platform, or just one big zip with everything in
it?)
Richard
On Jul 25, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote:
For the Maven deploy I need a JAR of the JavaDoc and another
containing the sources. That's the rules.
How do I build these with the Gradle build? I tried:
gradle javadoc
and can't see any JavaDoc anywhere in the build directory?
Admittedly I am running this on the 78 backport code, not the JFX
code, but I believe this part of the build should be the same?
Full log:
Daniels-MacBook-Pro:jfx78 zonski$ /usr/local/gradle-1.6/bin/gradle
javadoc The ConfigurationContainer.add() method has been deprecated
and is scheduled to be removed in Gradle 2.0. Please use the create()
method instead.
:buildSrc:clean UP-TO-DATE
:buildSrc:generateGrammarSource
error(10): internal error: Can't get property indirectDelegates using
method get/isIndirectDelegates from org.antlr.tool.Grammar instance :
java.lang.NullPointerException
java.util.Objects.requireNonNull(Objects.java:203)
java.util.ArrayList.removeAll(ArrayList.java:674)
org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.
java:222)
org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
ava
Re: Can JavaFX do CAD?
story...
So this is why I think it's imperative that Oracle invests in developing a
true showcase application for JavaFX. Something that non-technical people
(like managers who make decisions about where the money goes) can look at
it
and go wow!.
I am just not getting my managers to go wow at what I can show them with
JavaFX at the moment.
Every comment or apparent criticism I post about JavaFX is from the
perspective that I am trying to deal with real-world problems and people
who
require proof (such as demos, reference sites etc.) and not because I
myself
think JavaFX is not up to scratch.
It's quite the opposite actually.
I am a very, very strong believer and supporter of JavaFX and have many
reasons both personal and professional as to why I want it to be a massive
success. As I have said before, there are plenty of people who praise
JavaFX and tend to avoid the very real issues that are restricting its
adoption. I just think we have to face these issues head on if we are to
compete in what is a very cut-throat industry.
-jct
-Original Message-
From: Richard Bair [mailto:richard.b...@oracle.com]
Sent: Saturday, 27 July 2013 01:40
To: John C. Turnbull
Cc: 'Daniel Zwolenski'; openjfx-dev@openjdk.java.net
Subject: Re: Can JavaFX do CAD?
For Flash, there are literally millions of examples of
fancy/complex/impressive graphics and animations out there that can be
really impressive at times. I have not seen ONE such example in JavaFX!
Point to one?
Have you seen any of the JavaOne examples? The movie wall or movies on a
stack of 3D cubes was pretty good. But I guess you're not interested in the
3D aspect? What is it you are looking for exactly? Different people (on
this
list) have had different perceptions on both (a) what's important and (b)
what kind of graphics they're interested in. Most people would deride the
dancing cat as being totally irrelevant to the types of applications
they're
trying to build (the basis for much of flash animations is shape morphing,
you can find some code here https://gist.github.com/gontard/5029764).
On the other hand, JavaFX is not a replacement for OpenGL. Drawing 25
million lines is just not something we can do right now, especially in a
resource constrained environment. I've already commented on the memory
overhead (which would continue to be an issue even if the drawing part of
the problem were solved).
I've pushed to graphics repo the StretchyGrid, which is about 300k line
nodes (the actual amount is variable, see the javadoc comments). At 300k
nodes the scene graph overhead is negligible on the FX side, dirty opts is
taking a long time to run, and painting is really slow.
PULSE: 347 [122ms:222ms]
T12 (8 +0ms): CSS Pass
T12 (8 +0ms): Layout Pass
T12 (47 +53ms): Waiting for previous rendering
T12 (100 +1ms): Copy state to render graph
T10 (101 +16ms): Dirty Opts Computed
T10 (117 +105ms): Painted
Counters:
Nodes rendered: 306565
Nodes visited during render: 306565
If I were doing this by hand in open GL, I think the drawing would be
essentially free, if I used LINES with GL anti-aliasing, I could send 'em
all down to the card in a single shot (and if I had a modern GL I could do
LINES + FXAA or one of the other per-pixel AA algorithms available and it
would turn out pretty nice). Because our shapes don't implement the non-AA
path, and our AA involves software rasterization and uploading of pixels, I
expect that to be the main source of the 105ms time being spent here.
Also I noticed (by turning on prism.showdirty=true) that the entire grid is
being painted every time, even though visually it looks like only a small
subset actually needs to be changed. But that's really a minor thing, as I
said, drawing this many lines should basically be free if I configure
smooth to false in the app. Except that right now it is totally not
implemented (in NGShape):
public void setAntialiased(boolean aa) {
// We don't support aliased shapes at this time
}
The point of stretchy grid is not to say wow look at this amazing demo.
The point is to say what happens if I put in 300K nodes. Where does the
system start to fall over?.
Richard=
Pushing OpenJFX to Maven - licensing and other stuff (forked from Re: jfxrt.jar - is it platform specific?)
, e(fx)clipse will add support for your maven-plugin and RoboVM deployment options (most likely also ontop of the above mentionned maven-distro) with the next release in autumn. Tom On 25.07.13 08:46, Daniel Zwolenski wrote: Ok, thanks. Is it architecture specific, i.e. within a target OS does each platform require it's own jfxrt.jar or do they all share the same? Most specifically, on iOS do the armv7 and i386 architectures use the same JAR and just different lib files or is there a specific jfxrt.jar for each? In general it would be great to see a list of all the distinct JARs that can be produced e.g. something like: jfxrt-ios.jar jfxrt-win.jar (or is jfx-win32.jar and jfx-win64.jar, etc) jfxrt-osx.jar jfxrt-linux.jar jfxrt-pi.jar I imagine that list is very wrong (pi, linux, especially) - what's the real list? This ( https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) kind of hints at it but for example if I want to build for win32 do I have to be on a win32 system or does building on a 64 bit platform produce the files needed for both, etc? Even better if we had some document that outlined all the supported platforms the JAR and the native libs built for that platform in a nice big table. Bonus points for clear cut steps and commands to build each one, which platforms you can run on and what gradle command to run. On Thu, Jul 25, 2013 at 3:32 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Yes, jfxrt.jar is platform-specific. On the desktop there are platform-specific glass and Prism classes (not sure about the WebKit classes). On embedded platforms (Linux-arm, IOS, Android) there are many differences. -- Kevin Daniel Zwolenski wrote: Obviously there are native libs (dlls, etc) that JFX uses that are outside of the jfxrt.jar. But is the actual jfxrt.jar produced by the build generic and able to be used on any platform (so long as the natives are also present) or is it platform specific itself? We are getting close to the ios/backport stuff working (as well as it can at this stage) and are aiming to start putting stuff in Maven soon. Just want to make sure I get the separations as clean as possible because once it's in Central it doesn't ever leave. Cheers.
Re: Building JavaDoc and Sources JARs
I've enabled that property and I now get a bunch of errors (100+), some
random samples:
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/web/src/main/java/javafx/scene/web/HTMLEditor.java:31:
error: package com.sun.javafx.scene.web.skin does not exist
import com.sun.javafx.scene.web.skin.HTMLEditorSkin;
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java:186:
error: incorrect use of inline tag
* @inheritDoc
^
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/graphics/src/main/java/javafx/scene/input/Clipboard.java:93:
error: end tag missing: /code
* precode
/Users/zonski/Development/openjdk/jfx78/jfx78-zonski/jfx78/modules/controls/src/main/java/javafx/scene/control/TableColumn.java:381:
error: reference not found
* is the {@link PropertyValueFactory} class. Refer to this class for
more
I see properties talking about linking to the JavaDoc for the whole JDK
(which I'm now downloading). I will set this up but I don't think it's
going to solve most of those errors?
Some general feedback: Seems like a lot of hoops to jump through and magic
in the build still. I'm just trying to get some JavaDoc here, nothing
fancy. Apart from the errors working, it's not overly intuitive that I have
to set a BUILD_JAVADOC=true to make 'gradle javadoc' work - can't the
gradle command just force the jdoc to build? The gradle stuff is definitely
better than before but it's still not a check it out and get busy coding
setup, which I'm hoping is the eventual goal.
The IntelliJ project that comes down with it doesn't just open either. It
seems to be dependent on all the other JDK projects being there. I don't
know how Gradle works, but the Maven approach to this would be that all
your bits and pieces are stand-alone artefacts/modules with their own POM.
Each one could be built on their own (and the jar is then put in a repo)
and then they all just reference each other as needed. If you guys deployed
to repositories (literally a filesystem that follows a naming convention -
not that hard!) for your builds and deployed each of the modules, then
community developers could just reference these instead of having to build
and reference bits and pieces that they have no interest in.
On Fri, Jul 26, 2013 at 2:38 PM, Richard Bair richard.b...@oracle.comwrote:
You gotta set the BUILD_JAVADOC flag. Look in gradle.properties.template
-- all the different flags are pretty well documented there.
For sources, somebody else posted a message about wanting to do that, and
I think that's great. Just need to get a patch to the gradle build to
create a source zip (per platform, or just one big zip with everything in
it?)
Richard
On Jul 25, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote:
For the Maven deploy I need a JAR of the JavaDoc and another containing
the
sources. That's the rules.
How do I build these with the Gradle build? I tried:
gradle javadoc
and can't see any JavaDoc anywhere in the build directory?
Admittedly I am running this on the 78 backport code, not the JFX code,
but
I believe this part of the build should be the same?
Full log:
Daniels-MacBook-Pro:jfx78 zonski$ /usr/local/gradle-1.6/bin/gradle
javadoc
The ConfigurationContainer.add() method has been deprecated and is
scheduled to be removed in Gradle 2.0. Please use the create() method
instead.
:buildSrc:clean UP-TO-DATE
:buildSrc:generateGrammarSource
error(10): internal error: Can't get property indirectDelegates using
method get/isIndirectDelegates from org.antlr.tool.Grammar instance :
java.lang.NullPointerException
java.util.Objects.requireNonNull(Objects.java:203)
java.util.ArrayList.removeAll(ArrayList.java:674)
org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.java:222)
org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:491)
org.antlr.stringtemplate.language.ASTExpr.invokeMethod(ASTExpr.java:563)
org.antlr.stringtemplate.language.ASTExpr.rawGetObjectProperty(ASTExpr.java:514)
org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:416)
org.antlr.stringtemplate.language.ActionEvaluator.attribute(ActionEvaluator.java:351)
org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:136)
org.antlr.stringtemplate.language.ActionEvaluator.templateApplication(ActionEvaluator.java:216)
org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:126)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:84)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148
Re: Can JavaFX do CAD?
I think the below comment makes it sound more straight forward than it is. In building a diagramming tool there is much more to it than just the rendering frame rate. This topic about CAD-like apps and 'performant' highly visual jfx apps in general has been raised here and in the forums before, without any clear resolution. Chris, the closest we've come to an answer is that it certainly isn't straight forward to do and there are many areas where the intuitive solution (especially for us ex-swing devs) gives results that are horribly unusable. There *might* be a way to get jfx to do this but there's no clear guidelines on how to achieve a 'performant' result. This is why I +1'd your question and added areas I feel need clarification from the jfx team. Unfortunately I'm not entirely sure they know the answers themselves and it generally comes back as a 'you try it and let us know how it goes'. The last time we raised a similar topic it led to an attempt to build a Tower Defender game (led by Richard) in order to 'see how it goes', which revealed some pretty significant problems and the game quickly stalled as a result. Having built a prototype floor plan tool in JFX2 before I can say it did not go smoothly. The things I've listed as wanting best practices for are all areas where I struggled to make jfx achieve decent results in terms of responsiveness, animation speed/smoothness, rendering quality and simplicity and cleanliness of code. The one area where I'd say it did hold up well (as far as I could tell) was frame rate but that didn't help me at all and I doubt would be much consolation for you after you make the massive effort needed to convert your app. On 24/07/2013, at 4:29 PM, Joseph Andresen joseph.andre...@oracle.com wrote: I believe JavaFx could do cad, first step would be to provide a simple data set and boil it down to the best render paths in JavaFX. As far as I know it shouldn't be any worse than swing with the slowest render paths. -Joe On Jul 23, 2013, at 8:47 AM, Chris Gay chris.gay5...@gmail.com wrote: Hello all. Please could someone advise if it is even feasible for me to consider re-factoring the following Swing application, so that it becomes a JavaFX one. From trying to read about JavaFX, I get the feeling that Oracle never intended Java FX for the purpose I need. I have a large Java Swing desktop CAD application which makes heavy use of the Java 2D API, and concurrency. It is a Menu Bar driven application, with a Toolbar for Tools, and a few buttons, but 99% of the user activity concerns selecting and manipulating vector graphical objects in a traditional manner using one Tool at a time (think Inkscape or LibreOffice Drawing apps). The application has multiple drawings open at the same time (but only one is visible), and each Drawing contains it's own Drawing and Processing threads (in addition to sharing the Main and Event Threads), which keeps the Event Thread lively. Each Drawing contains an ArrayList, acting as a Display List of all graphical objects, and each graphical object can be a tree structure. In many cases I use simple iteration instead of Iterators, simply for speed, and to avoid garbage. The graphical objects are lightweight, in that they do not carry references to events and handlers. All they carry is their basic geometric data and properties, a bounding box which they can lend as Read Only, and a boolean flag to indicate selection, which means there can be millions of the objects, with a minimum memory footprint. To support them, there are many hundreds of methods, which the tools interact with. There can be multiple Drawing Windows active on a single drawing, where each Window is backed up by an offscreen image, which handles the zoom and sliding buffer behaviour for fast scrolling, to allow rapid bit-blt's to the actual window. Lastly, the user manipulates the Drawing (Display List), using one of many Tools, where the active Tool receives events from the event queue, and then manipulates selected and/or unselected graphical objects, by using XOR Mode graphics onto the offscreen buffer, generally using callbacks. The system is fast and very responsive on large data sets, but what I do not know is whether JavaFX will help me make a better implementation, or whether it will fight me all the way. With JavaFX claiming hardware acceleration, I do not understand whether it depends on transferring the very large data sets into graphics hardware to render, and what happens if the hardware cannot cope. So far, I have found little in the way of discussions that help me get a mental picture of how JavaFX is intended to work. Should I stick with Swing? Regards, Chris
jfxrt.jar - is it platform specific?
Obviously there are native libs (dlls, etc) that JFX uses that are outside of the jfxrt.jar. But is the actual jfxrt.jar produced by the build generic and able to be used on any platform (so long as the natives are also present) or is it platform specific itself? We are getting close to the ios/backport stuff working (as well as it can at this stage) and are aiming to start putting stuff in Maven soon. Just want to make sure I get the separations as clean as possible because once it's in Central it doesn't ever leave. Cheers.
Re: Can JavaFX do CAD?
+1 More specifically I would like to know the official recommended best practices for implementing a CAD style app in JFX. - How best to represent large numbers of complex shapes efficiently, and when to add shapes to the scene (add all and let jfx clip, or manually work out what should be showing, etc) - How best to handle font scaling and image scaling when rendered in a zoomed in/out viewport - How best to do panning and zooming with dynamic level of detail - How best to do the top level display in terms of panes vs regions vs canvas, vs whatever, how to manage overlays and layers (sharing same coordinate space, etc) - How best to do picking, mouse overs, dragging across the 'display' - How best to do infinite or dynamic bounds so you can add and move shapes and the scrolling adjusts accordingly. A JFX diagramming app would make a very powerful demo app in my mind. On 24/07/2013, at 1:47 AM, Chris Gay chris.gay5...@gmail.com wrote: Hello all. Please could someone advise if it is even feasible for me to consider re-factoring the following Swing application, so that it becomes a JavaFX one. From trying to read about JavaFX, I get the feeling that Oracle never intended Java FX for the purpose I need. I have a large Java Swing desktop CAD application which makes heavy use of the Java 2D API, and concurrency. It is a Menu Bar driven application, with a Toolbar for Tools, and a few buttons, but 99% of the user activity concerns selecting and manipulating vector graphical objects in a traditional manner using one Tool at a time (think Inkscape or LibreOffice Drawing apps). The application has multiple drawings open at the same time (but only one is visible), and each Drawing contains it's own Drawing and Processing threads (in addition to sharing the Main and Event Threads), which keeps the Event Thread lively. Each Drawing contains an ArrayList, acting as a Display List of all graphical objects, and each graphical object can be a tree structure. In many cases I use simple iteration instead of Iterators, simply for speed, and to avoid garbage. The graphical objects are lightweight, in that they do not carry references to events and handlers. All they carry is their basic geometric data and properties, a bounding box which they can lend as Read Only, and a boolean flag to indicate selection, which means there can be millions of the objects, with a minimum memory footprint. To support them, there are many hundreds of methods, which the tools interact with. There can be multiple Drawing Windows active on a single drawing, where each Window is backed up by an offscreen image, which handles the zoom and sliding buffer behaviour for fast scrolling, to allow rapid bit-blt's to the actual window. Lastly, the user manipulates the Drawing (Display List), using one of many Tools, where the active Tool receives events from the event queue, and then manipulates selected and/or unselected graphical objects, by using XOR Mode graphics onto the offscreen buffer, generally using callbacks. The system is fast and very responsive on large data sets, but what I do not know is whether JavaFX will help me make a better implementation, or whether it will fight me all the way. With JavaFX claiming hardware acceleration, I do not understand whether it depends on transferring the very large data sets into graphics hardware to render, and what happens if the hardware cannot cope. So far, I have found little in the way of discussions that help me get a mental picture of how JavaFX is intended to work. Should I stick with Swing? Regards, Chris
Re: JavaFX 8 Progress
Sure, but no one other than the JFX team are (or will be) working on these right? They are effectively desktop technologies and no other team has any interest in them I'm guessing? I'd assume if they're not on the JFX roadmap, they're not on the Java roadmap? On Thu, Jul 18, 2013 at 9:48 PM, Artem Ananiev artem.anan...@oracle.comwrote: On 7/18/2013 3:00 AM, David Ray wrote: Hi Richard, I don't see any mention of WebStart and JavaFX on the milestone list - are issues surrounding (and suffocating :)) WebStart going to addressed as part of the JDK release 8 instead? Java Plugin and Java Web Start are not parts of JavaFX (although JavaFX provides some APIs for them), they are shared between JDK and JavaFX and released as a part of Oracle JDK8 (not included to OpenJDK). Thanks, Artem David Sent from my iPhone On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote: Hi Peter, Our dates match up with JDK 8: http://openjdk.java.net/** projects/jdk8/milestoneshttp://openjdk.java.net/projects/jdk8/milestones Feature complete was a month ago (but little API tweaks continue to happen). Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce http://openjdk.java.net/**projects/jdk8/milestones#Zero_** Bug_Bouncehttp://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in March. Richard On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm new to JavaFX I'm interested what is the current progress of development of JavaFX 8. I want to use it for base framework for my enterprise application but I have concerns is it stable to be used? Can you give me some information do you plan to add something else before the official release? Best wishes, Peter
Re: JavaFX 8 Progress
By 'deployment team' you mean Mark Howe, etc? There's no other team working on anything to do with deployment right? On 19/07/2013, at 12:22 AM, Joe McGlynn joe.mcgl...@oracle.com wrote: No, the deployment team works on these, not the FX team. It's the same bits for FX and Swing/AWT when running browser-deployed apps (which includes applets and web start). Deployment, FX and Swing are all part of the Java client org. There are a number of bug fixed being worked in this area, as well as new requirements around how to deploy a secure applet or web start app. The deploy code base is currently identical between 7u and JDK 8. If you are working with deploy technologies you should know this area is rapidly changing and I'd strongly advise staying on the latest release (currently 7u40 EA) and following the updates to the docs, especially around best practices for deployment. In short, these are: Buy a code signing certificate from a recognized CA and sign your app Use the new permissions and codebase JAR manifest attributes I'd recommend avoiding the use of mixed code if at all possible as that results in additional warning prompts to the end user and additional runtime risks. I'd also recommend testing your app with the security slider at the Very High level with every update of the JRE. Typically new restrictions are introduced first at Very High, and then propagated down into High and ultimately Medium over time. If there are problems using deployment with FX, of course report the issue and the team will investigate. I'm aware of one problem that causes some FX web start apps not to work with the latest release. It's being investigated right now. On Jul 18, 2013, at 6:40 AM, Daniel Zwolenski zon...@gmail.com wrote: Sure, but no one other than the JFX team are (or will be) working on these right? They are effectively desktop technologies and no other team has any interest in them I'm guessing? I'd assume if they're not on the JFX roadmap, they're not on the Java roadmap? On Thu, Jul 18, 2013 at 9:48 PM, Artem Ananiev artem.anan...@oracle.comwrote: On 7/18/2013 3:00 AM, David Ray wrote: Hi Richard, I don't see any mention of WebStart and JavaFX on the milestone list - are issues surrounding (and suffocating :)) WebStart going to addressed as part of the JDK release 8 instead? Java Plugin and Java Web Start are not parts of JavaFX (although JavaFX provides some APIs for them), they are shared between JDK and JavaFX and released as a part of Oracle JDK8 (not included to OpenJDK). Thanks, Artem David Sent from my iPhone On Jul 17, 2013, at 12:06 PM, Richard Bair richard.b...@oracle.com wrote: Hi Peter, Our dates match up with JDK 8: http://openjdk.java.net/** projects/jdk8/milestoneshttp://openjdk.java.net/projects/jdk8/milestones Feature complete was a month ago (but little API tweaks continue to happen). Things are supposed to be reasonably stable by October 24 (Zero Bug Bounce http://openjdk.java.net/**projects/jdk8/milestones#Zero_** Bug_Bouncehttp://openjdk.java.net/projects/jdk8/milestones#Zero_Bug_Bounce) and GA in March. Richard On Jul 17, 2013, at 9:52 AM, Peter Penzov peter.pen...@gmail.com wrote: Hi, I'm new to JavaFX I'm interested what is the current progress of development of JavaFX 8. I want to use it for base framework for my enterprise application but I have concerns is it stable to be used? Can you give me some information do you plan to add something else before the official release? Best wishes, Peter
Re: Mixing 2D and 3D
Does it need to be a separate class, can it not just be a setting on scene like setRenderMode(3d)? Just thinking you may want a base 3d view for example but then show 2d screens at times for settings, etc, so you could switch it on and off. I assume there's no way to do it pane by pane, so the docked components of a BorderPane are 2d optimized but the center is 3d? Or is that what SubScene3d is for (not real clear how this would be used)? On 19/07/2013, at 6:58 AM, Richard Bair richard.b...@oracle.com wrote: While working on RT-5534, we found a large number of odd cases when mixing 2D and 3D. Some of these we talked about previously, some either we hadn't or, at least, they hadn't occurred to me. With 8 we are defining a lot of new API for 3D, and we need to make sure that we've very clearly defined how 2D and 3D nodes interact with each other, or developers will run into problems frequently and fire off angry emails about it :-) Fundamentally, 2D and 3D rendering are completely different. There are differences in how opacity is understood and applied. 2D graphics frequently use clips, whereas 3D does not (other than clipping the view frustum or other such environmental clipping). 2D uses things like filter effects (drop shadow, etc) that is based on pixel bashing, whereas 3D uses light sources, shaders, or other such techniques to cast shadows, implement fog, dynamic lighting, etc. In short, 2D is fundamentally about drawing pixels and blending using the Painters Algorithm, whereas 3D is about geometry and shaders and (usually) a depth buffer. Of course 2D is almost always defined as 0,0 in the top left, positive x to the right and positive y down, whereas 3D is almost always 0,0 in the center, positive x to the right and positive y up. But that's just a transform away, so I don't consider that a *fundamental* difference. There are many ways in which these differences manifest themselves when mixing content between the two graphics. http://fxexperience.com/?attachment_id=2853 This picture shows 4 circles and a rectangle. They are setup such that all 5 shapes are in the same group [c1, c2, r, c3, c4]. However depthBuffer is turned on (as well as perspective camera) so that I can use Z to position the shapes instead of using the painter's algorithm. You will notice that the first two circles (green and magenta) have a dirty edge, whereas the last two circles (blue and orange) look beautiful. Note that even though there is a depth buffer involved, we're still issuing these shapes to the card in a specific order. For those not familiar with the depth buffer, the way it works is very simple. When you draw something, in addition to recording the RGBA values for each pixel, you also write to an array (one element per pixel) with a value for every non-transparent pixel that was touched. In this way, if you draw something on top, and then draw something beneath it, the graphics card can check the depth buffer to determine whether it should skip a pixel. So in the image, we draw green for the green circle, and then later draw the black for the rectangle, and because some pixels were already drawn to by the green circle, the card knows not to overwrite those with the black pixel in the background rectangle. The depth buffer is just a technique used to ensure that content rendered respects Z for the order in which things appear composited in the final frame. (You can individually cause nodes to ignore this requirement by setting depthTest to false for a specific node or branch of the scene graph, in which case they won't check with the depth buffer prior to drawing their pixels, they'll just overwrite anything that was drawn previously, even if it has a Z value that would put it behind the thing it is drawing over!). For the sake of this discussion 3D World means depth buffer enabled and assumes perspective camera is enabled, and 2D means 2.5D capable by which I mean perspective camera but no depth buffer. So: 1) Draw the first green circle. This is done by rendering the circle into an image with nice anti-aliasing, and then rotating that image and blend with anything already in the frame buffer 2) Draw the magenta circle. Same as with green -- draw into an image with nice AA and rotate and blend 3) Draw the rectangle. Because the depth buffer is turned on, for each pixel of the green magenta circles, we *don't* render any black. Because the AA edge has been touched with some transparency, it was written to the depth buffer, and we will not draw any black there. Hence the dirty fringe! No blending! 4) Draw the blue circle into an image with nice AA, rotate, and blend. AA edges are blended nicely with black background! 5) Draw the orange circle into an image with nice AA, rotate, and blend. AA edges are blended nicely with black
Java Deployment (was Re: JavaFX 8 Progress)
There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
Re: JavaFX 8 Progress
Awesome - on the surface it does look like what Oracle were/should-be trying to build with their packaging tools - and it's free! If you use it a bit, let me know how it goes. If it's any good I'll look at wrappering this in a Maven plugin (looks straight forward). Maybe we can cut Oracle out of this altogether and get some actual progress here. If you can get your JWrappered reportmill app deployed somewhere, I'd be keen to try it out and see what the end user experience is like. Just trying their sample apps now. On Fri, Jul 19, 2013 at 10:43 AM, Jeff Martin j...@reportmill.com wrote: Wow - JWrapper really is remarkable. It took me less than 30 minutes to figure out how to package our ReportMill app for Mac, Windows and Linux. Worked like magic. It doesn't include JavaFX yet, though, even though the Mac JRE is 1.7.0u25. Jeff On Jul 18, 2013, at 4:20 PM, David Ray cognitionmiss...@gmail.com wrote: JWrapper (no plug - I don't work for them or own stock) solves all of this - you have to bundle the jvm but it's small and the installation is hitch-less… Oracle should buy them out - seriously! David On Jul 18, 2013, at 4:09 PM, ozem...@ozemail.com.au wrote: +1 The various applet and Web Start deployment options are severly damaging the entire Java brand. and should be discontinued ASAP. Even before the recent security issues raised their ugly heads there have been several issues with either launching Java applications from within a web page or running them as applets and the user experience has been dismal to say the least. The main reason why Java applets had such a short-lived period of popularity was because Flash came along. Flash applets started significantly faster, didn't pop-up any security warnings and almost always just worked. The exact opposite was true of applets and, sadly, this has only gone further downhill lately. For many years the browser vendors have gone out of their way to make running Java in the browser a very painful experience for the end user. Now we have the situation where most people assume every Java applet is a security threat and avoid them like the plague. Anyway, I do not believe Java, JavaFX or any plugin-based technology has any place in a web browser. This includes Flash and Silverlight. We have HTML5 for that kind of app. Surely it won't be long until all browser vendors make it *impossible* for Java to run inside the browser or simply not support *any* plugins. What's the point of investing any further effort into the Java Plugin? Yes, I know there are legacy apps and applets out there that need to run but Oracle should be focused on getting JavaFX into the modern platforms and their associated app stores. Why not issue an End Of LIfe bulletin that signals the end of the Java Plugin so anyone out there still relying on Java applets can have time to find an alternative. Let's face it, almost *all* the security vulnerabilities exposed in recent months only affect Java in the browser. All the effort Oracle expends on patching these vulnerabilities and tightening up the security model should be spent on advancing JavaFX on mobiles and tablets. -jct - Original Message - From: Daniel Zwolenski zon...@gmail.com To: David Ray cognitionmiss...@gmail.com Cc: mike.ehrenb...@barchart.com Ehrenberg mike.ehrenb...@barchart.com, openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net, JeremyJongsma jer...@barchart.com Sent: Fri, 19 Jul 2013 06:47:46 +1000 Subject: Re: JavaFX 8 Progress Among general complaints and my own disasters with it, I had this guy write to me: http://web-conferencing-central.com The failure of webstart is making him lose customers (they literally are emailing him and telling him it's too hard to install). This is one of the very few commercial, public apps that use desktop-java and webstart (I'd be keen to know about any others - I know of none that use jfx?). From what I understand of the work being carried out, I highly doubt any of the fixes or improvements being worked on are going to help people like this. I love the idea of web deployment but it's failed and getting worse with the complexities now added in your attempts to keep it secure. In my opinion, web deploy should be deprecated or at least placed in minimal 'bandaid' only fixes and all effort should be put into making native bundles actually useful and into adding app store support. On 19/07/2013, at 2:10 AM, David Ray cognitionmiss...@gmail.com wrote: I don't want to open up the webstart can of worms here, but we have multiple issues surrounding recognition and validity of signed jars when using certain VMARGS in combination with OSGi style deployment. We finally settled on JWrapper due to WebStarts apparent brittleness - but as you say, this is neither here nor there as far as JavaFX is concerned… Anyway
Re: JavaFX8 on iPhone! It works!
Thanks Niklas - sounds like there's still a bit to do. I'm still a bit confused though, I thought the JFX team were/are giving us a version of jfx that is specifically designed to work on Android but it sounds like that's pretty far from the actuality? What will the gradle build for android actually give us? I'd be keen to hear from someone on the jfx side on all of this. Is this how you planned for your smart device releases to work or has something gone wrong in the journey here? On 05/07/2013, at 9:57 PM, Niklas Therning nik...@therning.org wrote: mime-attachment.txt
Re: JavaFX8 on iPhone! It works!
You guys have obviously had jfx running on both ios and android internally before for demos (and I assume you're testing this code you're releasing?). What JVMs are you using for this? Niklas I'm assuming that robovm used the android base because j8 features are either not possible or much more work to support. Is this the case or was there another reason for that choice? I'm assuming that at best moving to j8 is not a trivial or quick task? Making the backport fully android focused would seem like the shortest path for both ios and and android here? It's not great that there's so much to change in jfx for this to work. Apart from the extra hassle/delay now, this is going to make maintaining this backport and keeping it inline with bug fixes and updates messy. On 06/07/2013, at 12:42 AM, Richard Bair richard.b...@oracle.com wrote: We have implementations for Android and iOS that are both functional on a Java 8 VM. It looks like, because the iOS one is so closely related to the Mac build, it was the easiest one to get a build for the open community. We're working on the Android build scripts. The situation on Android is exactly the same as iOS -- we're open sourcing the library code, but not a Java 8 VM. I would expect that if the iOS build on RoboVM works, that the Android build for RoboVM would also work, but I haven't tried it. Richard On Jul 5, 2013, at 5:07 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Niklas - sounds like there's still a bit to do. I'm still a bit confused though, I thought the JFX team were/are giving us a version of jfx that is specifically designed to work on Android but it sounds like that's pretty far from the actuality? What will the gradle build for android actually give us? I'd be keen to hear from someone on the jfx side on all of this. Is this how you planned for your smart device releases to work or has something gone wrong in the journey here? On 05/07/2013, at 9:57 PM, Niklas Therning nik...@therning.org wrote: mime-attachment.txt
Re: JavaFX8 on iPhone! It works!
As the platform architect, what direction would you suggest the community take to make JFX work on iOS and on Android? If Oracle came to their senses and said: Richard, that whole smart device space might actually be more than a passing fad, let's put jfx on it, and do it whatever way you think best, what would your implementation strategy look like? Would you backport or use another VM or do your own VM impl, or what? How long would you expect whatever strategy you'd pick to take, how many resources would you have on it, and what bits would you see needing the most attention, what would your milestones look like, etc. I don't see why Oracle not doing this doesn't mean we can't get your guidance and wisdom on this if you're willing to provide it. And looking particularly here beyond hello worlds and brick breaker demos, at a sustainable robust, performant platform that can be used and relied upon for commercial use both now and as java 8, 9, 10 etc come out. I get the feeling were a long long way from that, if indeed it's achievable. What's your view on this? On 06/07/2013, at 12:34 PM, Richard Bair richard.b...@oracle.com wrote: It's complicated. We've prototyped on all kinds of VMs including the CVM used with ADF mobile and a hacked up Java SE embedded 7. It's a long way from prototype to product and as I mentioned on my blog we have not announced any plan around SE embedded VM on iOS / Android. But at least we know that our port of fx was (mostly) functional and could be successful. On Jul 5, 2013, at 12:44 PM, Tobias Bley t...@ultramixer.com wrote: Richard, the question is: Has Oracle a hidden Java8 VM for Android and iOS? Or how do you test your Android and iOS JavaFX implementation??? Am 05.07.2013 um 16:42 schrieb Richard Bair richard.b...@oracle.com: We have implementations for Android and iOS that are both functional on a Java 8 VM. It looks like, because the iOS one is so closely related to the Mac build, it was the easiest one to get a build for the open community. We're working on the Android build scripts. The situation on Android is exactly the same as iOS -- we're open sourcing the library code, but not a Java 8 VM. I would expect that if the iOS build on RoboVM works, that the Android build for RoboVM would also work, but I haven't tried it. Richard On Jul 5, 2013, at 5:07 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Niklas - sounds like there's still a bit to do. I'm still a bit confused though, I thought the JFX team were/are giving us a version of jfx that is specifically designed to work on Android but it sounds like that's pretty far from the actuality? What will the gradle build for android actually give us? I'd be keen to hear from someone on the jfx side on all of this. Is this how you planned for your smart device releases to work or has something gone wrong in the journey here? On 05/07/2013, at 9:57 PM, Niklas Therning nik...@therning.org wrote: mime-attachment.txt
Re: iOS: current state of RoboVM 0.0.2 + latest gradle based OpenJFX on iOS
+100 On Wed, Jul 3, 2013 at 10:26 PM, cogmission1 . cognitionmiss...@gmail.comwrote: Hi, Is that being worked on or did we just hit a brick wall? David On Wed, Jul 3, 2013 at 4:31 AM, Tobias Bley t...@ultramixer.com wrote: Hi, I tried to use the latest gradle based OpenJFX on iOS using RoboVM. Current state: it fails: The reason why is the font rendering using CoreText which currently is not possible on iOS. Take a look here: coretext.c = #if TARGET_OS_MAC !(TARGET_OS_IPHONE) The alternative would be to use the T2K renderer, which is not available in OpenJFX. So currently we have to wait for an implementation of CoreText native code on iOS. Best regards, Tobi
Re: API REVIEW for TabPane tab content loading and fixed content size
Hi Paru,
What do you mean by 'loaded'?
Currently we create the tabs and then manually add them doing something
like:
TabPane tabPane = new TabPane();
tabPane.getTabs().add(new Tab(Tab1));
Wouldn't all the 'loading' have already happened before TabPane gets a look
in? Or are you talking about when the tabs get added to the scene?
Cheers,
Dan
On Thu, Jul 4, 2013 at 7:03 AM, Paru Somashekar
parvathi.somashe...@oracle.com wrote:
JIRA :
https://javafx-jira.kenai.com/**browse/RT-24105https://javafx-jira.kenai.com/browse/RT-24105
https://javafx-jira.kenai.com/**browse/RT-30648https://javafx-jira.kenai.com/browse/RT-30648
The following is API to control how tab content gets loaded for a TabPane
in order to improve startup time and runtime performance for a TabPane.
Jonathan has already reviewed the following API and I have incorporated
his feedback. Thanks Jonathan.
TabContentSceneGraphPolicy is a static enum within TabPane
--**--
public static enum TabContentSceneGraphPolicy {
//The content all the tabs get loaded up front with no
optimization. If there are a lot of tabs and content is large - this could
potentially cause slow start up time. This is the default behavior.
ALL_TABS,
//Only the content of the selected tab will be loaded on startup
and other tabs get loaded on selection. When a new tab is selected, its
content is loaded into the scenegraph and the content of the previously
selected tab is unloaded from the scenegraph.
SELECTED_TAB,
//Only the content of the selected tab will be loaded at startup
and content of other tabs get loaded lazily in the background. Hence there
is no loading and unloading of tab content when different tabs are selected
as in the case of SELECTED_TAB option.
SELECTED_TAB_WITH_LAZY_LOADING
}
--**--**--
API to specify fixed Width/Height/Size for tab content.
private DoubleProperty fixedWidth
public final void setFixedWidth(double value)
public final double getFixedWidth()
public final DoubleProperty fixedWidthProperty()
private DoubleProperty fixedHeight
public final void setFixedHeight(double value)
public final double getFixedHeight()
public final DoubleProperty fixedHeightProperty()
public final void setFixedSize(double width, double height)
--**--**
Notes on performance considerations
The TabPane offers some performance optimizations in the area of tab
content loading. Basically the default policy is to load the contents of
all specified tabs. If the TabPane consists of a large number of big
content tabs, then this could lead to a potential slow start up time, as it
will have to spend some time in loading all the content up front before
starting up.
In such situations, the TabPane allows specification of the
TabContentSceneGraphPolicy which determines how the tab contents are loaded
: all tabs, selected tab only, or selected tab and lazy loading of the rest
of the tabs. The selected tab only option also ensures the content of the
previously selected tab is removed from the scenegraph. This gives the
added benefit of ensuring that no scenegraph related activities are
performed on any of the tab contents that is not currently selected.
However this could potentially cause the tab switch operation to be a bit
slow. In order to achieve faster tab switch operation, the third option is
provided where the content of the rest of the tabs are loaded lazily in the
background. However the lazy loading option could result in a slower
runtime performance.
Another area of optimization is provided for specifying a fixed width /
height / size of the tab content area. If a fixed value is specified,
measurement of the tab content sizes for the purpose of setting the
available space is eliminated, thus providing faster resize operations on
windows that contain a TabPane in them.
--**--**---
There might be a situation where the TabContentSceneGraphPolicy is set to
SELECTED_TAB in which case only the content of the selected tab is loaded
and user does not set fixed size. In such a case, we can either do one of
the following,
1) hardcode a fixed size if it is not already set
2) measure the selected tab only and grow in size only if the size of the
next selected tab is bigger than the previous one.
3) throw an exception if SELECTED_TAB is chosen and fixed size is not set.
I prefer option either 1 or 2, that way we do not force the developer to
set a fixed size for the tab content.
Thoughts suggestions welcome, I shall go with option 1 if I don't hear any.
Re: API REVIEW for TabPane tab content loading and fixed content size
I'd probably be a little cautious about the term 'loading' then. In
particular, I'd probably read 'LAZY_LOADING' to hint that the actual tabs
themselves would be loaded/created lazily (a common use case). Might be
just me though.
It looks like the 'lazy' option actually does them eagerly (i.e. all on
startup - not so lazy :) ), just asynchronously. I wonder if there is a
need for one that does them truly 'lazily' (i.e. on selection) much like
the SELECTED_TAB but once first loaded it then keeps it there instead of
adding and removing each selection.
Maybe not the best names below but some ideas:
enum TabContentSceneGraphPolicy {
// The content all the tabs are *added* to the scenegraph up front
with no optimization. If there are a lot of tabs and content is large -
this could potentially cause slow start up time. This is the default
behavior.
ALL_TABS,
//Only the content of the selected tab will be *added* to the
scenegraph at startup and content of other tabs get *added* *asynchronously* in
the background. Hence there is no *adding* and *removing* of tab content
when different tabs are selected as in the case of the SELECTED_TAB options.
ALL_TABS_ASYNCH,
//Only the content of the selected tab will be *added to the **
scenegraph* on startup and other tabs get *added* on selection. When a new
tab is selected, its content is *added* into the scenegraph and the content
of the previously selected tab is *removed* from the scenegraph.
SELECTED_TAB_AND_REMOVE,
//Only the content of the selected tab will be *added to the **
scenegraph* on startup and other tabs get *added* on selection. Once added,
a Tab is kept in the scenegraph. When a new tab is selected for the first
time, its content is *added* into the scenegraph, after that the tab is
re-shown when selected again.
SELECTED_TAB_AND_KEEP
}
On Thu, Jul 4, 2013 at 8:06 AM, Paru Somashekar
parvathi.somashe...@oracle.com wrote:
**
Hi Daniel,
Yes, loading is referring to when the tab content gets added to the scene.
The API to add tabs to TabPane remain the same - the new API is only
proposing a policy that controls how they get added removed from the
scenegraph.
thanks,
Paru.
On 7/3/13 2:35 PM, Daniel Zwolenski wrote:
Hi Paru,
What do you mean by 'loaded'?
Currently we create the tabs and then manually add them doing something
like:
TabPane tabPane = new TabPane();
tabPane.getTabs().add(new Tab(Tab1));
Wouldn't all the 'loading' have already happened before TabPane gets a
look in? Or are you talking about when the tabs get added to the scene?
Cheers,
Dan
On Thu, Jul 4, 2013 at 7:03 AM, Paru Somashekar
parvathi.somashe...@oracle.com wrote:
JIRA : https://javafx-jira.kenai.com/
browse/RT-24105https://javafx-jira.kenai.com/browse/RT-24105
https://javafx-jira.kenai.com/
browse/RT-30648https://javafx-jira.kenai.com/browse/RT-30648
The following is API to control how tab content gets loaded for a TabPane
in order to improve startup time and runtime performance for a TabPane.
Jonathan has already reviewed the following API and I have incorporated
his feedback. Thanks Jonathan.
TabContentSceneGraphPolicy is a static enum within TabPane
-- --
public static enum TabContentSceneGraphPolicy {
//The content all the tabs get loaded up front with no
optimization. If there are a lot of tabs and content is large - this could
potentially cause slow start up time. This is the default behavior.
ALL_TABS,
//Only the content of the selected tab will be loaded on startup
and other tabs get loaded on selection. When a new tab is selected, its
content is loaded into the scenegraph and the content of the previously
selected tab is unloaded from the scenegraph.
SELECTED_TAB,
//Only the content of the selected tab will be loaded at startup
and content of other tabs get loaded lazily in the background. Hence there
is no loading and unloading of tab content when different tabs are selected
as in the case of SELECTED_TAB option.
SELECTED_TAB_WITH_LAZY_LOADING
}
-- -- --
API to specify fixed Width/Height/Size for tab content.
private DoubleProperty fixedWidth
public final void setFixedWidth(double value)
public final double getFixedWidth()
public final DoubleProperty fixedWidthProperty()
private DoubleProperty fixedHeight
public final void setFixedHeight(double value)
public final double getFixedHeight()
public final DoubleProperty fixedHeightProperty()
public final void setFixedSize(double width, double height)
-- --
Notes on performance considerations
The TabPane offers some performance optimizations in the area of tab
content loading. Basically the default policy is to load
Re: JavaFX8 on iPhone! It works!
Trying to catch up to Tobi on this one so I can have some fun with it too. I assume in order to compile the graphics repo of JFX8 I need an OpenJ8 JDK already installed? Are there pre-built bundles for this (for mac) or do I need to checkout and build myself? Does anyone know which repo, and what command line arg should I use to build J8 in this case? On Thu, Jul 4, 2013 at 6:44 AM, Tobias Bley t...@ultramixer.com wrote: Hi Guys, I used RoboVM 0.0.2 and the current OpenJFX8 from mercurial graphics branch So no 78 backport. I will write a blog post on blog.software4java.com until tomorrow... Currently the performance is very limited - as Richard told too. I’m testing now all the basic JFX controls (like button, RadioButton, CheckBox, ListView, TableView, ...). Best regards, Tobi Am 03.07.2013 um 21:47 schrieb Daniel Zwolenski zon...@gmail.com: Tobi, this is awesome! But you've left us hanging :) Did you use the 78 backport for this or just straight out J8? What are the steps to reproduce your working build? Very darn exciting! On 04/07/2013, at 2:50 AM, Danno Ferrin danno.fer...@shemnon.com wrote: JavaFX 8? Does RoboVM support invokedynamic? That is a big deal if so. On Wed, Jul 3, 2013 at 10:07 AM, Niklas Therning nik...@therning.org wrote: Awesome! Can you please post the build instructions somewhere? I'm not getting a long with gradle at all. :-( On Wed, Jul 3, 2013 at 6:03 PM, Tobi t...@ultramixer.com wrote: It works! Latest JavaFX 8 (gradle based) with RoboVM on a real iPhone with native text rendering and JFX CSS rendering! Tobi
Re: JavaFX8 on iPhone! It works!
Thanks Richard, in the building for Mac section there is a link to Install the latest JDK 8 build that goes to a dead URL (http://jdk8.dev.java.net/). Do you know the correct URL? On Thu, Jul 4, 2013 at 9:11 AM, Richard Bair richard.b...@oracle.comwrote: Extensive documentation that is mostly correct: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX https://wiki.openjdk.java.net/display/OpenJFX/Developing+OpenJFX It is still a work in progress but most things you need to know to build is found here. Richard On Jul 3, 2013, at 3:52 PM, Daniel Zwolenski zon...@gmail.com wrote: Trying to catch up to Tobi on this one so I can have some fun with it too. I assume in order to compile the graphics repo of JFX8 I need an OpenJ8 JDK already installed? Are there pre-built bundles for this (for mac) or do I need to checkout and build myself? Does anyone know which repo, and what command line arg should I use to build J8 in this case? On Thu, Jul 4, 2013 at 6:44 AM, Tobias Bley t...@ultramixer.com wrote: Hi Guys, I used RoboVM 0.0.2 and the current OpenJFX8 from mercurial graphics branch So no 78 backport. I will write a blog post on blog.software4java.com until tomorrow... Currently the performance is very limited - as Richard told too. I’m testing now all the basic JFX controls (like button, RadioButton, CheckBox, ListView, TableView, ...). Best regards, Tobi Am 03.07.2013 um 21:47 schrieb Daniel Zwolenski zon...@gmail.com: Tobi, this is awesome! But you've left us hanging :) Did you use the 78 backport for this or just straight out J8? What are the steps to reproduce your working build? Very darn exciting! On 04/07/2013, at 2:50 AM, Danno Ferrin danno.fer...@shemnon.com wrote: JavaFX 8? Does RoboVM support invokedynamic? That is a big deal if so. On Wed, Jul 3, 2013 at 10:07 AM, Niklas Therning nik...@therning.org wrote: Awesome! Can you please post the build instructions somewhere? I'm not getting a long with gradle at all. :-( On Wed, Jul 3, 2013 at 6:03 PM, Tobi t...@ultramixer.com wrote: It works! Latest JavaFX 8 (gradle based) with RoboVM on a real iPhone with native text rendering and JFX CSS rendering! Tobi
Re: JavaFX8 on iPhone! It works!
Can I just use this: https://jdk8.java.net/download.html ? On Thu, Jul 4, 2013 at 9:15 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Richard, in the building for Mac section there is a link to Install the latest JDK 8 build that goes to a dead URL ( http://jdk8.dev.java.net/). Do you know the correct URL? On Thu, Jul 4, 2013 at 9:11 AM, Richard Bair richard.b...@oracle.comwrote: Extensive documentation that is mostly correct: https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX https://wiki.openjdk.java.net/display/OpenJFX/Developing+OpenJFX It is still a work in progress but most things you need to know to build is found here. Richard On Jul 3, 2013, at 3:52 PM, Daniel Zwolenski zon...@gmail.com wrote: Trying to catch up to Tobi on this one so I can have some fun with it too. I assume in order to compile the graphics repo of JFX8 I need an OpenJ8 JDK already installed? Are there pre-built bundles for this (for mac) or do I need to checkout and build myself? Does anyone know which repo, and what command line arg should I use to build J8 in this case? On Thu, Jul 4, 2013 at 6:44 AM, Tobias Bley t...@ultramixer.com wrote: Hi Guys, I used RoboVM 0.0.2 and the current OpenJFX8 from mercurial graphics branch So no 78 backport. I will write a blog post on blog.software4java.com until tomorrow... Currently the performance is very limited - as Richard told too. I’m testing now all the basic JFX controls (like button, RadioButton, CheckBox, ListView, TableView, ...). Best regards, Tobi Am 03.07.2013 um 21:47 schrieb Daniel Zwolenski zon...@gmail.com: Tobi, this is awesome! But you've left us hanging :) Did you use the 78 backport for this or just straight out J8? What are the steps to reproduce your working build? Very darn exciting! On 04/07/2013, at 2:50 AM, Danno Ferrin danno.fer...@shemnon.com wrote: JavaFX 8? Does RoboVM support invokedynamic? That is a big deal if so. On Wed, Jul 3, 2013 at 10:07 AM, Niklas Therning nik...@therning.org wrote: Awesome! Can you please post the build instructions somewhere? I'm not getting a long with gradle at all. :-( On Wed, Jul 3, 2013 at 6:03 PM, Tobi t...@ultramixer.com wrote: It works! Latest JavaFX 8 (gradle based) with RoboVM on a real iPhone with native text rendering and JFX CSS rendering! Tobi
Re: javafx-font opensourced
Why not use Sonatype for your repo? For third party jars that aren't in central, you can upload these assuming the licence allows it: https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository For your own stuff that you aren't going to publish for real but still want to be available (e.g. latest releases of JFX), publish it as a SNAPSHOT. For real stuff, publish it proper into the Maven repo and make it available for use by the community. It certainly would make my life massively more enjoyable if a build of the JRE was available for download for each of the platforms. And things like win-launcher.exe and other secondary assets would also make it much easier to work on the packaging tools, etc. On Fri, Jun 21, 2013 at 2:34 PM, Richard Bair richard.b...@oracle.comwrote: Yes, working on the web view building. The main issue is there are a handful of libs (libxml, libxslt, etc) that we have to figure out where to put. I believe these are unaltered by us, but built with different flags to strip out stuff we don't need. I've asked Peter whether we can post the build instructions to produce these libs, and then figured once anyone can build them, it wouldn't be to hard to find a place to put them. Ultimately we're trying to get a public artifactory repository setup for OpenJDK which would be the natural place for us to put all our dependencies like this, but in the meantime we just need a place to put some binaries. I know some of these binaries could be found elsewhere but not all of them (win64 builds I think are missing for example). On Jun 20, 2013, at 8:56 PM, Danno Ferrin danno.fer...@shemnon.com wrote: On Thu, Jun 20, 2013 at 5:21 PM, Daniel Zwolenski zon...@gmail.com wrote: This time sending to the list (gets me every time!): Great news! Danno - where does this put us with the JFX78 backport? Can we get a build of this for iOS now or what's needed to close this loop? The good news is that my JFX78 project now compiles via gradle without needing a stub jar. I took out the date picker and the builders for media and web view. So you can download it locally and build a jfxrt.jar and likely use the ios libs that build currently. I haven't poked around too much with the native bits. (see https://bitbucket.org/narya/jfx78) I also have been working on some maven distribution for this, not ready for consumption yet but an accessory build file creates the poms and handles the upload tasks ( https://bitbucket.org/narya/jfx78/src/3fe6c37ebdfbed33d1bdc9ad9d6a2037972de680/narya.gradle?at=default ). The date picker will return when the threetenbp jars are updated, and media when those files are released. WebView I either need to submit a patch to get it building in gradle or be patient. But honestly all three of these rank in priority for me below writing a jfpackager bundler that wraps robovm. The RoboVM Maven plugin is working. I'd be keen to make it work with JFX auto included so basically you can create a normal project and run mvn robovm:ipad-simulator (robovm:ios-device is under construction) and next thing you have a running JFX app on iOS, no mess, no fuss. I have a pitch for a suite of fairly major app development next week. So many unknowns with JFX and app development at this stage! I'm still pretty disappointed that JFX on iOS/Android is not officially supported by Oracle (such a massive wtf? for me) - makes it such a risky prospect for us on the front line. On Fri, Jun 21, 2013 at 3:47 AM, Felipe Heidrich felipe.heidr...@oracle.com wrote: Hello, We have just open-sourced javafx-font and javafx-font-native! Note that a lot of the code we open-sourced today is a new implementation based on native text technologies (CoreText for the Mac and DirectWrite for Windows). We still have a lot of work to do: - finishing the new linux implementation is a big one - testing - improve on sub pixel position text - etc Help is most welcome, Thank you Felipe
Re: javafx-font opensourced
While I agree with Tom that setting up a Nexus (or Artifactory) repo is easy, I don't see any point for OSS stuff. That's what Sonatype is for, take advantage of it. Setting up your own Nexus (or Artifactory) is needed if you have proprietary stuff that you want to keep private or have licensing restrictions on, but the whole point of OpenJDK is to not be that - OSS Sonatype exists to make life easier for exactly these sorts of projects. You may want to setup an internal Nexus inside for your Oracle stuff but then you definitely wouldn't be giving us access to that. On Fri, Jun 21, 2013 at 5:01 PM, Tom Eugelink t...@tbee.org wrote: What I wanted to say with that (friends always accuse me of not being to the point) is that by running a Nexus repo yourself, - Oracle is self hosting - But also immediately compatible with Maven, Gradle, Ivy, etc - Allow other repo's to easily proxy, which improves availability I'm more than happy to setup a Nexus. Tom On 2013-06-21 08:56, Tom Eugelink wrote: Installing Nexus is extremely simple (kudo's to sonatype for that). I've got a copy running myself, proxying all kinds of other repo's, just to be not dependent on other hosting. Tom On 2013-06-21 08:51, Richard Bair wrote: Oracle has this thing about wanting to self host everything. However that doesn't stop the community from putting OpenJDK / OpenJFX stuff somewhere reasonable until Oracle finally gets all the infrastructure in place and the OpenJDK project can then take advantage of it. Richard On Jun 20, 2013, at 11:34 PM, Daniel Zwolenski zon...@gmail.com wrote: Why not use Sonatype for your repo? For third party jars that aren't in central, you can upload these assuming the licence allows it: https://docs.sonatype.org/**display/Repository/Uploading+** 3rd-party+Artifacts+to+The+**Central+Repositoryhttps://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository For your own stuff that you aren't going to publish for real but still want to be available (e.g. latest releases of JFX), publish it as a SNAPSHOT. For real stuff, publish it proper into the Maven repo and make it available for use by the community. It certainly would make my life massively more enjoyable if a build of the JRE was available for download for each of the platforms. And things like win-launcher.exe and other secondary assets would also make it much easier to work on the packaging tools, etc. On Fri, Jun 21, 2013 at 2:34 PM, Richard Bair richard.b...@oracle.com wrote: Yes, working on the web view building. The main issue is there are a handful of libs (libxml, libxslt, etc) that we have to figure out where to put. I believe these are unaltered by us, but built with different flags to strip out stuff we don't need. I've asked Peter whether we can post the build instructions to produce these libs, and then figured once anyone can build them, it wouldn't be to hard to find a place to put them. Ultimately we're trying to get a public artifactory repository setup for OpenJDK which would be the natural place for us to put all our dependencies like this, but in the meantime we just need a place to put some binaries. I know some of these binaries could be found elsewhere but not all of them (win64 builds I think are missing for example). On Jun 20, 2013, at 8:56 PM, Danno Ferrin danno.fer...@shemnon.com wrote: On Thu, Jun 20, 2013 at 5:21 PM, Daniel Zwolenski zon...@gmail.com wrote: This time sending to the list (gets me every time!): Great news! Danno - where does this put us with the JFX78 backport? Can we get a build of this for iOS now or what's needed to close this loop? The good news is that my JFX78 project now compiles via gradle without needing a stub jar. I took out the date picker and the builders for media and web view. So you can download it locally and build a jfxrt.jar and likely use the ios libs that build currently. I haven't poked around too much with the native bits. (see https://bitbucket.org/narya/**jfx78https://bitbucket.org/narya/jfx78 ) I also have been working on some maven distribution for this, not ready for consumption yet but an accessory build file creates the poms and handles the upload tasks ( https://bitbucket.org/narya/**jfx78/src/** 3fe6c37ebdfbed33d1bdc9ad9d6a20**37972de680/narya.gradle?at=**defaulthttps://bitbucket.org/narya/jfx78/src/3fe6c37ebdfbed33d1bdc9ad9d6a2037972de680/narya.gradle?at=default ). The date picker will return when the threetenbp jars are updated, and media when those files are released. WebView I either need to submit a patch to get it building in gradle or be patient. But honestly all three of these rank in priority for me below writing a jfpackager bundler that wraps robovm. The RoboVM Maven plugin is working. I'd be keen to make it work with JFX auto included so basically you can create a normal project and run mvn robovm:ipad
Re: javafx-font opensourced
Ok, that's how I read it, and so as per my email Sonatype still makes sense to me as the spot to put these libs (see the link I linked to). And, as I said, once you start using it for your third party repos it's a small step to then start deploying the actual built artifacts into it, which is something I've been asking for since I first joined in when 2.0 was in beta. We couldn't do it before now because of legal reasons with Oracle. Now we can legally do it but it's technically very, very easy for you guys to do and very hard for us to do. I have already the Sonatype groupId setup and waiting for you to use so most of red tape part is already done. I don't really see any reason not to do this but you seem reluctant? What's the reason for the reluctance? On Fri, Jun 21, 2013 at 5:14 PM, Richard Bair richard.b...@oracle.comwrote: Are we talking Oracle or OpenJDK here. I got the impression those libs were Open? Right, it is confusing. Much of the code we (meaning the build system) are building all the time (for example, all of webkit or gstreamer). However some of it (libxslt, libxml, some others) we have only built and then loaded up onto an internal web server as a zip. The existing closed ant build system downloads that zip and unpacks it, and then the existing ant build uses those libraries for building webkit and producing the final artifacts. So in order to get the build working we either need to include the sources for these libs and build them every time, or build them once and put them someplace that Gradle can download them from. The ideal thing would be for OpenJDK to have a public binary repository in which we can put all our OpenJDK stuff (including snapshots of every build, and all the native libraries, etc) and then our gradle build can just pull everything from there. However in the meantime, I'd be happy if those native libs lived anywhere and we wired it up in the gradle build to make it automatic. The point I was making about Oracle vs OpenJDK is just that the Official Java / JavaFX / Oracle JDK builds will always probably be downloaded via that web page and the continuous builds of that might not be exposed in a binary repository. But the OpenJDK / OpenJFX builds certainly could be AFAIK and certainly could be hosted by anybody on any server since it is all just GPL. So what I was referring to wasn't putting builds of OpenJFX into Maven so much as putting the libxml, libxslt, and other web dependencies someplace like maven that we could then pull from in order to be able to build web view. Richard
NullPointer in BaseGraphics.drawTextureVO
Can anyone tell me what might cause the exception below in Prism? It's from an app that captures video via a native library (LTI-CIVIL) and then converts that image to JFX display via: BufferedImage buffImage = AWTImageConverter.toBufferedImage(image); jfxImage = javafx.scene.image.Image.impl_fromExternalImage(buffImage); previewView.setImage(jfxImage); java.lang.NullPointerException at com.sun.prism.impl.BaseGraphics.drawTextureVO(BaseGraphics.java:365) at com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:334) at com.sun.prism.impl.ps.BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:103) at com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:315) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.tk.quantum.PaintRunnable.doPaint(PaintRunnable.java:214) at com.sun.javafx.tk.quantum.PaintRunnable.paintImpl(PaintRunnable.java:145) at com.sun.javafx.tk.quantum.PaintRunnable.run(PaintRunnable.java:349) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at com.sun.prism.render.RenderJob.run(RenderJob.java:29) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:101) at java.lang.Thread.run(Thread.java:722)
Re: NullPointer in BaseGraphics.drawTextureVO
This is an older version, probably JFX from around jdk1.7.0_02. I'm running it now on jdk1.7.0_21 to see what happens (takes about an hour to get to the point of failure, which is why I didn't pick it up when I wrote the code originally). Unfortunately chunks of the system are broken when it runs on this newer code. Lots of backwards compatibility breaks, especially visual ones with CSS that just make it screwy. This is an old project and I don't really want to be touching this code but they have this video capture bug which is killing everything. I take it there's no way to avoid the resources issue in the old JFX, it's just a plain and simple bug? On Tue, Jun 11, 2013 at 11:10 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Is this from FX 2.2.x or FX 8? The stack trace suggests an earlier version of FX. The only thing I can think of off hand is that the HW texture couldn't be created, probably because you ran out of resources. There are a few issues relating to this, which we believe are fixed in FX 8 with the implementation of RT-25323. -- Kevin Daniel Zwolenski wrote: Can anyone tell me what might cause the exception below in Prism? It's from an app that captures video via a native library (LTI-CIVIL) and then converts that image to JFX display via: BufferedImage buffImage = AWTImageConverter.**toBufferedImage(image); jfxImage = javafx.scene.image.Image.impl_** fromExternalImage(buffImage); previewView.setImage(jfxImage)**; java.lang.NullPointerException at com.sun.prism.impl.**BaseGraphics.drawTextureVO(** BaseGraphics.java:365) at com.sun.prism.impl.**BaseGraphics.drawTexture(**BaseGraphics.java:334) at com.sun.prism.impl.ps.**BaseShaderGraphics.**drawTexture(** BaseShaderGraphics.java:103) at com.sun.javafx.sg.prism.**NGImageView.renderContent(** NGImageView.java:315) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**185) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**39) at com.sun.javafx.sg.BaseNode.**render(BaseNode.java:1139) at com.sun.javafx.sg.prism.**NGGroup.renderContent(NGGroup.**java:205) at com.sun.javafx.sg.prism.**NGRegion.renderContent(**NGRegion.java:420) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**185) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**39) at com.sun.javafx.sg.BaseNode.**render(BaseNode.java:1139) at com.sun.javafx.sg.prism.**NGGroup.renderContent(NGGroup.**java:205) at com.sun.javafx.sg.prism.**NGRegion.renderContent(**NGRegion.java:420) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**185) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**39) at com.sun.javafx.sg.BaseNode.**render(BaseNode.java:1139) at com.sun.javafx.sg.prism.**NGGroup.renderContent(NGGroup.**java:205) at com.sun.javafx.sg.prism.**NGRegion.renderContent(**NGRegion.java:420) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**185) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**39) at com.sun.javafx.sg.BaseNode.**render(BaseNode.java:1139) at com.sun.javafx.sg.prism.**NGGroup.renderContent(NGGroup.**java:205) at com.sun.javafx.sg.prism.**NGRegion.renderContent(**NGRegion.java:420) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**185) at com.sun.javafx.sg.prism.**NGNode.doRender(NGNode.java:**39) at com.sun.javafx.sg.BaseNode.**render(BaseNode.java:1139) at com.sun.javafx.tk.quantum.**PaintRunnable.doPaint(** PaintRunnable.java:214) at com.sun.javafx.tk.quantum.**PaintRunnable.paintImpl(** PaintRunnable.java:145) at com.sun.javafx.tk.quantum.**PaintRunnable.run(** PaintRunnable.java:349) at java.util.concurrent.**Executors$RunnableAdapter.** call(Executors.java:471) at java.util.concurrent.**FutureTask$Sync.**innerRunAndReset(FutureTask.** java:351) at java.util.concurrent.**FutureTask.runAndReset(**FutureTask.java:178) at com.sun.prism.render.**RenderJob.run(RenderJob.java:**29) at java.util.concurrent.**ThreadPoolExecutor.runWorker(** ThreadPoolExecutor.java:1110) at java.util.concurrent.**ThreadPoolExecutor$Worker.run(** ThreadPoolExecutor.java:603) at com.sun.javafx.tk.quantum.**QuantumRenderer$**PipelineRunnable.run(** QuantumRenderer.java:101) at java.lang.Thread.run(Thread.**java:722)
Re: NullPointer in BaseGraphics.drawTextureVO
) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:98) at java.lang.Thread.run(Thread.java:722) On Wed, Jun 12, 2013 at 12:55 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: ** I take it there's no way to avoid the resources issue in the old JFX, it's just a plain and simple bug? I don't know of a way to completely avoid it. As far as we know there aren't any actual leaks in the more recent FX 2.2.x texture code, but the resource disposal is not deterministic and if you hit the limit of texture memory it does not recover gracefully (or at all). Jim might have more insight, since he implemented the new texture management system for FX 8.; -- Kevin Daniel Zwolenski wrote: This is an older version, probably JFX from around jdk1.7.0_02. I'm running it now on jdk1.7.0_21 to see what happens (takes about an hour to get to the point of failure, which is why I didn't pick it up when I wrote the code originally). Unfortunately chunks of the system are broken when it runs on this newer code. Lots of backwards compatibility breaks, especially visual ones with CSS that just make it screwy. This is an old project and I don't really want to be touching this code but they have this video capture bug which is killing everything. I take it there's no way to avoid the resources issue in the old JFX, it's just a plain and simple bug? On Tue, Jun 11, 2013 at 11:10 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Is this from FX 2.2.x or FX 8? The stack trace suggests an earlier version of FX. The only thing I can think of off hand is that the HW texture couldn't be created, probably because you ran out of resources. There are a few issues relating to this, which we believe are fixed in FX 8 with the implementation of RT-25323. -- Kevin Daniel Zwolenski wrote: Can anyone tell me what might cause the exception below in Prism? It's from an app that captures video via a native library (LTI-CIVIL) and then converts that image to JFX display via: BufferedImage buffImage = AWTImageConverter.toBufferedImage(image); jfxImage = javafx.scene.image.Image.impl_fromExternalImage(buffImage); previewView.setImage(jfxImage); java.lang.NullPointerException at com.sun.prism.impl.BaseGraphics.drawTextureVO(BaseGraphics.java:365) at com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:334) at com.sun.prism.impl.ps .BaseShaderGraphics.drawTexture(BaseShaderGraphics.java:103) at com.sun.javafx.sg.prism.NGImageView.renderContent(NGImageView.java:315) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:205) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:185) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1139) at com.sun.javafx.tk.quantum.PaintRunnable.doPaint(PaintRunnable.java:214) at com.sun.javafx.tk.quantum.PaintRunnable.paintImpl(PaintRunnable.java:145) at com.sun.javafx.tk.quantum.PaintRunnable.run(PaintRunnable.java:349) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at com.sun.prism.render.RenderJob.run(RenderJob.java:29) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:101) at java.lang.Thread.run(Thread.java:722)
Re: Tracking down an NPE
Cool, thanks - so the native packager requires that every one of the JARs used in the app (even the third party ones not built as part of the app) have a manifest in them? That's going to be very nasty. Regarding getting the javafx-ant jars into a repo, I started down this road a while back and have now access to the OSS repo for groupID 'net.java.openjdk.openjfx'. I gave up actually deploying it when I realised there was a different javafx-ant.jar for each native platform. I wasn't able to build them all (and the Windows build was patchy at best anyway). Happy to work with you on getting them into that repo if you want. Just let me know where you're up to with it and what you need. On Tue, Jun 11, 2013 at 8:27 AM, Danno Ferrin danno.fer...@shemnon.comwrote: At least one of your jars does not have a manifest: https://javafx-jira.kenai.com/browse/RT-24143 I'm tempted to get the JFX78 builds auto-deploying at least the javafx-ant jar to some repo so the build plugins can use JavaFX 8 deployment code on Java 7. On Mon, Jun 10, 2013 at 4:13 PM, Daniel Zwolenski zon...@gmail.comwrote: Any chance someone from Oracle could tell me what the line of code is in com.sun.javafx.tools.packager.bundlers.BundleParams at line 390? Someone is getting a NullPointer on this line when using the maven plugin and I can't work out why. The line number is different in the Sun code vs the open sourced one. Cheers, Dan
JFX Packager (was Re: Preloaders)
On Thu, Jun 6, 2013 at 5:52 PM, Danno Ferrin danno.fer...@shemnon.comwrote: On Wed, Jun 5, 2013 at 9:47 PM, Daniel Zwolenski zon...@gmail.com wrote: To sum up my previous major suggestions for a better world: - web deploy code should be separate module from native, and jar separate again. Each native module (win, Linux, Mac) should be separate and I should be able to invoke any and all of them how and when I want, not just one generateDeployment method as the only entry point. I think JNLP and web generation should be a bundler on the same level as win/mac/lin. No special treatment, it is just hte same as the rest Agreed, they are all the same level, but modularised at a code level so we can call generateJnlpBundle or generateWinExeBundle, generateWinMsiBundle. Currently there's this uber bundle going on that you can sort-of-if-you're-lucky turn some bits off. It's this uber bundling I'd like to see change in the future. Give me finer hook in points for the Maven plugin anyway. - java code of packager should be one library for all platforms so we have one jar for all, not a separate one for each OS. Native bits are referenced from this one jar as needed. I actually disagree with this. Perhaps the default bundlers come in one jar for hte JDK, but I would like the ability to add bundlers external to the tool that evolve at different speeds than the core JDK. Tha was the point of my service loader patch. Making the bundlers separate for the JDK is a good exercise in proving severability. Agree to being to add your own customisations by the core tools having plugin points. Also would love to see the packager tools not tied into the JDK and be on their own release cycle - this would be a massive win (wasn't a popular suggestion when I made it a while back). My point about one jar was more to do with the fact that currently the ant-javafx.jar at the moment is different in the Mac distro of the JDK to the Window version of the JDK, which is different again to a 32bit version of the ant-javafx.jar on a 32 bit windows JDK. 95% of the code is the same in all of these however there are slight differences to the Java code (or so I was told - by Ivan I think) and the native bits (winlauncher.exe for example) are included in the JAR (from memory). So effectively the ant-javafx.jar is platform specific. Messy to get all those platform specific JARs and put them in Maven (or whatever). You need to reference the right JAR for the platform you are on, even for doing, say a web build, which doesn't actually care. Also the native inter-twining makes it hard to build for testing and contributing, since I need to do the native builds, whereas if these were separate assets I could just mess with the Java code and use the native bits out of the repo. So when I say one jar maybe translate that to not platform specific JARs of stuff that doesn't need to be. - native should not have dumb stuff from web as a requirement if not used. Signing, special jfx meta-inf in jars, checking registry for jdk, etc, etc. Native is actually very simple and really should be able to work with a stock standard jar and not need a special jfx built one. Web should be quarrantined so that native isn't sullied by it. Sullied is a bit of a harsh word. I'm afraid I've come to hate the web deployment stuff (partly disappointment because it held so much potential). The code in the packager is really messy and makes me angry when I try and work with it. Most of it is over engineering as far as I can tell. It also doesn't work reliably. And web deploy is the reason security problems are possible. And... I'll stop there. Unfortunately, native bundles were an after thought and just tacked on. The Native bundler code in the packager is tightly intertwined with this web code currently. I'd like to see that change. e.g. Why do we need version checks on JRE's etc, when we have a co-bundled JRE in our native app? Deployment modes are different For example, a Mac App, iOS app, and Android APK all still need to be signed, their deployment models for signing are different. Yep, agreed. My preference is that each one should be a separate module in the packager, so they can each do whatever is special for them. APK should not have complexities resulting from native, and native not from web, and web not from APK, etc. Each module should deal with the job of building a distro for that platform in the simplest and cleanest way. There would definitely be some re-used code (like signing) that is in a common spot but at the moment the native launcher depends on a JFX built JAR which includes stuff only needed for web, etc. And I agree, I should be able to build my own custom bundle builder that just slots into the framework alongside the others. I should be able to leverage the common code (like signing) from my custom module. - no magic config in the core libraries (higher wrappers can try and add
Re: Preloaders
Thanks Mark. If the user sets a preloader in the plugin I'm going to pass that same class to the jar and to the native bundle. I guess people will complain to me if that doesn't work and I'll point them your way. Are they ever going to let you do some packager stuff? I gave up waiting for the revolution and rebuilt the maven plugin to be less crap than it was but its the underlying packaging tools that need the rewrite if JFX is ever going to have a decent deployment option. On 05/06/2013, at 3:58 AM, Mark Howe mark.h...@oracle.com wrote: It should be the one within the bundle otherwise deploying an app bundle won't work. If you find otherwise please create an issue. Cheers Mark On May 29, 2013, at 6:51 AM, Scott Palmer swpal...@gmail.com wrote: I think native bundles should use the preloader contained within. I use the Preloader to implement a splash screen since my app takes a long time to start up, even though all the jars are already downloaded. On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski zon...@gmail.com wrote: The jfx packaging tools allow pre-loaders to be set. I don't use them but people using the maven plugin want them. It looks like you can set a preloader for both jars and for bundles (web, native). When building the bundles however they include the jar in them. So we end up with both the bundle, and the jar within the bundle, getting the preloader set. Does anyone know what will or should happen in this case? Does one preloader take precedence and the other is ignored, or are both used at different times and I should allow the user to set a different jar preloader to the bundle one, or is this setup invalid and I should actually not pass the preloader setting to one or the other in this case? Not using Preloaders myself and with the packaging tool code being a complete mess, it would be good to know the expectations here so I can properly support the users wanting this. Cheers Dan
Re: Preloaders
Great news - happy to provide more input and feedback into the new tools/APIs when you get to that. I'd guess that Danno's probably got some good input for that side of it too - would be great to keep the conversations open and on this mailing list. For my money, I'd vote for only show stopper bugs getting fixed on the existing packager code base, and you focus on getting it all cleaned up and working nice and a better pattern for contributions in place. That could allow us to contribute more and stop you churning endlessly on a backlog of bugs. Cheers, Dan On Thu, Jun 6, 2013 at 1:21 AM, Mark Howe mark.h...@oracle.com wrote: I actually spent at least half my time on the packager the last two weeks - woo hoo :). Still have other priorities but am finding time for the packager. Working on a few critical packager bugs right now. Then later this week going to finally get Danno's patches in. There are a lot of packager bugs in the backlog. Once some of that backlog is cleared up I am going to do some refactoring, really want to make the code simpler, cleaner and more obvious - and subsequently easier to contribute to. Cheers On Jun 5, 2013, at 5:14 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Mark. If the user sets a preloader in the plugin I'm going to pass that same class to the jar and to the native bundle. I guess people will complain to me if that doesn't work and I'll point them your way. Are they ever going to let you do some packager stuff? I gave up waiting for the revolution and rebuilt the maven plugin to be less crap than it was but its the underlying packaging tools that need the rewrite if JFX is ever going to have a decent deployment option. On 05/06/2013, at 3:58 AM, Mark Howe mark.h...@oracle.com wrote: It should be the one within the bundle otherwise deploying an app bundle won't work. If you find otherwise please create an issue. Cheers Mark On May 29, 2013, at 6:51 AM, Scott Palmer swpal...@gmail.com wrote: I think native bundles should use the preloader contained within. I use the Preloader to implement a splash screen since my app takes a long time to start up, even though all the jars are already downloaded. On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski zon...@gmail.com wrote: The jfx packaging tools allow pre-loaders to be set. I don't use them but people using the maven plugin want them. It looks like you can set a preloader for both jars and for bundles (web, native). When building the bundles however they include the jar in them. So we end up with both the bundle, and the jar within the bundle, getting the preloader set. Does anyone know what will or should happen in this case? Does one preloader take precedence and the other is ignored, or are both used at different times and I should allow the user to set a different jar preloader to the bundle one, or is this setup invalid and I should actually not pass the preloader setting to one or the other in this case? Not using Preloaders myself and with the packaging tool code being a complete mess, it would be good to know the expectations here so I can properly support the users wanting this. Cheers Dan
Re: Preloaders
To sum up my previous major suggestions for a better world: - everything should be easily configurable via runtime params passed to packager code: input paths, output paths, paths to native tools, resources, includes, file names, etc. Everything! - web deploy code should be separate module from native, and jar separate again. Each native module (win, Linux, Mac) should be separate and I should be able to invoke any and all of them how and when I want, not just one generateDeployment method as the only entry point. - java code of packager should be one library for all platforms so we have one jar for all, not a separate one for each OS. Native bits are referenced from this one jar as needed. - native should not have dumb stuff from web as a requirement if not used. Signing, special jfx meta-inf in jars, checking registry for jdk, etc, etc. Native is actually very simple and really should be able to work with a stock standard jar and not need a special jfx built one. Web should be quarrantined so that native isn't sullied by it. - no magic config in the core libraries (higher wrappers can try and add it on top). Eg It shouldn't look for wix and use it just because it's installed. I should be able to specify I want wix or inno and tools should fail if they are not there. That's just looking at improvements to what's already there. As far as my picks for new features, these would be my top: - app store support (desktop at this stage) - auto updating support for native bundles - cross platform builds on the one machine (ie build for Mac from a windows machine, etc). Also build a 32bit distro on a 64bit jdk, etc. - compact jre's for smaller distro sizes. Just a little wish list :) Cheers, Dan On 06/06/2013, at 1:15 PM, Danno Ferrin danno.fer...@shemnon.com wrote: For me the biggest add would be for some form of runtime configuration of the packager, as well as the bundler params. this would allow outside contributors to cerate an APK bundler or an iOS bundler of many forms without having to adjust the core code, and allowing them to be brought in at runtime (the runtime of the build). This also extends to the bundle params having an open-ended property set of some sort, so things that matter to random packaging formats don't leak into other bundle params. My dream would be to be able to create an APK or other such bundle just by flipping a param in the packager call form an otherwise desktop app. On Wed, Jun 5, 2013 at 8:33 PM, Daniel Zwolenski zon...@gmail.com wrote: Great news - happy to provide more input and feedback into the new tools/APIs when you get to that. I'd guess that Danno's probably got some good input for that side of it too - would be great to keep the conversations open and on this mailing list. For my money, I'd vote for only show stopper bugs getting fixed on the existing packager code base, and you focus on getting it all cleaned up and working nice and a better pattern for contributions in place. That could allow us to contribute more and stop you churning endlessly on a backlog of bugs. Cheers, Dan On Thu, Jun 6, 2013 at 1:21 AM, Mark Howe mark.h...@oracle.com wrote: I actually spent at least half my time on the packager the last two weeks - woo hoo :). Still have other priorities but am finding time for the packager. Working on a few critical packager bugs right now. Then later this week going to finally get Danno's patches in. There are a lot of packager bugs in the backlog. Once some of that backlog is cleared up I am going to do some refactoring, really want to make the code simpler, cleaner and more obvious - and subsequently easier to contribute to. Cheers On Jun 5, 2013, at 5:14 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Mark. If the user sets a preloader in the plugin I'm going to pass that same class to the jar and to the native bundle. I guess people will complain to me if that doesn't work and I'll point them your way. Are they ever going to let you do some packager stuff? I gave up waiting for the revolution and rebuilt the maven plugin to be less crap than it was but its the underlying packaging tools that need the rewrite if JFX is ever going to have a decent deployment option. On 05/06/2013, at 3:58 AM, Mark Howe mark.h...@oracle.com wrote: It should be the one within the bundle otherwise deploying an app bundle won't work. If you find otherwise please create an issue. Cheers Mark On May 29, 2013, at 6:51 AM, Scott Palmer swpal...@gmail.com wrote: I think native bundles should use the preloader contained within. I use the Preloader to implement a splash screen since my app takes a long time to start up, even though all the jars are already downloaded. On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski zon...@gmail.com wrote: The jfx packaging tools allow pre-loaders
Re: Canvas clip problems
Finally got round to testing this and setting -Dprism.order=j2d as Scott makes the smear go away. On Sun, Jun 2, 2013 at 11:16 AM, Scott Palmer swpal...@gmail.com wrote: Try -Dprism.order=sw with JavaFS 8 or -Dprism.order=j2d with JavaFX 2.2 to see if the clipping issue goes away. Also try -Dprism.dirtyopts=false to see if that fixes the smearing. On Sat, Jun 1, 2013 at 9:14 PM, Scott Palmer swpal...@gmail.com wrote: This looks like it may be related to the clipping issue that I'm having (the one that forces me o use the software pipeline in JavaFX 8 or the j2d pipeline in JavaX 2.2) https://javafx-jira.kenai.com/browse/RT-30591 I'll try to do the same screencast thingy, as the still in my report don't do justice to the problem. Scott On Sat, Jun 1, 2013 at 8:55 PM, Richard Bair richard.b...@oracle.comwrote: Cheese (the smear) should never be possible. It means that the clip used on the device is wrong for some reason, and therefore some area of the screen was not being repainted that needed to be. In Swing (or Android or any other immediate mode API) it is possible that your app could have a bug that causes this, but with the scene graph the responsibility is with JFX not to mess up the dirty regions. My guess is this is related to the other issue you already filed about the z order rendering issue (which is also related to the clip being wrong). It might be worth putting the link to the screencast on that bug report. Richard On Jun 1, 2013, at 3:21 PM, Daniel Zwolenski zon...@gmail.com wrote: Here is one I can't reproduce in smaller code. http://www.screencast.com/t/AJZjx1TjFT You can see that when the enemies start off the canvas they end up leaving a smear behind. When they leave the canvas at the other end they also smear. I suspect it's something to do with the clipping code used in the game but I haven't been able to narrow it down (and this area I was a bit flaky on and I think Richard did the starting setup for). It's probably a case of clipping properly, but should this sort of behaviour be even possible to occur? p.s. thanks for the Camtasia tips - nice product.
Re: When will JFX be fully open sourced?
Danno, what do you need to wrap it up? Basically I'm intending to have the Maven plugin automatically use a build of Danno's backport for iOS (that I'm hoping Danno will provide for me). Once this exists I can do the Maven side of it. On Wed, Jun 5, 2013 at 10:33 AM, Richard Bair richard.b...@oracle.comwrote: The accessibility stuff is going out this week, and the font pieces in mid June. Media we're in process of but I don't have a date. Is there anything else missing? I had heard from Danno that fonts accessibility were the big blockers. Richard On Jun 4, 2013, at 5:09 PM, Daniel Zwolenski zon...@gmail.com wrote: Niklas and I have been working on getting the RoboVM Maven plugin working - it is in the final stages of testing. This is *without* JavaFX however. We are waiting on the final parts of JavaFX to be open sourced before doing this. When is this due to happen?
Re: ScrollPane.prefViewportWidth == computed size?
A similar, or at least related, issue I created a while back: https://javafx-jira.kenai.com/browse/RT-17988 On 04/06/2013, at 5:28 AM, Werner Lehmann lehm...@media-interactive.de wrote: Hi Richard, thanks for the quick reply. FYI, I am currently using a hardcoded value with some extra space, hopefully sufficient for all platforms. On 03.06.2013 20:57, Richard Bair wrote: I think calling it a bug would be fair, and this approach should work. I'll create a ticket later. Hmmm. I guess fitToWidth doesn't work for you because you want the content to dictate the size of the scroll pane, and not the other way around? Maybe a combination of this and a subclass to work around the issue you are seeing? Exactly. fitToWidth removes the horizontal scrollbar but abbreviates the label text (...). The suggested subclass approach does not work because prefWidth() is final in Control. Is there any event I could listen for to update the prefWidth? I tried onSceneChange but that seems to be too early as prefWidth(-1) returns 0.0 then. Or maybe the ScrollPane, when fitToWidth is true, automatically adjusts its pref width to match that of its content? That would seem to be the right thing to do in this case, but I don't know that it does (or that it makes sense in all cases?). ScrollPane.fitToWidth resizes its content (if resizable) to its viewport width. Does nothing if content is not resizable, and does not seem to change ScrollPane.prefWidth. I'd say fit-to-width could mean both: fit content to viewport width and fit viewport width to content. The former is already implemented, of course. No horizontal scrollbar in either case. So it seems to me that there are at least 2 different ways we could go about supporting this specific use case, one seems like a straightforward thing (let -1 have meaning for prefViewportWidth) and one is the result of a perhaps questionable interpretation (fitToWidth=true changes the way we compute the prefWidth of the ScrollPane). Both seem reasonable ways to have tried to use the control and both yield unexpected results it sounds like. The binding was not really obvious to me but eventually I arrived here and it would be nice to have this working. Additional API would make this easier to find but it might be hard to come up with something which makes sense in the API and does not change or conflict with existing API. Werner
Re: Performance Tips n' Tricks wiki page
This is very good. Looking forward to it growing. There's going to be a lot of work in building and maintaining that - would be great if it gets the love it needs. I do wonder if there should be a separate guide for embedded and mobile as they really are a set of unique problems that you probably only care about if doing that sort of stuff. Might help keep the desktop one more digestible. A couple of questions to add (sure I will have more over time): 1) turning cache to true and cache hint to SPEED I haven't seen explained what the drawbacks are to doing this. I assume there is some trade-off for turning this on otherwise it would be on by default? 2) AnimationTimer - how is this related to transitions (like TransitionTimer). They seem to be two very different things - not just at the usage level but the actual underlying performance and implementation - but it's not clear to me exactly the difference. I wanted to work with both AnimationTimer stuff and Transitions in a consistent way (e.g. pause one thing to pause my whole app). When trying to use the API my instinct was that the transitions used an underlying AnimationTimer, so I was looking for a way to setAnimationTimer on the transitions, so they all shared the same instance. I'm obviously seeing it wrong, but it's not clear to me why these things are so different. 3) If I have an app with multiple views (say 20 or 30) and I want to animate between them (slide in, out, etc). Should I have all the views already added to the scene and then just move them off-center (and/or make them invisible), or should I add and remove them at the start and end of each animation. I'd assumed that adding and removing was the way to go for performance, is this correct? The question really is: If a node is in the scene graph but not visible does it add much overhead to rendering, picking, etc? Doing something like Mac's Mission Control would be much easier if I didn't have to add/remove and could just zoom, but is this a bad idea from performance perspective? 4) Is there much of a hit in building a view full of nodes and then throwing them away and rebuilding on each showing of that view? In my apps (browser style) I would build all the views on startup and then reuse these by loading different data into them (e.g. the same instance was used for showing Person1 details as Person2, just loading different values into it). I thought this would be the best from performance, but there was a comment from Richard a while back that suggested it was perfectly ok/performant to throw away and build the page again on each showing? This would be much easier from an animation point of view as animating the transition 'back' or 'forward' between two pages of the same view is problematic when you are reusing the same view for both! 5) Is there much overhead to a view that it is in memory but not actually added to the scene. i.e. if I do end up building a new instance of the view for every page load (as per question 4), then it would be extra handy to just keep those views in memory so when the back button is hit I don't have to rebuild them. I assume the memory would build up pretty quickly if there were large tables, images, videos, etc? How does a web browser manage to cache all these pages in history and would the same approach be performant for JFX? On Tue, Jun 4, 2013 at 7:11 AM, Richard Bair richard.b...@oracle.comwrote: Hi, We had a brief meeting this afternoon and kicked off a performance tips n' tricks wiki page, which is presently a dumping ground of ideas that will get massaged into something useful. The content on this wiki will then be used by the docs team to produce some official documentation that goes on the oracle website. https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks I pre-loaded it with a chunk of John Smith's email listing a bunch of different performance related ideas, and also stuff we had on an internal document we'd brainstormed up a while ago, plus some ideas we brainstormed up a few minutes ago. Its rough, but if you are interested in taking a look and giving more ideas that occur, I'd appreciate it. Thanks Richard
Wrap text backwards compatibility issue
Since I had to run that old app for those performance screenshots, I found this: https://javafx-jira.kenai.com/browse/RT-30868 I'm just highlighting it here because it is another pretty major backwards compatibility issue between minor release versions. I think backwards compatibility of styling is going to be pretty darn hard for you guys to preserve (read impossible). Here's where I throw out my usual call to have Applets and Webstart deprecated, so we don't need auto-updating, and so this kind of backwards compatibility issue isn't so debilitating. Yea, yea, no go, whatever. Hopefully I'm the only one who built an app with single letter buttons, that also has the wrap-text flag set to true for the base button style, but if you were unlucky enough to do this and your app is using web deployment, you probably want to tweak your code around this.
Re: Animation swipe stutter
Thanks for the info. No VMWare going on with this one. Regrettably the app is not mine to share, it's a clients. Taking screen shots is a liberty. It is visible on multiple different windows machines though. On 02/06/2013, at 6:15 PM, Tom Eugelink t...@tbee.org wrote: I had a similar problem where my calendar popup would flicker when moving the mouse. This was also only reproducible on my system alone. Turns out the fact that I'm using VMWare to separate all the different projects I work on was the cause; somewhere half consciously I've clicked on a VMWare setting called accelerate 3D graphics and that didn't quite work as expected. One of the things you can do is let other people run your app and see when the stutter occurs; maybe there is a common denominator. I'm willing to test, and creating a UI only version should not be that hard. Tom On 2013-06-02 07:36, Daniel Zwolenski wrote: Here is another one I can't reproduce in a constrained example. http://www.screencast.com/t/ufJsZhiLhNJH This is a real world app that runs on a tablet (Windows). I tried to give this app a bit of an iPad style, with animations to transition between screens, etc (this was built a year or two ago). Many of the animations ' perform poorly' and are either slow or jumpy, etc, but it's hard to capture on video and hard to replicate in simple examples. In this video you can see a 'stutter' as the animation goes from left to right and back again. The stutter is right at the end just before the transition finishes. Sometimes it's pretty much perfect but 70% of the time it either overshoots and re-adjusts or just suddenly jumps to the end point before it's finished the smooth animation. At least that's the visual effect as far as I can tell. This (and many of the problems) could very well be an issue with the actual code on my end and not true JFX issues. I've tried to narrow down further but it is very time consuming to do this and it would help to know if there were any rough guesses at what might be causing this problem. Is it the fact that everything is so highly styled, or just the number of components, is it something like I shouldn't do any actual real work in an 'on finished' method, etc? If there are any possible leads then I can try and put together a small sample but at the moment I'm firing randomly. As far as the code goes, it's a fairly standard parallel transition containing two translate transitions. A very simple example of the sort of logic used can be seen here: https://code.google.com/p/zenjava-playtime/source/browse/trunk/javafx-performance/animate1/src/main/java/com/zenjava/jfx/performance/animate1/SwipeApp.java But this one animates consistently smooth.
Animation swipe stutter
Here is another one I can't reproduce in a constrained example. http://www.screencast.com/t/ufJsZhiLhNJH This is a real world app that runs on a tablet (Windows). I tried to give this app a bit of an iPad style, with animations to transition between screens, etc (this was built a year or two ago). Many of the animations ' perform poorly' and are either slow or jumpy, etc, but it's hard to capture on video and hard to replicate in simple examples. In this video you can see a 'stutter' as the animation goes from left to right and back again. The stutter is right at the end just before the transition finishes. Sometimes it's pretty much perfect but 70% of the time it either overshoots and re-adjusts or just suddenly jumps to the end point before it's finished the smooth animation. At least that's the visual effect as far as I can tell. This (and many of the problems) could very well be an issue with the actual code on my end and not true JFX issues. I've tried to narrow down further but it is very time consuming to do this and it would help to know if there were any rough guesses at what might be causing this problem. Is it the fact that everything is so highly styled, or just the number of components, is it something like I shouldn't do any actual real work in an 'on finished' method, etc? If there are any possible leads then I can try and put together a small sample but at the moment I'm firing randomly. As far as the code goes, it's a fairly standard parallel transition containing two translate transitions. A very simple example of the sort of logic used can be seen here: https://code.google.com/p/zenjava-playtime/source/browse/trunk/javafx-performance/animate1/src/main/java/com/zenjava/jfx/performance/animate1/SwipeApp.java But this one animates consistently smooth.
Re: JavaFX graphics performance and suitability for advanced animations
I tried your pixel snapping one and it is on par with the JScript version,
so it could be that either my system or my eye prefers that option. Good to
know we can switch between them at least to cater for different devices.
That project I captured in the last email had a fixed brand/model of tablet
that it was on so in that case it's good to be able to maximise performance
for that particular device.
I tried to taking screen captures of the different scenarios but it's too
fine detail and the animation just looks crap on all of them in the
captures.
I'm hearing you that this is a messy problem with no ideal, and some
options might be better in case A but worse in case B. Happy to say that
one is done and dusted and not worth going into deeper. I think the trick
will be to use coloured backgrounds - windows metro style.
On Sat, Jun 1, 2013 at 1:59 PM, Richard Bair richard.b...@oracle.comwrote:
This looks bad for me though in FX, I'm wondering what it looks like for
you.
I ran with the pulse logger and definitely there is no frame taking more
than a couple milliseconds. Things look awful because this example is
truncating (by casting to int) instead of rounding, and so on each frame
the rectangle is pixel snapped to a position that may be closer, or farther
away from the expected location and our brain sees it. To test this theory,
one thing I did was modify the sample so that instead of taking 3 seconds
to travel 400 pixels, I use 4 seconds and I removed the EASE_BOTH
interpolators. In this case the expected location on each frame is exactly
a pixel boundary, and of course it looks smooth. Note though that the
border still looks fuzzy (to me) but this is because the refresh rate on
the monitor or possibly the eye is exhibiting a motion blur.
public void start(Stage stage) throws Exception {
final StackPane rootPane = new StackPane();
VBox box = new VBox();
box.setMaxSize(200, 200);
box.setStyle(-fx-border-color: black; -fx-background-color:
white; -fx-effect: dropshadow(two-pass-box , darkgray, 10, 0.0 , 4, 5););
rootPane.getChildren().add(box);
createTranslation(box, 4, -200, -200, 200, 200).play();
Scene scene = new Scene(rootPane, 1200, 800);
stage.setScene(scene);
stage.show();
}
protected Animation createTranslation(Node node, int seconds, int
fromX, int fromY, int toX, int toY) {
IntegerProperty xProperty = new SimpleIntegerProperty(fromX);
IntegerProperty yProperty = new SimpleIntegerProperty(fromY);
node.translateXProperty().bind(xProperty);
node.translateYProperty().bind(yProperty);
Timeline t = new Timeline(
new KeyFrame(Duration.seconds(seconds),
new KeyValue(xProperty, toX),
new KeyValue(yProperty, toY)));
t.setCycleCount(Timeline.INDEFINITE);
t.setAutoReverse(true);
return t;
}
And here is another version which instead keeps the interpolator and the 3
second movement (so we're back to unexpected irregular positions) and we
pixel snap by rounding instead of by truncating.
public void start(Stage stage) throws Exception {
final StackPane rootPane = new StackPane();
VBox box = new VBox();
box.setMaxSize(200, 200);
box.setStyle(-fx-border-color: black; -fx-background-color:
white; -fx-effect: dropshadow(two-pass-box , darkgray, 10, 0.0 , 4, 5););
rootPane.getChildren().add(box);
createTranslation(box, 3, -200, -200, 200, 200).play();
Scene scene = new Scene(rootPane, 1200, 800);
stage.setScene(scene);
stage.show();
}
class RoundingValue extends SimpleDoubleProperty {
public RoundingValue(int initialValue) {
super(initialValue);
}
@Override public void set(double newValue) {
super.set(Math.round(newValue));
}
}
protected Animation createTranslation(Node node, int seconds, int
fromX, int fromY, int toX, int toY) {
RoundingValue xProperty = new RoundingValue(fromX);
RoundingValue yProperty = new RoundingValue(fromY);
node.translateXProperty().bind(xProperty);
node.translateYProperty().bind(yProperty);
Timeline t = new Timeline(
new KeyFrame(Duration.seconds(seconds),
new KeyValue(xProperty, toX,
Interpolator.EASE_BOTH),
new KeyValue(yProperty, toY,
Interpolator.EASE_BOTH)));
t.setCycleCount(Timeline.INDEFINITE);
t.setAutoReverse(true);
return t;
}
This looks pretty good perhaps this is what you are seeing in the browser?
Richard
Re: Backwards compatibility issue?
On 01/06/2013, at 1:23 AM, David Grieve david.gri...@oracle.com wrote: I won't take you up on that bet. I hate to lose. If the jar file has the .css file in it, you can disabled the loading of binary css by setting the property binary.css to false. I don't know if there is a way to set logging on the command line. This is not so much a question of what can I do to fix this, as highlighting the fact that an app built on b13 and then run on b23 is utterly broken. With auto updating jre's this means someone who has an app in the wild will suddenly have it break for all their customers. Massive backwards compatibility problem between minor build releases is not good for any of us. As an aside, from memory I don't think the original CSS is included in the jar by the packaging tools but I haven't checked. What's so horrid about css to bss compiling? A) It's broken B) What's the point? Not trying to be unduly critical but is it for some performance gain or something? Surely the load time is minimal. Given that I have a dozen XML config files, a handful of property files and a thousand FXML files that are being loaded by my app it seems like a whole lot of extra complexity and space for bugs to crawl in for no gain. Maybe I'm missing some benefit of this? On May 31, 2013, at 11:11 AM, Daniel Zwolenski zon...@gmail.com wrote: Can I set this using a system property or similar? This is a built jar and the fact that it was built with an older version of the jdk is part of the scenario. The packaging tools were used to assemble this jar and by default they do that horrid CSS to BSS compiling. If I was betting man, my money would be on that. As a side comment, I defaulted this to false in the maven plugin as people reported problems with the BSS files. Note that the jar is linked to in the post if you want to do your own testing on it. On 01/06/2013, at 12:57 AM, David Grieve david.gri...@oracle.com wrote: 512 is the localized message of the exception that is being thrown, which in itself is odd. You might get more info if you set the CSS logger to INFO. Assuming this is JavaFX 2.2.x, you can set the CSS logging level via: com.sun.javafx.Logging.getCSSLogger().setLevel(com.sun.javafx.logging.PlatformLogger.INFO) On May 31, 2013, at 12:27 AM, Daniel Zwolenski zon...@gmail.com wrote: No stack trace, just this: C:\tempc:\apps\java\jdk1.7.0_21-32bit\bin\java.exe -jar defender-jfx.jar Cannot add stylesheet. 512 If there's an easy way to turn on more debugging info let me know. On Fri, May 31, 2013 at 2:07 PM, Richard Bair richard.b...@oracle.comwrote: Possibly, what is the stack trace? On May 30, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote: While trying to narrow down the rendering/performance/whatever issues with the game, I just opened up the JAR that I'd previously built for it: https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar If I run this with java version 1.7.0_13 it works fine. If I run this with java version 1.7.0_21 none of the styles get loaded. Massive backwards compatibility fail between minor build versions?
Re: JavaFX graphics performance and suitability for advanced animations
Just on the topic of what should we expect performance/animation/graphic wise, are there technical limitations why jfx can't achieve this exact level of quality in animations: http://m.youtube.com/#/watch?v=-fNg-qZcIdYfeature=youtube_gdata_playerdesktop_uri=%2Fwatch%3Fv%3D-fNg-qZcIdY%26feature%3Dyoutube_gdata_player This is more or less the style of animation that I'd want to use jfx for. So if I wrote the code for this and then ran it side by side with the video how far off should the two be? I get that this is a pre-rendered video so it has some advantages but the video does not use rapid redraws or complicated particle effects, shadows, reflections, etc, like in a FPS game. How close should we expect jfx to get to this and which bits are not achievable and why? On 01/06/2013, at 1:32 AM, Scott Palmer swpal...@gmail.com wrote: Richard, I suspect you made a typo. I think you mean *40*ms is a really odd number... (it was 25 FPS, not 25ms) I quickly hacked it to use AnimationTimer and the animation is very smooth now. Though I didn't make the required changes to adjust the speeds based on the refresh rate. The quick conversion to AnimationTimer is trivial.. but going through and adjusting all the translations and increments to be relative to the time between consecutive frames is something I don't have time for. Cheers, Scott Scott On Fri, May 31, 2013 at 11:21 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: ** Btw, there is a JIRA issue filed against BrickBreaker specifically: https://javafx-jira.kenai.com/browse/RT-29801 Richard Bair wrote: Have you tried to determine what the FPS is? My guess is that FPS is not anywhere near the limit and it is the occasional stutter that is the problem, but I'm not certain. Knowing that helps to point in which direction to go. The fact that it runs pretty well on a PI is indication that it isn't the framerate. Richard On May 31, 2013, at 4:26 AM, Scott Palmer swpal...@gmail.com swpal...@gmail.com wrote: Speaking of poor animation in Ensemble... Is anyone able to run Brick Breaker without choppy animation or poor framerate performance on the ball? Now, I suspect the issue there is in the balls animation implementation in the application rather than the JavaFX framework, as the bat moves smoothly when I move the mouse, but the overall perception of JavaFX performance for this demo app is not good. I would go so far as to say that Brick Breaker has had the opposite effect it was intended too - simply because the animation of the ball is not smooth. That's something that would run smoothly on a Commodore 64,yet the last time I tried it (5 minutes ago) with JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a decent NVIDIA card, it didn't run as smoothly as I would expect. Just a single ball with a shadow bouncing around the screen seemed to have a low framerate and the occasional skipped frame. It just didn't look that great. The fact that Brick Breaker ships as a sample app from Oracle and it's animation looks bad is harming JavaFX's reputation in my opinion. I think it could run much better on the existing JavaFX runtime. The simple animations in the Ensemble app run much smoother for example. Scott On Thu, May 30, 2013 at 11:11 AM, Richard Bair richard.b...@oracle.com richard.b...@oracle.com wrote: Then you mention Halo 5. I have to say the subtext here troubles me greatly. If I read you correctly then you are saying that JavaFX is not really suitable for games (at least anything beyond the demands of something like Solitaire). As someone else pointed out, what is point of developing 3D support in JavaFX if it is not really suitable for games? To say it is not suitable for games implies that it is not really suitable for *any* application that requires performant animations and visualisations. What use then is the 3D API? That's not fair at all. There are a *lot* of enterprise use cases for 3D, and we get these requests all the time. Whether we're taking about 3D visualizations for medical or engineering applications or consumer applications (product display, etc), there is a requirement for 3D that are broader than real time first person shooters. Game engines often have very specialized scene graphs (sometimes several of them) as well as very specialized tricks for getting the most out of their graphics cards. When we expose API that allows people to hammer the card directly, then it would be possible for somebody to build some of the UI in FX and let their game engine be hand written (in Unity or JOGL or whatever). However, I am not sure that having me preparing reproducible test cases will actually help. In my experience, the Ensemble app already serves this purpose. The choppiness I describe is *always* prevalent when I run the animations and transitions in
Re: JavaFX graphics performance and suitability for advanced animations
A little bit more esoteric, but some not very nice looking rendering when animating a very lightly styled Node: https://javafx-jira.kenai.com/browse/RT-30830 On Fri, May 31, 2013 at 12:07 PM, Daniel Zwolenski zon...@gmail.com wrote: Jittery text when scaling in an animation: https://javafx-jira.kenai.com/browse/RT-30827 On Fri, May 31, 2013 at 12:01 PM, Richard Bair richard.b...@oracle.comwrote: Wow. Thanks! On May 30, 2013, at 6:48 PM, Daniel Zwolenski zon...@gmail.com wrote: I have replicated the z-order problem with the Tower Defender game and the Canvas: https://javafx-jira.kenai.com/browse/RT-30826 On Fri, May 31, 2013 at 1:26 AM, Richard Bair richard.b...@oracle.comwrote: Note this is only for Mac. On May 30, 2013, at 7:54 AM, Richard Bair richard.b...@oracle.com wrote: Anybody interested in jitter ought to look at https://javafx-jira.kenai.com/browse/RT-26702 Richard
Re: Backwards compatibility issue?
No stack trace, just this: C:\tempc:\apps\java\jdk1.7.0_21-32bit\bin\java.exe -jar defender-jfx.jar Cannot add stylesheet. 512 If there's an easy way to turn on more debugging info let me know. On Fri, May 31, 2013 at 2:07 PM, Richard Bair richard.b...@oracle.comwrote: Possibly, what is the stack trace? On May 30, 2013, at 8:24 PM, Daniel Zwolenski zon...@gmail.com wrote: While trying to narrow down the rendering/performance/whatever issues with the game, I just opened up the JAR that I'd previously built for it: https://bytebucket.org/rbair/fx-games/wiki/release/defender-jfx.jar If I run this with java version 1.7.0_13 it works fine. If I run this with java version 1.7.0_21 none of the styles get loaded. Massive backwards compatibility fail between minor build versions?
Preloaders
The jfx packaging tools allow pre-loaders to be set. I don't use them but people using the maven plugin want them. It looks like you can set a preloader for both jars and for bundles (web, native). When building the bundles however they include the jar in them. So we end up with both the bundle, and the jar within the bundle, getting the preloader set. Does anyone know what will or should happen in this case? Does one preloader take precedence and the other is ignored, or are both used at different times and I should allow the user to set a different jar preloader to the bundle one, or is this setup invalid and I should actually not pass the preloader setting to one or the other in this case? Not using Preloaders myself and with the packaging tool code being a complete mess, it would be good to know the expectations here so I can properly support the users wanting this. Cheers Dan
