From martin.sladecek at oracle.com Tue Oct 1 00:15:46 2013 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Tue, 01 Oct 2013 09:15:46 +0200 Subject: FXMLLoader templates In-Reply-To: <523C3DF6.6090109@oracle.com> References: <523C3DF6.6090109@oracle.com> Message-ID: <524A76A2.80503@oracle.com> After discussion with Richard, we decided to remove the template flag from FXMLLoader for 8.0. This API is not mature yet, due to the reasons described below and should be completely re-designed for some next release. This means that loading the same fxml multiple times will still require multiple FXMLLoader instances. Any comments? Thanks, -Martin On 09/20/2013 02:22 PM, Martin Sladecek wrote: > Hi, > I would like to discuss a 8.0 feature of FXMLLoader - the template flag. > I was introduced with this issue: > https://javafx-jira.kenai.com/browse/RT-23413, but unfortunately, it > never worked: https://javafx-jira.kenai.com/browse/RT-28121. I was > trying to fix the issue, but the whole concept of a flag for loading > templates seems hardly usable and incorrect to me and should be > replaced with something more appropriate. > > The reason is the handling of root, controller and the namespace > before and after the load. Both are treated in 2 different ways. > Before the load, they are used to adjust the following load - by > setting the root (for tag), setting the namespace and a > controller. > However, after the load, these properties (though not FX-properties) > can be used to query what was just loaded. The root of the FXML, the > namespace with all "id"s and the controller. > > Now that's not very useful when you want to use template loading. My > solution for RT-28121 (when keeping the old API) is to save the > namespace after setTemplate(true) was called, using this namespace on > each load(), clearing it at the begging of load() + disallow > setController() for this mode. > > But that doesn't cover all of the relevant use-cases I can think of. > Actually, without changing the API, I doubt we can support all such > use-cases. > > Here's the set I'm working with: > 1) setup some "template namespace", n times do { adjust namespace > (based on template namespace) , load) } > > 2) n times do {load, query id from namespace} > > 3) n times do {setController(new Controller) load } > > 4) n times do {load, query newly created controller} > > 5,6) same as 3,4 but with root > > So while in 1,3 we would need to clear namespace/controller after each > load, in 2,4 we need to clear it before each load. In case 3), > forgetting to set a new controller would otherwise result in 2 > instances with the same controller. > > One solution might be to split this to 2 independent calls. > setController/getLoadedController, ObservableMap getNamespace() and > Map getLoadedNamespace (unmodifiable). > > Another might be a completely new class FXMLTemplate. > It might yield new pre-set FXMLLoaders that can be adjusted and > loaded, but it means generating a temporary object for each call. > Also, FXMLLoader would need to be updated, so that it's only possible > to call load() once. > > Other ideas / use-cases? > > Thanks, > -Martin From tom.schindl at bestsolution.at Tue Oct 1 00:18:41 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 01 Oct 2013 09:18:41 +0200 Subject: FXMLLoader templates In-Reply-To: <524A76A2.80503@oracle.com> References: <523C3DF6.6090109@oracle.com> <524A76A2.80503@oracle.com> Message-ID: <524A7751.1000207@bestsolution.at> In case someone needs extra performance I can point you to my FXML => Java-Converter which will give you the best performance ;-) Tom On 01.10.13 09:15, Martin Sladecek wrote: > After discussion with Richard, we decided to remove the template flag > from FXMLLoader for 8.0. > This API is not mature yet, due to the reasons described below and > should be completely re-designed for some next release. > > This means that loading the same fxml multiple times will still require > multiple FXMLLoader instances. > > Any comments? > > Thanks, > -Martin > > On 09/20/2013 02:22 PM, Martin Sladecek wrote: >> Hi, >> I would like to discuss a 8.0 feature of FXMLLoader - the template flag. >> I was introduced with this issue: >> https://javafx-jira.kenai.com/browse/RT-23413, but unfortunately, it >> never worked: https://javafx-jira.kenai.com/browse/RT-28121. I was >> trying to fix the issue, but the whole concept of a flag for loading >> templates seems hardly usable and incorrect to me and should be >> replaced with something more appropriate. >> >> The reason is the handling of root, controller and the namespace >> before and after the load. Both are treated in 2 different ways. >> Before the load, they are used to adjust the following load - by >> setting the root (for tag), setting the namespace and a >> controller. >> However, after the load, these properties (though not FX-properties) >> can be used to query what was just loaded. The root of the FXML, the >> namespace with all "id"s and the controller. >> >> Now that's not very useful when you want to use template loading. My >> solution for RT-28121 (when keeping the old API) is to save the >> namespace after setTemplate(true) was called, using this namespace on >> each load(), clearing it at the begging of load() + disallow >> setController() for this mode. >> >> But that doesn't cover all of the relevant use-cases I can think of. >> Actually, without changing the API, I doubt we can support all such >> use-cases. >> >> Here's the set I'm working with: >> 1) setup some "template namespace", n times do { adjust namespace >> (based on template namespace) , load) } >> >> 2) n times do {load, query id from namespace} >> >> 3) n times do {setController(new Controller) load } >> >> 4) n times do {load, query newly created controller} >> >> 5,6) same as 3,4 but with root >> >> So while in 1,3 we would need to clear namespace/controller after each >> load, in 2,4 we need to clear it before each load. In case 3), >> forgetting to set a new controller would otherwise result in 2 >> instances with the same controller. >> >> One solution might be to split this to 2 independent calls. >> setController/getLoadedController, ObservableMap getNamespace() and >> Map getLoadedNamespace (unmodifiable). >> >> Another might be a completely new class FXMLTemplate. >> It might yield new pre-set FXMLLoaders that can be adjusted and >> loaded, but it means generating a temporary object for each call. >> Also, FXMLLoader would need to be updated, so that it's only possible >> to call load() once. >> >> Other ideas / use-cases? >> >> Thanks, >> -Martin > From tobi at ultramixer.com Tue Oct 1 00:23:48 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 1 Oct 2013 09:23:48 +0200 Subject: Moving on to a "round house kick" (forked from Re: JavaOne roundup?) In-Reply-To: References: <21E125CD-B429-4A64-A513-628446FC3262@gmail.com> <17135445-8646-4B77-86BC-575812205D2F@ultramixer.com> Message-ID: Richard, why do you choose Rasp.PI as demo platform instead of iPad or Android tablet? I really believe in you JFX guys and I really believe that you all love to see JFX on tablets. So I don?t understand why you can?t open your mouth, go to your management and legal department and tell him, that?s important to talk to the community. What you do currently is to sedate the community with tech demos on Rasp.PI like you sedate a dog :) Sorry, for that, but that?s how we feel. Keep up the good work and hopefully the time comes for you guys. It?s late because QT 5.2 fully supports iOS and Android now. But it?s not to late. Am 30.09.2013 um 19:18 schrieb Richard Bair : >> 2. Wow, there is a JavaFX enabled Dukepad. Beeing a soldering nerd myself, hacking firmware and much cool stuff >> in my spare time it really kicked me in the first place. Then I grounded when I have seen that it was a childish puzzle >> with lego blocks. > > What? > >> The longer I think about that, the longer I am getting angry to see a 100 men powered development >> team to build a demo on a demo board for a hand full nerds. > > I don't know where you got that impression. Jasper did the design, and there were a couple of people who spent a couple weeks working on software. And that wasn't writing the DukePad software, predominantly, but it was fixing performance issues in Prism that affect all platforms. > > The value is in embedded development. Before JavaOne we didn't have all the agreements in place to work with Freescale. The Raspberry PI has a nice following, is great for educational purposes and home-brew, so it was a great choice to build a demo on top of (as opposed to, say, a BeagleBoard or BeagleBone which is either more expensive or doesn't have the same size following). Having an actual project to work on also teases out bugs and performance issues, and most of the work leading up to JavaOne was in finding and fixing these issues. These same issues will affect any embedded project, including the RoboVM / iOS / Android work. > >> Well that would be ok, if Oracle said that this is a demo >> on a prototyping board and the important platforms will follow soon. No word about iOS, Android, Windows8. > > Do you mean Windows Phone 8? Because Windows 8 is a given. > >> Do you really believe that there are many people to build a Tablet like this? I am really sure non of the major >> hardware manufacturer will build a tablet on top of this platform soon since Android is also free to us and is >> much more attractive to the end-user. The only thing that I can image is that Oracle comes up with their own >> iPad-Killer in the near future (don't wait too long) otherwise this decision make no sense to me. > > No, none of this. DukePad is not a product. We made that pretty clear, it's an open source hardware/software design for the Raspberry PI community. We will make no money off the designs and Oracle isn't selling anything here. For us it was a vehicle on which we could demonstrate our ability to run well on embedded devices, and find and fix bugs along the way. Oracle isn't going to produce a mobile device. DukePad was not any kind of product announcement. Those kinds of things happen in strategy keynotes, not in technical keynotes. > > Richard > From haenel at ultramixer.com Tue Oct 1 00:24:34 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Tue, 1 Oct 2013 09:24:34 +0200 Subject: Moving on to a "round house kick" (forked from Re: JavaOne roundup?) In-Reply-To: References: <21E125CD-B429-4A64-A513-628446FC3262@gmail.com> <17135445-8646-4B77-86BC-575812205D2F@ultramixer.com> Message-ID: <539B08F0-C6EC-438E-8583-E4F1CA6FE0CC@ultramixer.com> Hi Richard, thank you for your fast answer. I know you are a bussy man. >> The longer I think about that, the longer I am getting angry to see a 100 men powered development >> team to build a demo on a demo board for a hand full nerds. > > I don't know where you got that impression. Jasper did the design, and there were a couple of people who spent a couple weeks working on software. And that wasn't writing the DukePad software, predominantly, but it was fixing performance issues in Prism that affect all platforms. > > The value is in embedded development. Before JavaOne we didn't have all the agreements in place to work with Freescale. The Raspberry PI has a nice following, is great for educational purposes and home-brew, so it was a great choice to build a demo on top of (as opposed to, say, a BeagleBoard or BeagleBone which is either more expensive or doesn't have the same size following). Having an actual project to work on also teases out bugs and performance issues, and most of the work leading up to JavaOne was in finding and fixing these issues. These same issues will affect any embedded project, including the RoboVM / iOS / Android work. Why do you guys always talk about embedded development? The old days of embbedded stuff have been without an OS. What we are talking about are not really embedded platforms, these are Desktop systems like Linux/Android (linux base)/iOS (berkley based) with energy optimized kernels which are primary used on an ARM CPUs. From my point of view the summary of an ARM cpu, operating systems and toolkits build the platform. Unfortunately, I missed the Freescale announcment. How could I miss it? (I used to work with their Motorola dev boards back in time) http://gigaom.com/2013/09/23/oracle-and-freescale-push-java-for-the-internet-of-things/ I read this announcement and now I hopefully understand the idea where JavaFX should end up. Oracle wants to establish a network of little running devices based on Linux/JavaFX build inside any electric device. Now I understand everything much better. off topic: Nice idea, but keep in mind we have 2013 and it is the phase of consolidation in the software and OS market. The costumer don't want a closed system. Just one question. You want to buy a fridge in late 2014 with a tablet interface on the front door. You are in a very big Target super market. There you will find one with "JavaFX powered" logo and another one with "Google Android". Which one do you buy? What I want to say is, that as long as there are others using well known operating interfaces it will be very very hard to enter this market. Sure there is always a chance to enter a new market but wouldn't it be smart to enter a currently used operating system and let the customer get used to a particular technology? >> Well that would be ok, if Oracle said that this is a demo >> on a prototyping board and the important platforms will follow soon. No word about iOS, Android, Windows8. > > Do you mean Windows Phone 8? Because Windows 8 is a given. Yes, I meant Windows Phone 8. Sure, this is currently not a major player in my opinion it has a much broader audiance and end-user acceptance than a linux based system. >> Do you really believe that there are many people to build a Tablet like this? I am really sure non of the major >> hardware manufacturer will build a tablet on top of this platform soon since Android is also free to us and is >> much more attractive to the end-user. The only thing that I can image is that Oracle comes up with their own >> iPad-Killer in the near future (don't wait too long) otherwise this decision make no sense to me. > > No, none of this. DukePad is not a product. We made that pretty clear, it's an open source hardware/software design for the Raspberry PI community. We will make no money off the designs and Oracle isn't selling anything here. For us it was a vehicle on which we could demonstrate our ability to run well on embedded devices, and find and fix bugs along the way. Oracle isn't going to produce a mobile device. DukePad was not any kind of product announcement. Those kinds of things happen in strategy keynotes, not in technical keynotes. Ok, the rasp-pi stuff is done for demonstration purposes and as a development platform. I see. The direction is clearly "enriched internet things". That means for me it is the end of my hopes for JavaFX as a game changer on every platform. Thanks for enlighten me, this makes our future decisions a bit easier. kind regards Matthias From hang.vo at oracle.com Tue Oct 1 01:03:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 08:03:49 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32415 NullPointerException when using fx:include Message-ID: <20131001080423.8F93E62C2A@hg.openjdk.java.net> Changeset: d049142f7145 Author: Martin Sladecek Date: 2013-10-01 09:50 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d049142f7145 RT-32415 NullPointerException when using fx:include Reviewed-by: ekrejcir ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java From tobi at ultramixer.com Tue Oct 1 02:29:12 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 1 Oct 2013 11:29:12 +0200 Subject: JavaFX on Android: JavaSELauncher? Message-ID: <0A87CF81-6950-47FF-A9FB-49B2691AAF4A@ultramixer.com> @Oracle: which JVM uses the new JavaSELauncher class in the com.oracle.dalvik package? How to use this class to start JFX on Android? Best, Tobi From hang.vo at oracle.com Tue Oct 1 02:35:21 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 09:35:21 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30637: used proper near/far clipping planes for default perspective camera. Message-ID: <20131001093754.81E0062C2F@hg.openjdk.java.net> Changeset: 105b4c1ce770 Author: Pavel Safrata Date: 2013-10-01 10:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/105b4c1ce770 RT-30637: used proper near/far clipping planes for default perspective camera. ! apps/toys/FX8-3DFeatures/src/fx83dfeatures/NearAndFarClipTest.java ! modules/graphics/src/main/java/com/sun/javafx/geom/PickRay.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/PerspectiveCamera.java ! modules/graphics/src/test/java/javafx/scene/Mouse3DTest.java From hang.vo at oracle.com Tue Oct 1 05:18:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 12:18:29 +0000 Subject: hg: openjfx/8/controls/rt: RT-30206 : [Button] default and cancel accelerator removing is implemented incorrectly in behavior set to false, reviewed by Leif Message-ID: <20131001121937.6221462C3B@hg.openjdk.java.net> Changeset: 5475dfc3d98a Author: mickf Date: 2013-10-01 13:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5475dfc3d98a RT-30206 : [Button] default and cancel accelerator removing is implemented incorrectly in behavior set to false, reviewed by Leif ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ButtonSkin.java From anton.nashatyrev at oracle.com Tue Oct 1 05:53:04 2013 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Tue, 01 Oct 2013 16:53:04 +0400 Subject: Event for when a node gets shown on screen In-Reply-To: References: Message-ID: <524AC5B0.3050306@oracle.com> Hi Pedro, you may try the following code: Bindings.select(node.sceneProperty(), "window", "showing").addListener(new ChangeListener() ....); BTW, this way you could add the listener even when the node is not yet attached to any scene or window. Regards, Anton. On 29.09.2013 18:57, Pedro Duque Vieira wrote: > Hi, > > More than once or twice I had the need to do something when a node first > gets shown on screen. Like for instance do some animation or setup some > parameters which are only valid when the node is showing. > > For this reason I think there is a need for an event that is triggered when > the node becomes live, i.e. is shown on screen. > > Thanks, best regards, > From hang.vo at oracle.com Tue Oct 1 06:48:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 13:48:33 +0000 Subject: hg: openjfx/8/controls/rt: RT-29334 : Split pane doesn't change its rendering after items has changed order, reviewed by David Message-ID: <20131001134915.EE9E762C40@hg.openjdk.java.net> Changeset: 5a67a3c94fee Author: mickf Date: 2013-10-01 14:38 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5a67a3c94fee RT-29334 : Split pane doesn't change its rendering after items has changed order, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java From hang.vo at oracle.com Tue Oct 1 06:48:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 13:48:33 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33092 GridPane column with Hgrow should be able to grow above children max width Message-ID: <20131001134930.7BDC062C41@hg.openjdk.java.net> Changeset: cd993475e253 Author: Martin Sladecek Date: 2013-10-01 15:46 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cd993475e253 RT-33092 GridPane column with Hgrow should be able to grow above children max width Reviewed-by: ekrejcir ! modules/graphics/src/main/java/javafx/scene/layout/GridPane.java ! modules/graphics/src/test/java/javafx/scene/layout/GridPaneTest.java From hang.vo at oracle.com Tue Oct 1 07:03:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 14:03:53 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131001140437.C178462C43@hg.openjdk.java.net> Changeset: fb7da215b220 Author: Martin Sladecek Date: 2013-10-01 15:48 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fb7da215b220 RT-33092 (cont.) [variable rename] ! modules/graphics/src/main/java/javafx/scene/layout/GridPane.java Changeset: 604ebe0585ea Author: Eva Krejcirova Date: 2013-10-01 15:02 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/604ebe0585ea [DOC-ONLY] RT-32979: Example of boundsInParent & boundsInLocal in javafx.scene.Node documentation is confusing - modules/graphics/src/main/docs/javafx/scene/doc-files/bounds-complex.png + modules/graphics/src/main/docs/javafx/scene/doc-files/boundsLocal.png + modules/graphics/src/main/docs/javafx/scene/doc-files/boundsParent.png ! modules/graphics/src/main/java/javafx/scene/Node.java From hang.vo at oracle.com Tue Oct 1 07:03:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 14:03:44 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20131001140446.92EB862C44@hg.openjdk.java.net> Changeset: 8319071566e7 Author: mickf Date: 2013-10-01 14:57 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8319071566e7 RT-32380 - ScrollPane: Content does not scroll using keyboard, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java Changeset: a9d5fe2c0bb9 Author: hudson Date: 2013-09-26 08:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a9d5fe2c0bb9 Added tag 8.0-b109 for changeset ad10ea1df81d ! .hgtags Changeset: 6039c1e69ed7 Author: David Grieve Date: 2013-10-01 10:00 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6039c1e69ed7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From martin.sladecek at oracle.com Tue Oct 1 07:06:07 2013 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Tue, 01 Oct 2013 16:06:07 +0200 Subject: Event for when a node gets shown on screen In-Reply-To: <524AC5B0.3050306@oracle.com> References: <524AC5B0.3050306@oracle.com> Message-ID: <524AD6CF.3060004@oracle.com> That would work, except you need to hard-ref the binding otherwise it might get GCed. -Martin On 10/01/2013 02:53 PM, anton nashatyrev wrote: > Hi Pedro, > > you may try the following code: > > Bindings.select(node.sceneProperty(), "window", > "showing").addListener(new ChangeListener() ....); > > BTW, this way you could add the listener even when the node is not yet > attached to any scene or window. > > Regards, > Anton. > > On 29.09.2013 18:57, Pedro Duque Vieira wrote: >> Hi, >> >> More than once or twice I had the need to do something when a node first >> gets shown on screen. Like for instance do some animation or setup some >> parameters which are only valid when the node is showing. >> >> For this reason I think there is a need for an event that is >> triggered when >> the node becomes live, i.e. is shown on screen. >> >> Thanks, best regards, >> > From goodnewsforyou at yahoo.com Tue Oct 1 07:28:27 2013 From: goodnewsforyou at yahoo.com (Anil) Date: Tue, 1 Oct 2013 07:28:27 -0700 (PDT) Subject: In JavaFX2.2, how to set the font size for text entered in input fields and table headers? In-Reply-To: <1380572961.12105.YahooMailNeo@web160805.mail.bf1.yahoo.com> References: <1380572961.12105.YahooMailNeo@web160805.mail.bf1.yahoo.com> Message-ID: <1380637707.28750.YahooMailNeo@web160805.mail.bf1.yahoo.com> any help appreciated... ________________________________ From: Anil To: "openjfx-dev at openjdk.java.net" Sent: Monday, September 30, 2013 3:29 PM Subject: In JavaFX2.2, how to set the font size for text entered in input fields and table headers? In my JavaFX2.2 fxml program (Java 7.25, Windows 7), I am finding that fonts do not scale properly. As a result, table headers and input data fields are disproportionately large. Is there any way to set the font size for text entered in the input fields? see screenshot here using the standard JavaFx sample http://stackoverflow.com/questions/18495823/javafx-text-fonts-are-tiny-on-windows-7 From steve.x.northover at oracle.com Tue Oct 1 08:34:03 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 01 Oct 2013 11:34:03 -0400 Subject: CFV: New OpenJDK Committer: Lisa Selle In-Reply-To: <5243019D.90301@oracle.com> References: <5243019D.90301@oracle.com> Message-ID: <524AEB6B.2070909@oracle.com> Vote: yes On 25/09/2013 11:30 AM, Artem Ananiev wrote: > > I hereby nominate Lisa Selle to OpenJFX Committer. > > Lisa is a member of JavaFX Embedded team. Her changes are all over the > JavaFX code, from cursors and input events to makefiles and virtual > keyboard. The list of Lisa's commits in the workspace: > > hg log -u "Lisa Selle" > hg log -u "Lisa.Selle" > > Incomplete list is also available by the following link: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=selle > > Votes are due to Oct 09, 2013. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From kevin.rushforth at oracle.com Tue Oct 1 08:59:37 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 01 Oct 2013 08:59:37 -0700 Subject: CFV: New OpenJFX Committer: Joseph Andresen In-Reply-To: <5242FE9D.3050205@oracle.com> References: <5242FE9D.3050205@oracle.com> Message-ID: <524AF169.5080509@oracle.com> Vote: yes Artem Ananiev wrote: > > I hereby nominate Joe Andresen to OpenJFX Committer. > > Joe is a member of JavaFX Graphics team at Oracle. His first changeset > in Prism is dated by 2009, and total number of commits is close to one > hundred. Full list of Joe's changesets in the open workspace is > available from command line: > > hg log -u "Joseph Andresen" > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From kevin.rushforth at oracle.com Tue Oct 1 08:59:44 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 01 Oct 2013 08:59:44 -0700 Subject: CFV: New OpenJDK Committer: Lisa Selle In-Reply-To: <5243019D.90301@oracle.com> References: <5243019D.90301@oracle.com> Message-ID: <524AF170.7020505@oracle.com> Vote: yes Artem Ananiev wrote: > > I hereby nominate Lisa Selle to OpenJFX Committer. > > Lisa is a member of JavaFX Embedded team. Her changes are all over the > JavaFX code, from cursors and input events to makefiles and virtual > keyboard. The list of Lisa's commits in the workspace: > > hg log -u "Lisa Selle" > hg log -u "Lisa.Selle" > > Incomplete list is also available by the following link: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=selle > > Votes are due to Oct 09, 2013. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From kevin.rushforth at oracle.com Tue Oct 1 08:59:51 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 01 Oct 2013 08:59:51 -0700 Subject: CFV: New OpenJFX Committer: Yao Wang In-Reply-To: <524308DA.30004@oracle.com> References: <524308DA.30004@oracle.com> Message-ID: <524AF177.2020707@oracle.com> Vote: yes Artem Ananiev wrote: > > I hereby nominate Yao Wang to OpenJFX Committer. > > Yao is a member of JavaFX Graphics team at Oracle. Most of recent > Yao's changes are in 3D support code, but not only there: > > hg log -u "Yao Wang" > > Incomplete list of Yao's commits and reviews is also available by the > following link: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=wang > > Votes are due by Oct 09, 2013. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From hang.vo at oracle.com Tue Oct 1 09:03:38 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 16:03:38 +0000 Subject: hg: openjfx/8/graphics/rt: RT-27540: Swing application with JFXPanel does not terminate properly Message-ID: <20131001160404.7B7A762C53@hg.openjdk.java.net> Changeset: ac845cbafb49 Author: art Date: 2013-10-01 19:52 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ac845cbafb49 RT-27540: Swing application with JFXPanel does not terminate properly RT-21404: JFXPanel: If Platform implicitExit flag is false when the last window exits, setting it back to true will have no effect Reviewed-by: Kevin Rushforth ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java ! modules/swing/src/main/java/javafx/embed/swing/JFXPanel.java ! tests/system/src/test/java/com/sun/javafx/application/SwingExitCommon.java ! tests/system/src/test/java/com/sun/javafx/application/SwingExitExplicit2Test.java + tests/system/src/test/java/com/sun/javafx/application/SwingNoExit.java From richard.bair at oracle.com Tue Oct 1 09:21:24 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 1 Oct 2013 09:21:24 -0700 Subject: CFV: New OpenJDK Committer: Lisa Selle In-Reply-To: <5243019D.90301@oracle.com> References: <5243019D.90301@oracle.com> Message-ID: <9447C323-FB38-43EF-B4F0-9C6212CC4B4F@oracle.com> Vote: Yes On Sep 25, 2013, at 8:30 AM, Artem Ananiev wrote: > > I hereby nominate Lisa Selle to OpenJFX Committer. > > Lisa is a member of JavaFX Embedded team. Her changes are all over the JavaFX code, from cursors and input events to makefiles and virtual keyboard. The list of Lisa's commits in the workspace: > > hg log -u "Lisa Selle" > hg log -u "Lisa.Selle" > > Incomplete list is also available by the following link: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=selle > > Votes are due to Oct 09, 2013. > > Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From richard.bair at oracle.com Tue Oct 1 09:21:44 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 1 Oct 2013 09:21:44 -0700 Subject: CFV: New OpenJFX Committer: Yao Wang In-Reply-To: <524308DA.30004@oracle.com> References: <524308DA.30004@oracle.com> Message-ID: Vote: yes On Sep 25, 2013, at 9:01 AM, Artem Ananiev wrote: > > I hereby nominate Yao Wang to OpenJFX Committer. > > Yao is a member of JavaFX Graphics team at Oracle. Most of recent Yao's changes are in 3D support code, but not only there: > > hg log -u "Yao Wang" > > Incomplete list of Yao's commits and reviews is also available by the following link: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=wang > > Votes are due by Oct 09, 2013. > > Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From richard.bair at oracle.com Tue Oct 1 09:21:59 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 1 Oct 2013 09:21:59 -0700 Subject: CFV: New OpenJFX Committer: Joseph Andresen In-Reply-To: <5242FE9D.3050205@oracle.com> References: <5242FE9D.3050205@oracle.com> Message-ID: Vote: yes On Sep 25, 2013, at 8:17 AM, Artem Ananiev wrote: > > I hereby nominate Joe Andresen to OpenJFX Committer. > > Joe is a member of JavaFX Graphics team at Oracle. His first changeset in Prism is dated by 2009, and total number of commits is close to one hundred. Full list of Joe's changesets in the open workspace is available from command line: > > hg log -u "Joseph Andresen" > > Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From steve.x.northover at oracle.com Tue Oct 1 09:27:27 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 01 Oct 2013 12:27:27 -0400 Subject: com.sun.prism.tkal.Window Message-ID: <524AF7EF.9020100@oracle.com> Hi FX developers, The class com.sun.prism.tkal.Window seems to have no references. Speak now if you know anybody who uses it, otherwise it will get deleted. Steve From artem.ananiev at oracle.com Tue Oct 1 10:42:53 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 01 Oct 2013 21:42:53 +0400 Subject: com.sun.prism.tkal.Window In-Reply-To: <524AF7EF.9020100@oracle.com> References: <524AF7EF.9020100@oracle.com> Message-ID: <524B099D.9050605@oracle.com> On 10/1/2013 8:27 PM, steve.x.northover at oracle.com wrote: > Hi FX developers, > > The class com.sun.prism.tkal.Window seems to have no references. Speak > now if you know anybody who uses it, otherwise it will get deleted. This package was introduced as abstraction between Newt and Glass, so it's obsolete now. +1 to remove. Thanks, Artem > Steve From steve.x.northover at oracle.com Tue Oct 1 10:44:08 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 01 Oct 2013 13:44:08 -0400 Subject: com.sun.prism.tkal.Window In-Reply-To: <524B099D.9050605@oracle.com> References: <524AF7EF.9020100@oracle.com> <524B099D.9050605@oracle.com> Message-ID: <524B09E8.7090505@oracle.com> .. going once ... Steve On 01/10/2013 1:42 PM, Artem Ananiev wrote: > > On 10/1/2013 8:27 PM, steve.x.northover at oracle.com wrote: >> Hi FX developers, >> >> The class com.sun.prism.tkal.Window seems to have no references. Speak >> now if you know anybody who uses it, otherwise it will get deleted. > > This package was introduced as abstraction between Newt and Glass, so > it's obsolete now. +1 to remove. > > Thanks, > > Artem > >> Steve From hang.vo at oracle.com Tue Oct 1 10:18:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 17:18:44 +0000 Subject: hg: openjfx/8/graphics/rt: 30 new changesets Message-ID: <20131001172655.769E662C5C@hg.openjdk.java.net> Changeset: a9d5fe2c0bb9 Author: hudson Date: 2013-09-26 08:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a9d5fe2c0bb9 Added tag 8.0-b109 for changeset ad10ea1df81d ! .hgtags Changeset: 50a4af3f8b03 Author: jgiles Date: 2013-09-18 12:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50a4af3f8b03 RT-31100: LCD text not rendering on cached node unless background is set Contributed-by: jasper Reviewed-by: felipe, jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 5031afa0b69d Author: anashaty Date: 2013-09-19 15:56 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5031afa0b69d RT-31393: Wrong widget is selected if another had focus before it Reviewed-by: jgiles,dmarkov ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java Changeset: 8db542421315 Author: psomashe Date: 2013-09-19 09:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8db542421315 RT-29433 ChoiceBox keeps selected item when underlying collection is replaced. unit test : checkSelectedItemAfterReplacingDataWithEmptyList() ! modules/controls/src/main/java/javafx/scene/control/ChoiceBox.java ! modules/controls/src/test/java/javafx/scene/control/ChoiceBoxTest.java Changeset: 2441235395a4 Author: leifs Date: 2013-09-20 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2441235395a4 RT-27199: HTML Editor, in ja and ko locales, can't open "Font Size" menu. Reviewed-by: mickf ! modules/web/src/main/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java Changeset: 047354976850 Author: leifs Date: 2013-09-23 15:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/047354976850 RT-33074: [DatePicker] Fix issues in Modena CSS ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: ac217689464d Author: David Grieve Date: 2013-09-24 11:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ac217689464d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: dbcbfaf3abb4 Author: jgiles Date: 2013-09-25 10:01 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dbcbfaf3abb4 RT-32908: Scrolling mousewheel quickly with virtualised controls can result in incorrect layout of cells Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: a1c13e1ce899 Author: psomashe Date: 2013-09-24 15:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a1c13e1ce899 RT-32996 MenuButton text should be left aligned. reviewed by Jonathan. ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 26e00f0c1674 Author: jgiles Date: 2013-09-25 11:28 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/26e00f0c1674 RT-33148: Allow ComboBox subclasses to disable autohide when the ListView popup is clicked Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 35ed95c6f4ed Author: jgiles Date: 2013-09-25 11:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/35ed95c6f4ed [DOC ONLY] RT-32182: Incorrect Javadoc for TitledPane ! modules/controls/src/main/java/javafx/scene/control/TitledPane.java Changeset: d61aca2e2f9b Author: jgiles Date: 2013-09-25 12:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d61aca2e2f9b RT-25059: ListView scroll bar thumb resizes wildly Contributed-by: rbair Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java ! modules/controls/src/test/java/javafx/scene/control/ListViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java Changeset: b97f4a5bcfb2 Author: jgiles Date: 2013-09-25 15:06 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b97f4a5bcfb2 RT-33150: NPE in Ensemble 8 app when scrolling main screen with mouse wheel Cell culling was occurring slightly too early, leading to blank spots in the virtualised controls. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 8a99b06d9c22 Author: David Grieve Date: 2013-09-25 15:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8a99b06d9c22 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: d67eca687eef Author: jgiles Date: 2013-09-26 10:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d67eca687eef Backed out changeset d61aca2e2f9b (Fix for RT-25059) as it introduced RT-33172: 8.0-controls-scrum-849: up to 40% performance regression in Controls.ListView and Controls.TreeView benchmarks ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java ! modules/controls/src/test/java/javafx/scene/control/ListViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java Changeset: acf01d7fdc73 Author: jgiles Date: 2013-09-26 14:08 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/acf01d7fdc73 RT-33101: Unable to collapse/expand tree item by mouse click Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java Changeset: 240636b0c18c Author: jgiles Date: 2013-09-26 14:14 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/240636b0c18c RT-27447: [TableView] [TreeTableView] When multiple cells are selected in horizontal direction, control doesn't scroll to tle last selected item. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java Changeset: 4d3df4e0c494 Author: mickf Date: 2013-09-27 16:11 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4d3df4e0c494 RT-32966 : Multiline text is rendered outside of control bounds, reviewed by Leif ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: bdc3f404c931 Author: leifs Date: 2013-09-27 11:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bdc3f404c931 RT-33075: [DatePicker] Fix issues in Caspian CSS Reviewed-by: jdinga ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 62e08c34a629 Author: David Grieve Date: 2013-09-30 14:52 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/62e08c34a629 RT-31168: reset CssFlag to clean so css will be reapplied if the node is added back later. + modules/controls/src/test/java/javafx/scene/control/MiscellaneousTests.java ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: 88a48547ab6c Author: jgiles Date: 2013-09-27 14:07 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/88a48547ab6c RT-32592: CSS: Table header render is incorrectly when set style "-fx-border-*" from Platform.runLater Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 42e0d1d0e0a5 Author: jgiles Date: 2013-09-30 09:38 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/42e0d1d0e0a5 RT-25375: CSS : shadow not visible on ProgressBar, TitledPane,TabPane This patch only resolves the remaining issue in TitledPane - the issue is no longer reproducible for ProgressBar or TabPane. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: d3f0a56c635c Author: jgiles Date: 2013-09-30 13:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d3f0a56c635c RT-26604: [TreeView] ctrl shift down doesn't make visible area to follow the selection. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java Changeset: e0f5c9318547 Author: jgiles Date: 2013-09-30 14:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e0f5c9318547 RT-25484: [TableView, TreeTableView] pageUp/pageDown and ctrl+pageDown/pageUp navigates to the partly visible line. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 2c2b8f13d1cb Author: leifs Date: 2013-09-30 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2c2b8f13d1cb RT-26861: RTL orientation, ColorPicker palette position issue. Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 5475dfc3d98a Author: mickf Date: 2013-10-01 13:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5475dfc3d98a RT-30206 : [Button] default and cancel accelerator removing is implemented incorrectly in behavior set to false, reviewed by Leif ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ButtonSkin.java Changeset: 5a67a3c94fee Author: mickf Date: 2013-10-01 14:38 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5a67a3c94fee RT-29334 : Split pane doesn't change its rendering after items has changed order, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java Changeset: 8319071566e7 Author: mickf Date: 2013-10-01 14:57 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8319071566e7 RT-32380 - ScrollPane: Content does not scroll using keyboard, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java Changeset: 6039c1e69ed7 Author: David Grieve Date: 2013-10-01 10:00 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6039c1e69ed7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 0eb503d2b567 Author: jgodinez Date: 2013-10-01 10:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0eb503d2b567 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/graphics/src/main/docs/javafx/scene/doc-files/bounds-complex.png - modules/graphics/src/main/java/com/sun/javafx/font/coretext/CFRange.java ! modules/graphics/src/main/java/javafx/scene/Node.java From kevin.rushforth at oracle.com Tue Oct 1 11:58:52 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 01 Oct 2013 11:58:52 -0700 Subject: Compile error building FX with latest JDK Message-ID: <524B1B6C.4070908@oracle.com> All, There is a bug in JDK 8, introduced in b108, that will cause a clean build of FX to fail. https://bugs.openjdk.java.net/browse/JDK-8025173 It is expected that this will be fixed in b110. Until then, you can either stick with an older JDK, or use the following workaround, to compile the buildSrc part of the project with an older JDK: # point to older JDK gradle clean # point to latest JDK gradle -- Kevin From steve.x.northover at oracle.com Tue Oct 1 12:30:11 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 01 Oct 2013 15:30:11 -0400 Subject: com.sun.prism.tkal.Window In-Reply-To: <524B09E8.7090505@oracle.com> References: <524AF7EF.9020100@oracle.com> <524B099D.9050605@oracle.com> <524B09E8.7090505@oracle.com> Message-ID: <524B22C3.8060801@oracle.com> https://javafx-jira.kenai.com/browse/RT-33293 Steve On 01/10/2013 1:44 PM, steve.x.northover at oracle.com wrote: > .. going once ... > > Steve > > On 01/10/2013 1:42 PM, Artem Ananiev wrote: >> >> On 10/1/2013 8:27 PM, steve.x.northover at oracle.com wrote: >>> Hi FX developers, >>> >>> The class com.sun.prism.tkal.Window seems to have no references. Speak >>> now if you know anybody who uses it, otherwise it will get deleted. >> >> This package was introduced as abstraction between Newt and Glass, so >> it's obsolete now. +1 to remove. >> >> Thanks, >> >> Artem >> >>> Steve > From pedro.duquevieira at gmail.com Tue Oct 1 12:37:51 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 1 Oct 2013 20:37:51 +0100 Subject: Event for when a node gets shown on screen Message-ID: Hi Anton, If I understand correctly (never used the Bindings.select method) you're listening to the node scene property and at the same time if the window that owns the scene is showing, that is, if the stage is visible on screen? Thanks, best regards, Hi Pedro, > you may try the following code: > Bindings.select(node.sceneProperty(), "window", > "showing").addListener(new ChangeListener() ....); > BTW, this way you could add the listener even when the node is not yet > attached to any scene or window. > Regards, > Anton. -- Pedro Duque Vieira From hang.vo at oracle.com Tue Oct 1 13:18:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 20:18:53 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33293: Get rid of unused class/package com.sun.prism.tkal.Window Message-ID: <20131001201911.6AE6962C6B@hg.openjdk.java.net> Changeset: 8207cae52078 Author: snorthov Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8207cae52078 RT-33293: Get rid of unused class/package com.sun.prism.tkal.Window Summary: The IDE's and Artem find no references to this class so we killed it. Reviewed-by: rbair - modules/graphics/src/main/java/com/sun/prism/tkal/Window.java From John_Smith at symantec.com Tue Oct 1 13:46:57 2013 From: John_Smith at symantec.com (John Smith) Date: Tue, 1 Oct 2013 13:46:57 -0700 Subject: Compile error building FX with latest JDK In-Reply-To: <524B1B6C.4070908@oracle.com> References: <524B1B6C.4070908@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221689E1F407@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Wow, what happened to the JDK bug system, it's based on Jira, it works similar to the JavaFX bug system, it no longer an abominable - that's a huge step forward. Thanks for pioneering the move to a better bug reporter and testing the waters with the gradle build system! -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Tuesday, October 01, 2013 11:59 AM To: openjfx-dev at openjdk.java.net Subject: Compile error building FX with latest JDK All, There is a bug in JDK 8, introduced in b108, that will cause a clean build of FX to fail. https://bugs.openjdk.java.net/browse/JDK-8025173 It is expected that this will be fixed in b110. Until then, you can either stick with an older JDK, or use the following workaround, to compile the buildSrc part of the project with an older JDK: # point to older JDK gradle clean # point to latest JDK gradle -- Kevin From hang.vo at oracle.com Tue Oct 1 14:18:25 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 21:18:25 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32829: loading of embedded font definitions doesn't work in PrismFontLoader Message-ID: <20131001211843.7623662C72@hg.openjdk.java.net> Changeset: 4600cb2846c1 Author: Felipe Heidrich Date: 2013-10-01 14:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4600cb2846c1 RT-32829: loading of embedded font definitions doesn't work in PrismFontLoader ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontLoader.java From hang.vo at oracle.com Tue Oct 1 14:33:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 21:33:36 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32255 [win only] Message-ID: <20131001213352.29FAF62C76@hg.openjdk.java.net> Changeset: 932cecc14e49 Author: Felipe Heidrich Date: 2013-10-01 13:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/932cecc14e49 RT-32255 [win only] ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/ID2D1RenderTarget.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/IDWriteFactory.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/IDWriteFontFace.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/IDWriteLocalizedStrings.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/OS.java ! modules/graphics/src/main/native-font/directwrite.cpp From richard.bair at oracle.com Tue Oct 1 15:13:12 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 1 Oct 2013 15:13:12 -0700 Subject: Bounds constructor validation Message-ID: Hi, I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the argument is made that the width / height of a node (specifically, a Region's prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never be negative. While looking at this, I noticed that in Node, the prefWidth method relies on the layoutBounds.getWidth(). However, the Bounds class itself does not appear to do any validation of the parameters passed to the Bounds. There are no checks for NaN, and no checks for negative width, height, depth. Is there any reason why we should allow NaN, or negative width / height / depth for Bounds? Richard From richard.bair at oracle.com Tue Oct 1 15:59:41 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 1 Oct 2013 15:59:41 -0700 Subject: Moving on to a "round house kick" (forked from Re: JavaOne roundup?) In-Reply-To: <539B08F0-C6EC-438E-8583-E4F1CA6FE0CC@ultramixer.com> References: <21E125CD-B429-4A64-A513-628446FC3262@gmail.com> <17135445-8646-4B77-86BC-575812205D2F@ultramixer.com> <539B08F0-C6EC-438E-8583-E4F1CA6FE0CC@ultramixer.com> Message-ID: <91E6973A-5AC8-4A24-8F9E-7D3061185007@oracle.com> Hi Matthias, > Why do you guys always talk about embedded development? The old days of embbedded stuff have been without an OS. > What we are talking about are not really embedded platforms, these are Desktop systems like Linux/Android (linux base)/iOS (berkley based) with > energy optimized kernels which are primary used on an ARM CPUs. From my point of view the summary of an ARM cpu, operating systems and toolkits build the platform. > > Unfortunately, I missed the Freescale announcment. How could I miss it? (I used to work with their Motorola dev boards back in time) > http://gigaom.com/2013/09/23/oracle-and-freescale-push-java-for-the-internet-of-things/ > > I read this announcement and now I hopefully understand the idea where JavaFX should end up. > Oracle wants to establish a network of little running devices based on Linux/JavaFX build inside any electric device. > Now I understand everything much better. > > off topic: > Nice idea, but keep in mind we have 2013 and it is the phase of consolidation in the software and OS market. > The costumer don't want a closed system. Just one question. > > You want to buy a fridge in late 2014 with a tablet interface on the front door. You are in a very big Target super market. > There you will find one with "JavaFX powered" logo and another one with "Google Android". Which one do you buy? The key value proposition of Android is a market for apps. Are you going to have an app store and random 3rd party apps for your refrigerator? If so, Android may make good sense. If you're doing your own in-house software development, then what advantage is there to Android? The same can be said for a multitude of devices and products. JavaFX runs as fast or faster, runs on cheap hardware, is completely open source, etc. Oracle has some great embedded VM's and a lot of acceptance in this market. I can't predict the future but we've got a strong position, both on the business side and the technology side, in this market. Richard From hang.vo at oracle.com Tue Oct 1 15:48:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 01 Oct 2013 22:48:15 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33038: ScheduledService doesn't stop after calling cancel Message-ID: <20131001224852.6324362C7C@hg.openjdk.java.net> Changeset: 19431d2dcdd5 Author: rbair Date: 2013-10-01 15:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/19431d2dcdd5 RT-33038: ScheduledService doesn't stop after calling cancel Reviewed by: snorthov ! modules/graphics/src/main/java/javafx/concurrent/ScheduledService.java ! modules/graphics/src/main/java/javafx/concurrent/Service.java ! modules/graphics/src/test/java/javafx/concurrent/ScheduledServiceTest.java ! modules/graphics/src/test/java/javafx/concurrent/ServiceLifecycleTest.java From richard.bair at oracle.com Tue Oct 1 16:32:54 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 1 Oct 2013 16:32:54 -0700 Subject: Bounds constructor validation In-Reply-To: References: Message-ID: <81A5FA29-6DDF-43DE-B4AC-3B80810B2836@oracle.com> I see this is not going to work, since isEmpty() defines itself as where one component's max (maxX, maxY, maxZ) is less than the corresponding min. So we make sense, at least, out of -1 (although as far as the implementation is concerned, any negative value works just as well). On Oct 1, 2013, at 3:13 PM, Richard Bair wrote: > Hi, > > I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the argument is made that the width / height of a node (specifically, a Region's prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never be negative. While looking at this, I noticed that in Node, the prefWidth method relies on the layoutBounds.getWidth(). However, the Bounds class itself does not appear to do any validation of the parameters passed to the Bounds. There are no checks for NaN, and no checks for negative width, height, depth. > > Is there any reason why we should allow NaN, or negative width / height / depth for Bounds? > > Richard From richard.bair at oracle.com Tue Oct 1 16:46:28 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 1 Oct 2013 16:46:28 -0700 Subject: [IMPORTANT] The controls team is moving repos In-Reply-To: <5249D051.4040100@oracle.com> References: <5249D051.4040100@oracle.com> Message-ID: <061BE462-507C-4CBF-AB7C-6265434C1F14@oracle.com> This has now been completed, thanks Jonathan and the controls team for making the move so easy. Reducing the complexity of our build / test / integration is important both for allowing us to get more done with less effort (always a plus), but also in making it easier for everybody else to be able to clone from the right repos, follow the path of a fix as it goes through all the repos, test, etc. As of today, we're all working out of the "graphics" rt repo, and the master is just a read-only mirror of our once-per-week push. I'm hopeful that with 9 we can omit the master entirely, and instead what we'll do is once a week (prior to JDK promotion), we will just tag the repo at a revision that constitutes "stable", and that we won't have to do integrations at all. Richard On Sep 30, 2013, at 12:26 PM, Jonathan Giles wrote: > Hi all, > > The controls team is moving repos this week! The summary is that after > this weeks integration by David, the controls repo will remain locked. >> From this point we will no longer be able to push changesets into the > controls repo, but we can easily switch over to using the graphics repo > and carry on as-is without the need to clone new repos. We just need to > be careful to time things properly. > > For others that use the controls repo (SQE, performance teams, and > members of the openjfx community, at least), it is advised that you also > switch from using this repo after this weeks integration, as it will no > longer be relevant. > > For everyone who has a cloned repo, the steps to switch from controls to > graphics are the following: > > 1) Do an 'hg pull --rebase' in each of your repo directories to ensure > you're up to date. > 2) If you have changes to push, get them into the controls repo before > integration if you want your changes to be in this weeks build. > 3) After integration happens David will send an email indicating that > you can make the switch. At this time you can browse to your repo clone, > and within each folder (jfx, rt, rt-closed, tests, etc), you will find > an .hg directory containing a file named hgrc. Open this file in a text > editor and replace 'controls' with 'graphics'. > 4) You're done! > > Keep an eye out for any updates to these instructions, and also the > instruction to switch from David. Try not to jump the gun! > > Thanks, > Jonathan From joseph.andresen at oracle.com Tue Oct 1 17:59:11 2013 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Tue, 1 Oct 2013 17:59:11 -0700 Subject: Bounds constructor validation In-Reply-To: <81A5FA29-6DDF-43DE-B4AC-3B80810B2836@oracle.com> References: <81A5FA29-6DDF-43DE-B4AC-3B80810B2836@oracle.com> Message-ID: Kevin and I had this exact conversation years ago. I believe our answer was that anything less than 0 meant uninitialized? Maybe he can remember better than I. -Joe On Oct 1, 2013, at 4:32 PM, Richard Bair wrote: > I see this is not going to work, since isEmpty() defines itself as where one component's max (maxX, maxY, maxZ) is less than the corresponding min. So we make sense, at least, out of -1 (although as far as the implementation is concerned, any negative value works just as well). > > On Oct 1, 2013, at 3:13 PM, Richard Bair wrote: > >> Hi, >> >> I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the argument is made that the width / height of a node (specifically, a Region's prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never be negative. While looking at this, I noticed that in Node, the prefWidth method relies on the layoutBounds.getWidth(). However, the Bounds class itself does not appear to do any validation of the parameters passed to the Bounds. There are no checks for NaN, and no checks for negative width, height, depth. >> >> Is there any reason why we should allow NaN, or negative width / height / depth for Bounds? >> >> Richard > From pedro.duquevieira at gmail.com Tue Oct 1 18:59:52 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 2 Oct 2013 02:59:52 +0100 Subject: Moving on to a "round house kick" (forked from Re: JavaOne roundup?) Message-ID: Hi Richard, > Hi Matthias, > > Why do you guys always talk about embedded development? The old days of > embbedded stuff have been without an OS. > > What we are talking about are not really embedded platforms, these are > Desktop systems like Linux/Android (linux base)/iOS (berkley based) with > > energy optimized kernels which are primary used on an ARM CPUs. From my > point of view the summary of an ARM cpu, operating systems and toolkits > build the platform. > > > > Unfortunately, I missed the Freescale announcment. How could I miss it? > (I used to work with their Motorola dev boards back in time) > > > http://gigaom.com/2013/09/23/oracle-and-freescale-push-java-for-the-internet-of-things/ > > > > I read this announcement and now I hopefully understand the idea where > JavaFX should end up. > > Oracle wants to establish a network of little running devices based on > Linux/JavaFX build inside any electric device. > > Now I understand everything much better. > > > > off topic: > > Nice idea, but keep in mind we have 2013 and it is the phase of > consolidation in the software and OS market. > > The costumer don't want a closed system. Just one question. > > > > You want to buy a fridge in late 2014 with a tablet interface on the > front door. You are in a very big Target super market. > > There you will find one with "JavaFX powered" logo and another one with > "Google Android". Which one do you buy? > The key value proposition of Android is a market for apps. Are you going > to have an app store and random 3rd party apps for your refrigerator? If > so, Android may make good sense. If you're doing your own in-house software > development, then what advantage is there to Android? The same can be said > for a multitude of devices and products. > JavaFX runs as fast or faster, runs on cheap hardware, is completely open > source, etc. Oracle has some great embedded VM's and a lot of acceptance in > this market. > I can't predict the future but we've got a strong position, both on the > business side and the technology side, in this market. > Richard That's not exactly that simple and Matthias does make a point. Google in fact has been targeting the embedded space with its android OS and has a big popularity there. Check out this article: http://www.doubleencore.com/2013/07/android-embedded/ For instance one of the devices listed in the Android 4.0 release was the Pandaboard. Further android has several things in its favor besides being popular like the fact it has a specialized UI to work on small screens. There are also other strong players like Ubuntu and other Linux distributions. I do love JavaFX and I do hope it becomes the SDK of choice for creating UI applications but without it supporting iOS and Android it will slowly die or become a niche tool. The last 2 JavaOnes have been pretty disappointing to me with too much emphasis on the embedded space and no news whatsoever about iOS, Android (or windows phone). To me, embedded should be last in the list of priorities. I do think you guys know the importance of these and are working to make it a reality. Anyone who thinks this won't matter is simply not in touch with reality. This kind of effort cannot be made by the community alone, there's too much to be done also it requires specialized knowledge and guidance that probably only Oracle staff can provide. There is already one big player in the cross platform development field: PhoneGap (or Cordova) owned by Adobe, which I personally hate but which enjoys big popularity. The longer JavaFX is without ios and android support the worse. Other players will jump in the cross platform development space and it might be too late when JavaFX jumps in as well. With JavaFX 1 Oracle made the huge mistake of not listening to the community, lets hope that with JavaFX 2+, Oracle has learned from this. Best regards, -- Pedro Duque Vieira From chien.yang at oracle.com Tue Oct 1 23:11:21 2013 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 01 Oct 2013 23:11:21 -0700 Subject: Bounds constructor validation In-Reply-To: References: <81A5FA29-6DDF-43DE-B4AC-3B80810B2836@oracle.com> Message-ID: <524BB909.7090806@oracle.com> min* > max* implies empty bounds. This semantic can be traced back to https://javafx-jira.kenai.com/browse/RT-11793 - Chien On 10/1/2013 5:59 PM, Joseph Andresen wrote: > Kevin and I had this exact conversation years ago. I believe our answer was that anything less than 0 meant uninitialized? > > Maybe he can remember better than I. > > -Joe > > On Oct 1, 2013, at 4:32 PM, Richard Bair wrote: > >> I see this is not going to work, since isEmpty() defines itself as where one component's max (maxX, maxY, maxZ) is less than the corresponding min. So we make sense, at least, out of -1 (although as far as the implementation is concerned, any negative value works just as well). >> >> On Oct 1, 2013, at 3:13 PM, Richard Bair wrote: >> >>> Hi, >>> >>> I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the argument is made that the width / height of a node (specifically, a Region's prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never be negative. While looking at this, I noticed that in Node, the prefWidth method relies on the layoutBounds.getWidth(). However, the Bounds class itself does not appear to do any validation of the parameters passed to the Bounds. There are no checks for NaN, and no checks for negative width, height, depth. >>> >>> Is there any reason why we should allow NaN, or negative width / height / depth for Bounds? >>> >>> Richard From hang.vo at oracle.com Wed Oct 2 01:18:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 08:18:36 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: improved fillRect with ImagePaint (RT-29811) Message-ID: <20131002082009.2E97D62C95@hg.openjdk.java.net> Changeset: 90e48442d0ff Author: Martin Soch Date: 2013-10-02 10:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/90e48442d0ff SW pipeline: improved fillRect with ImagePaint (RT-29811) ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java + modules/graphics/src/main/java/com/sun/prism/sw/SWPaint.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWUtils.java ! modules/graphics/src/main/native-prism-sw/JPiscesRenderer.c ! modules/graphics/src/main/native-prism-sw/PiscesPaint.c ! modules/graphics/src/main/native-prism-sw/PiscesRenderer.h From anton.nashatyrev at oracle.com Wed Oct 2 03:58:38 2013 From: anton.nashatyrev at oracle.com (anton nashatyrev) Date: Wed, 02 Oct 2013 14:58:38 +0400 Subject: Event for when a node gets shown on screen In-Reply-To: References: Message-ID: <524BFC5E.5060200@oracle.com> Hi Pedro, that binding is 'watching' for the whole chain of properties and is changed to 'true' only when the node is attached to the scene, the scene is attached to the window and the window isShowing() = true. Vice verse it changed to 'false' if any of the above conditions becomes false, i.e. node or scene is detached or window is hidden. Regards, Anton. On 01.10.2013 23:37, Pedro Duque Vieira wrote: > Hi Anton, > > If I understand correctly (never used the Bindings.select method) > you're listening to the node scene property and at the same time if > the window that owns the scene is showing, that is, if the stage is > visible on screen? > > Thanks, best regards, > > Hi Pedro, > you may try the following code: > Bindings.select(node.sceneProperty(), "window", > "showing").addListener(new ChangeListener() ....); > BTW, this way you could add the listener even when the node is not yet > attached to any scene or window. > Regards, > Anton. > > > -- > Pedro Duque Vieira From pedro.duquevieira at gmail.com Wed Oct 2 07:10:40 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 2 Oct 2013 15:10:40 +0100 Subject: Event for when a node gets shown on screen In-Reply-To: <524BFC5E.5060200@oracle.com> References: <524BFC5E.5060200@oracle.com> Message-ID: Yap, just what I thought. Sounds like a great idea. I'll give it a try. Thanks Anton, best regards, On Wed, Oct 2, 2013 at 11:58 AM, anton nashatyrev < anton.nashatyrev at oracle.com> wrote: > Hi Pedro, > > that binding is 'watching' for the whole chain of properties and is > changed to 'true' only when the node is attached to the scene, the scene is > attached to the window and the window isShowing() = true. Vice verse it > changed to 'false' if any of the above conditions becomes false, i.e. node > or scene is detached or window is hidden. > > Regards, > Anton. > > > On 01.10.2013 23:37, Pedro Duque Vieira wrote: > > Hi Anton, > > If I understand correctly (never used the Bindings.select method) you're > listening to the node scene property and at the same time if the window > that owns the scene is showing, that is, if the stage is visible on screen? > > Thanks, best regards, > > Hi Pedro, >> you may try the following code: >> Bindings.select(node.sceneProperty(), "window", >> "showing").addListener(new ChangeListener() ....); >> BTW, this way you could add the listener even when the node is not yet >> attached to any scene or window. >> Regards, >> Anton. > > > -- > Pedro Duque Vieira > > > -- Pedro Duque Vieira From kevin.rushforth at oracle.com Wed Oct 2 08:50:32 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 02 Oct 2013 08:50:32 -0700 Subject: Bounds constructor validation In-Reply-To: References: Message-ID: <524C40C8.2080304@oracle.com> Note that a negative width or height is considered empty (see Bounds.isEmpty()) so it might break something if you couldn't constuct such a bounds. -- Kevin Richard Bair wrote: > Hi, > > I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the argument is made that the width / height of a node (specifically, a Region's prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never be negative. While looking at this, I noticed that in Node, the prefWidth method relies on the layoutBounds.getWidth(). However, the Bounds class itself does not appear to do any validation of the parameters passed to the Bounds. There are no checks for NaN, and no checks for negative width, height, depth. > > Is there any reason why we should allow NaN, or negative width / height / depth for Bounds? > > Richard From steve.x.northover at oracle.com Wed Oct 2 10:09:42 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 02 Oct 2013 13:09:42 -0400 Subject: Bounds constructor validation In-Reply-To: References: <81A5FA29-6DDF-43DE-B4AC-3B80810B2836@oracle.com> Message-ID: <524C5356.3000003@oracle.com> If not already up to date, we should update the Javadoc so that we don't have the conversation again. Steve On 01/10/2013 8:59 PM, Joseph Andresen wrote: > Kevin and I had this exact conversation years ago. I believe our answer was that anything less than 0 meant uninitialized? > > Maybe he can remember better than I. > > -Joe > > On Oct 1, 2013, at 4:32 PM, Richard Bair wrote: > >> I see this is not going to work, since isEmpty() defines itself as where one component's max (maxX, maxY, maxZ) is less than the corresponding min. So we make sense, at least, out of -1 (although as far as the implementation is concerned, any negative value works just as well). >> >> On Oct 1, 2013, at 3:13 PM, Richard Bair wrote: >> >>> Hi, >>> >>> I'm looking at https://javafx-jira.kenai.com/browse/RT-23446, where the argument is made that the width / height of a node (specifically, a Region's prefWidth, minWidth, maxWidth, prefHeight, minHeight, maxHeight) should never be negative. While looking at this, I noticed that in Node, the prefWidth method relies on the layoutBounds.getWidth(). However, the Bounds class itself does not appear to do any validation of the parameters passed to the Bounds. There are no checks for NaN, and no checks for negative width, height, depth. >>> >>> Is there any reason why we should allow NaN, or negative width / height / depth for Bounds? >>> >>> Richard From hang.vo at oracle.com Wed Oct 2 11:04:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 18:04:05 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing Message-ID: <20131002180527.3E47362CAE@hg.openjdk.java.net> Changeset: 6204306cde59 Author: dmasada Date: 2013-10-02 10:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6204306cde59 RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/BouncingBallsApp.java From hang.vo at oracle.com Wed Oct 2 12:18:28 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 19:18:28 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33103: Children may change, iterate over a copy. Message-ID: <20131002191857.3748362CB9@hg.openjdk.java.net> Changeset: 67b0664167d6 Author: David Grieve Date: 2013-10-02 14:53 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/67b0664167d6 RT-33103: Children may change, iterate over a copy. Reviewed by paru ! modules/graphics/src/main/java/javafx/scene/Parent.java From hang.vo at oracle.com Wed Oct 2 12:33:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 19:33:36 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20131002193433.DE81D62CBC@hg.openjdk.java.net> Changeset: 31c7ced6e2e6 Author: psomashe Date: 2013-10-02 12:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/31c7ced6e2e6 RT-27768 : PieChart adding new data lead to incorrect style class updating. reviwed by Jonathan. ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java Changeset: bd2f3d13cbf7 Author: psomashe Date: 2013-10-02 12:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bd2f3d13cbf7 RT-33245 Font is not applied to charts axis with caspian theme reviwed by David. ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 04dfdd1ed7be Author: David Grieve Date: 2013-10-02 15:26 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/04dfdd1ed7be [TEST-ONLY] RT-33103 unit test ! modules/controls/src/test/java/javafx/scene/control/MiscellaneousTests.java From richard.bair at oracle.com Wed Oct 2 13:37:29 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 2 Oct 2013 13:37:29 -0700 Subject: [API-REVIEW] RT-32848: Add CENTER constant to BackgroundPosition Message-ID: <6FD66534-5CD1-4232-9247-CF532F971704@oracle.com> Simple API addition to BackgroundPosition: /** * A BackgroundPosition which will center a BackgroundImage. */ public static final BackgroundPosition CENTER = new BackgroundPosition( Side.LEFT, .5, true, Side.TOP, .5, true); No implementation changes. From hang.vo at oracle.com Wed Oct 2 13:48:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 20:48:39 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131002204920.C432962CBD@hg.openjdk.java.net> Changeset: 48e93b84056d Author: rbair Date: 2013-10-02 13:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/48e93b84056d RT-32848: Add CENTER constant to BackgroundPosition Reviewed-by: snorthov ! modules/graphics/src/main/java/javafx/scene/layout/BackgroundPosition.java ! modules/graphics/src/test/java/javafx/scene/layout/BackgroundPositionTest.java Changeset: 043bd9ac4de2 Author: rbair Date: 2013-10-02 13:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/043bd9ac4de2 [DOC-ONLY] Update Bounds class doc to discuss empty bounds. It is also described in isEmpty method documentation and already covered by tests. ! modules/graphics/src/main/java/javafx/geometry/Bounds.java From hang.vo at oracle.com Wed Oct 2 14:03:38 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 21:03:38 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131002210409.A84B162CBE@hg.openjdk.java.net> Changeset: e1f9a085f399 Author: rbair Date: 2013-10-02 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e1f9a085f399 RT-33262: Not able to use Task and Service from the init method of Application Reviewed-by: kcr + apps/toys/Hello/src/main/java/hello/HelloTask.java ! modules/graphics/src/main/java/javafx/concurrent/Service.java ! modules/graphics/src/main/java/javafx/concurrent/Task.java ! modules/graphics/src/main/java/javafx/geometry/Bounds.java ! modules/graphics/src/test/java/javafx/concurrent/AbstractTask.java ! modules/graphics/src/test/java/javafx/concurrent/ServiceLifecycleTest.java ! modules/graphics/src/test/java/javafx/concurrent/ServiceTest.java ! modules/graphics/src/test/java/javafx/concurrent/TestServiceFactory.java Changeset: d70c498de565 Author: rbair Date: 2013-10-02 13:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d70c498de565 RT-23446: Negative height or width should be forbidden Reviewed-by: msladecek ! modules/graphics/src/main/java/javafx/scene/Group.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/scene/layout/Region.java ! modules/graphics/src/test/java/javafx/scene/GroupTest.java + modules/graphics/src/test/java/javafx/scene/Node_layoutSizes_Test.java ! modules/graphics/src/test/java/javafx/scene/layout/RegionTest.java ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java ! modules/web/src/main/java/javafx/scene/web/WebView.java From tobi at ultramixer.com Wed Oct 2 14:43:39 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 2 Oct 2013 23:43:39 +0200 Subject: Pagination: hide control box Message-ID: <99391163-0B32-4EA1-9F04-8223DC6461B2@ultramixer.com> Hi, I would like to use Pagination for an iOS animation between two slide.slides. Would it be possible to hide the pagination control? From hang.vo at oracle.com Wed Oct 2 15:03:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 22:03:57 +0000 Subject: hg: openjfx/8/graphics/rt: 4 new changesets Message-ID: <20131002220517.9430862CC0@hg.openjdk.java.net> Changeset: 1bbb02497363 Author: jgiles Date: 2013-10-01 10:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1bbb02497363 [DOC ONLY] RT-32230: CheckBoxTableCell page doesn't display some CSS styles ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTableCell.java Changeset: 988cdf5dfc94 Author: jgiles Date: 2013-10-02 10:10 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/988cdf5dfc94 RT-33106: Ensemble8: Service NPE on refresh button click ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/test/java/javafx/scene/control/ListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableRowTest.java Changeset: 2f48570d437f Author: jgiles Date: 2013-10-02 12:29 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2f48570d437f RT-33301: ctrl+shift+down is looping in all virtualised controls RT-33307: Ctrl+shift+up/down should map to up/down in virtualised controls when in single selection mode ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/test/java/javafx/scene/control/ListViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java Changeset: dfe5f213aab4 Author: jgiles Date: 2013-10-02 15:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dfe5f213aab4 RT-31206: [TableView] custom skin replacements fails, when columns or data is added. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java From hang.vo at oracle.com Wed Oct 2 15:18:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 22:18:29 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-33036 Separator in ColorPicker ColorPalette is broken under Caspian. Message-ID: <20131002221845.30B9662CC2@hg.openjdk.java.net> Changeset: 5f4b2dc52be7 Author: psomashe Date: 2013-10-02 15:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5f4b2dc52be7 Fix RT-33036 Separator in ColorPicker ColorPalette is broken under Caspian. reviewed by Jonathan. ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css From hang.vo at oracle.com Wed Oct 2 15:33:24 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 02 Oct 2013 22:33:24 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29922 Ensemble8: remove builders (partial) Message-ID: <20131002223339.1947862CC3@hg.openjdk.java.net> Changeset: 9b496ab6ad57 Author: dmasada Date: 2013-10-02 15:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9b496ab6ad57 RT-29922 Ensemble8: remove builders (partial) ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/animation/transitions/sequentialtransition/SequentialTransitionApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/area/stacked/StackedAreaChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bar/stacked/StackedBarChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/colorpicker/ColorPickerApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/pagination/PaginationApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/splitpane/hiddensplitpane/HiddenSplitPaneApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/tab/tabpane/TabPaneApp.java From richard.bair at oracle.com Wed Oct 2 17:09:55 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 2 Oct 2013 17:09:55 -0700 Subject: Pagination: hide control box In-Reply-To: <99391163-0B32-4EA1-9F04-8223DC6461B2@ultramixer.com> References: <99391163-0B32-4EA1-9F04-8223DC6461B2@ultramixer.com> Message-ID: You should be able to find the nodes and hide them, I would think. Probably even from CSS. Richard On Oct 2, 2013, at 2:43 PM, Tobias Bley wrote: > Hi, > > I would like to use Pagination for an iOS animation between two slide.slides. Would it be possible to hide the pagination control? > > From hang.vo at oracle.com Wed Oct 2 18:03:48 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 01:03:48 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29922 Ensemble8: remove builders (partial).Update generated sample info Message-ID: <20131003010419.6142B62CC6@hg.openjdk.java.net> Changeset: bed4d07b03e8 Author: dmasada Date: 2013-10-02 17:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bed4d07b03e8 RT-29922 Ensemble8: remove builders (partial).Update generated sample info ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java From hang.vo at oracle.com Wed Oct 2 18:18:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 01:18:15 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33231: [JAVADOC] PhongMaterial JavaDoc fixes and clarifications Message-ID: <20131003011839.CBC1062CC7@hg.openjdk.java.net> Changeset: 51aa0b68a442 Author: Yao Wang Date: 2013-10-02 18:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/51aa0b68a442 RT-33231: [JAVADOC] PhongMaterial JavaDoc fixes and clarifications Summary: Fix format errors and Add spec that bumpMap property requires a normal map. Reviewed-by: kcr ! modules/graphics/src/main/java/javafx/scene/paint/PhongMaterial.java From kirill.kirichenko at oracle.com Thu Oct 3 01:15:40 2013 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Thu, 03 Oct 2013 12:15:40 +0400 Subject: JavaFX Media HTTPS support Message-ID: <524D27AC.6060906@oracle.com> We've started working on HTTPS support in JavaFX Media component. Due to internal restrictions we won't be able to support HTTPS on MacOs (and possibly on iOS). Do you think it a good idea to add a feature with limited support - just for Linux and Windows ? From hang.vo at oracle.com Thu Oct 3 00:18:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 07:18:37 +0000 Subject: hg: openjfx/8/graphics/rt: [DOC] RT-32520 FXML reference is outdated Message-ID: <20131003071911.96A9362CD2@hg.openjdk.java.net> Changeset: 5677ce5e6af3 Author: Martin Sladecek Date: 2013-10-03 09:09 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5677ce5e6af3 [DOC] RT-32520 FXML reference is outdated ! modules/fxml/src/main/docs/javafx/fxml/doc-files/fxml.css ! modules/fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html From kirill.kirichenko at oracle.com Thu Oct 3 01:28:08 2013 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Thu, 03 Oct 2013 12:28:08 +0400 Subject: JavaFX Media HTTPS support In-Reply-To: References: <524D27AC.6060906@oracle.com> Message-ID: <524D2A98.1020708@oracle.com> For HTTP Live Streaming and some cases for MP4 on Mac we using QTMovie, which only accepts URLs for FILE or HTTP protocol only and handles downloading, progress buffering and HLS playlists parsing internally. We do not have control over it. MP4 can also be played on Mac via GStreamer via Video Acceleration Framework, but it is limited to only one instance and one stream across all apps (meaning if someone runs QuickTime and loaded movie we cannot use it), limited support of H.264 bitsream (not all resolutions, framerates, profiles are supported). It depends on video card. On 03.10.2013 12:24, Randahl Isaksen wrote: > No. Adding a feature which only works on some desktop OSes ruins the > WORA quality of Java. What kinds of restrictions? Resource restrictions > or...? > > Den 03/10/2013 10.19 skrev "Kirill Kirichenko" > >: > > We've started working on HTTPS support in JavaFX Media component. > > Due to internal restrictions we won't be able to support HTTPS on > MacOs (and possibly on iOS). > > Do you think it a good idea to add a feature with limited support - > just for Linux and Windows ? > From kirill.kirichenko at oracle.com Thu Oct 3 01:29:39 2013 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Thu, 03 Oct 2013 12:29:39 +0400 Subject: JavaFX Media HTTPS support In-Reply-To: <524D27AC.6060906@oracle.com> References: <524D27AC.6060906@oracle.com> Message-ID: <524D2AF3.2060508@oracle.com> Forgot to add. It's this issue: https://javafx-jira.kenai.com/browse/RT-28420 On 03.10.2013 12:15, Kirill Kirichenko wrote: > We've started working on HTTPS support in JavaFX Media component. > > Due to internal restrictions we won't be able to support HTTPS on MacOs > (and possibly on iOS). > > Do you think it a good idea to add a feature with limited support - just > for Linux and Windows ? From tom.schindl at bestsolution.at Thu Oct 3 01:51:11 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 03 Oct 2013 10:51:11 +0200 Subject: JavaFX Media HTTPS support In-Reply-To: <524D2A98.1020708@oracle.com> References: <524D27AC.6060906@oracle.com> <524D2A98.1020708@oracle.com> Message-ID: <524D2FFF.9000908@bestsolution.at> On 03.10.13 10:28, Kirill Kirichenko wrote: > > For HTTP Live Streaming and some cases for MP4 on Mac we using QTMovie, > which only accepts URLs for FILE or HTTP protocol only and handles > downloading, progress buffering and HLS playlists parsing internally. We > do not have control over it. MP4 can also be played on Mac via GStreamer > via Video Acceleration Framework, but it is limited to only one instance > and one stream across all apps (meaning if someone runs QuickTime and > loaded movie we cannot use it), limited support of H.264 bitsream (not > all resolutions, framerates, profiles are supported). It depends on > video card. > > On 03.10.2013 12:24, Randahl Isaksen wrote: >> No. Adding a feature which only works on some desktop OSes ruins the >> WORA quality of Java. What kinds of restrictions? Resource restrictions >> or...? >> I don't see that as a problem, if I can query for it I'd welcome that this is possible on other platforms. The common denominator problem is causing more damage to Java UIs. If you want to write applications today you need to exploit the native platform as much as possible, so IMHO WORA is not getting you anywhere. What JavaFX gives me is LORA (learn once run anywhere). Tom From felix.bembrick at gmail.com Thu Oct 3 01:52:18 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 3 Oct 2013 18:52:18 +1000 Subject: Font rendering improvements with JDK8 b109 Message-ID: I have noticed quite a significant improvement in the quality of font rendering since JDK b109 on my Windows machine. The text looks darker and crisper and is now almost on par with the quality of fonts in something like IE10. What has changed? Am I just imagining it (I don't think so!)? N.B. The font rendering within Canvas or TextFlow still remains very poor :-( From felix.bembrick at gmail.com Thu Oct 3 02:09:35 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 3 Oct 2013 19:09:35 +1000 Subject: JavaFX Media HTTPS support In-Reply-To: <524D2FFF.9000908@bestsolution.at> References: <524D27AC.6060906@oracle.com> <524D2A98.1020708@oracle.com> <524D2FFF.9000908@bestsolution.at> Message-ID: I agree. If the inability to provide 100% WORA for a particular feature results in 0% availability then that is a fail. I would rather the feature was available where it worked. At least we can build apps with those features on those platforms. On 3 October 2013 18:51, Tom Schindl wrote: > On 03.10.13 10:28, Kirill Kirichenko wrote: > > > > For HTTP Live Streaming and some cases for MP4 on Mac we using QTMovie, > > which only accepts URLs for FILE or HTTP protocol only and handles > > downloading, progress buffering and HLS playlists parsing internally. We > > do not have control over it. MP4 can also be played on Mac via GStreamer > > via Video Acceleration Framework, but it is limited to only one instance > > and one stream across all apps (meaning if someone runs QuickTime and > > loaded movie we cannot use it), limited support of H.264 bitsream (not > > all resolutions, framerates, profiles are supported). It depends on > > video card. > > > > On 03.10.2013 12:24, Randahl Isaksen wrote: > >> No. Adding a feature which only works on some desktop OSes ruins the > >> WORA quality of Java. What kinds of restrictions? Resource restrictions > >> or...? > >> > > I don't see that as a problem, if I can query for it I'd welcome that > this is possible on other platforms. The common denominator problem is > causing more damage to Java UIs. > > If you want to write applications today you need to exploit the native > platform as much as possible, so IMHO WORA is not getting you anywhere. > What JavaFX gives me is LORA (learn once run anywhere). > > Tom > From swpalmer at gmail.com Thu Oct 3 04:44:51 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 3 Oct 2013 07:44:51 -0400 Subject: JavaFX Media HTTPS support In-Reply-To: <524D2A98.1020708@oracle.com> References: <524D27AC.6060906@oracle.com> <524D2A98.1020708@oracle.com> Message-ID: I'm curious about "only one instance" for MP4 playback. QuickTime Player on OS X simultaneously plays multiple MP4s. Of course it isn't using GStreamer, but if you are going direct to QuickTime for HTTPLS what's stopping you from doing the same for MP4? Scott On Thu, Oct 3, 2013 at 4:28 AM, Kirill Kirichenko < kirill.kirichenko at oracle.com> wrote: > > For HTTP Live Streaming and some cases for MP4 on Mac we using QTMovie, > which only accepts URLs for FILE or HTTP protocol only and handles > downloading, progress buffering and HLS playlists parsing internally. We do > not have control over it. MP4 can also be played on Mac via GStreamer via > Video Acceleration Framework, but it is limited to only one instance and > one stream across all apps (meaning if someone runs QuickTime and loaded > movie we cannot use it), limited support of H.264 bitsream (not all > resolutions, framerates, profiles are supported). It depends on video card. > > From hang.vo at oracle.com Thu Oct 3 05:04:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 12:04:03 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131003120524.DE54462CE5@hg.openjdk.java.net> Changeset: 98b9cd9ee0fc Author: Martin Sladecek Date: 2013-10-03 13:49 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98b9cd9ee0fc [JAVADOC/DOC] RT-30851 FXMLLoader has many undocumented fields ! modules/fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java Changeset: b182b0b07282 Author: Martin Sladecek Date: 2013-10-03 14:01 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b182b0b07282 RT-33052 Generify FXMLLoader.load instance methods Reviewed-by: ekrejcir ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java From hang.vo at oracle.com Thu Oct 3 07:04:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 14:04:02 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131003140450.B319E62CF0@hg.openjdk.java.net> Changeset: abbc53855b43 Author: flar Date: 2013-10-03 06:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/abbc53855b43 Fix RT-32472: NPE setting a broken image into a working ImageView with viewport Reviewed by: kcr, ckyang ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGImageView.java Changeset: 8baf1c812ced Author: Oldrich Maticka Date: 2013-10-03 16:00 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8baf1c812ced iOS: replacing StringBuffer occurrences in favour of StringBuilder ! modules/web/src/ios/java/javafx/scene/web/ExportedJavaObject.java ! modules/web/src/ios/java/javafx/scene/web/JS2JavaBridge.java ! modules/web/src/ios/java/javafx/scene/web/JSONEncoder.java From hang.vo at oracle.com Thu Oct 3 08:33:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 15:33:39 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-32974 LensTouchInputSupport calls GestureSupport methods from the wrong thread. Move calls to correct thread. Message-ID: <20131003153433.B3C2C62CF6@hg.openjdk.java.net> Changeset: 5fd60ebdb9d5 Author: Lisa.Selle at oracle.com Date: 2013-10-03 11:19 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5fd60ebdb9d5 Fix for RT-32974 LensTouchInputSupport calls GestureSupport methods from the wrong thread. Move calls to correct thread. Reviewed by Rafi Tayar. Tested with HelloSanity on beagle/pi. ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java From richard.bair at oracle.com Thu Oct 3 08:40:22 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 3 Oct 2013 08:40:22 -0700 Subject: FXMLLoader templates In-Reply-To: <524A76A2.80503@oracle.com> References: <523C3DF6.6090109@oracle.com> <524A76A2.80503@oracle.com> Message-ID: <8D55E0AA-AD3F-4E10-962A-0ED143264759@oracle.com> After reviewing the situation with Martin my feeling was that this API is just not ready for prime-time. In fact, I'd like to think of how FXML fits in from a more holistic perspective, meaning, it might be time to consider a different approach to loading FXML files than the way FXMLLoader was designed to be used. I've never had that settled feeling about FXMLLoader (whereas most of the functionality in FXML itself I've been quite pleased with). And as Tom mentioned, there is now a much faster alternative anyway (it just won't work as well for dynamically loaded FXML, unless you do the compilation step locally). Richard On Oct 1, 2013, at 12:15 AM, Martin Sladecek wrote: > After discussion with Richard, we decided to remove the template flag from FXMLLoader for 8.0. > This API is not mature yet, due to the reasons described below and should be completely re-designed for some next release. > > This means that loading the same fxml multiple times will still require multiple FXMLLoader instances. > > Any comments? > > Thanks, > -Martin > > On 09/20/2013 02:22 PM, Martin Sladecek wrote: >> Hi, >> I would like to discuss a 8.0 feature of FXMLLoader - the template flag. >> I was introduced with this issue: https://javafx-jira.kenai.com/browse/RT-23413, but unfortunately, it never worked: https://javafx-jira.kenai.com/browse/RT-28121. I was trying to fix the issue, but the whole concept of a flag for loading templates seems hardly usable and incorrect to me and should be replaced with something more appropriate. >> >> The reason is the handling of root, controller and the namespace before and after the load. Both are treated in 2 different ways. Before the load, they are used to adjust the following load - by setting the root (for tag), setting the namespace and a controller. >> However, after the load, these properties (though not FX-properties) can be used to query what was just loaded. The root of the FXML, the namespace with all "id"s and the controller. >> >> Now that's not very useful when you want to use template loading. My solution for RT-28121 (when keeping the old API) is to save the namespace after setTemplate(true) was called, using this namespace on each load(), clearing it at the begging of load() + disallow setController() for this mode. >> >> But that doesn't cover all of the relevant use-cases I can think of. Actually, without changing the API, I doubt we can support all such use-cases. >> >> Here's the set I'm working with: >> 1) setup some "template namespace", n times do { adjust namespace (based on template namespace) , load) } >> >> 2) n times do {load, query id from namespace} >> >> 3) n times do {setController(new Controller) load } >> >> 4) n times do {load, query newly created controller} >> >> 5,6) same as 3,4 but with root >> >> So while in 1,3 we would need to clear namespace/controller after each load, in 2,4 we need to clear it before each load. In case 3), forgetting to set a new controller would otherwise result in 2 instances with the same controller. >> >> One solution might be to split this to 2 independent calls. setController/getLoadedController, ObservableMap getNamespace() and Map getLoadedNamespace (unmodifiable). >> >> Another might be a completely new class FXMLTemplate. >> It might yield new pre-set FXMLLoaders that can be adjusted and loaded, but it means generating a temporary object for each call. >> Also, FXMLLoader would need to be updated, so that it's only possible to call load() once. >> >> Other ideas / use-cases? >> >> Thanks, >> -Martin > From hang.vo at oracle.com Thu Oct 3 08:48:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 15:48:29 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131003155031.6FE1462CFD@hg.openjdk.java.net> Changeset: 98ddce26ad7b Author: prrace Date: 2013-10-03 08:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98ddce26ad7b RT-32840: javadoc on javafx.print.Paper is not up to date ! modules/graphics/src/main/java/javafx/print/Paper.java Changeset: b606518bf749 Author: kcr Date: 2013-10-03 08:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b606518bf749 RT-32975: Exception in PlatformImpl.checkIdle with glass thread checks enabled Reviewed-by: art, anthony ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java ! modules/graphics/src/main/java/javafx/application/Platform.java ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubToolkit.java ! modules/graphics/src/test/java/javafx/scene/SceneTest.java From richard.bair at oracle.com Thu Oct 3 08:57:08 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 3 Oct 2013 08:57:08 -0700 Subject: A milestone in history management Message-ID: I just wanted to say, we've now had 30 change sets without a single merge change set. I'm bursting with joy :-). Looking forward to reaching 50. Cheers Richard From hang.vo at oracle.com Thu Oct 3 09:48:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 16:48:27 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20131003164937.BA76362D08@hg.openjdk.java.net> Changeset: e6ee45d834cb Author: rbair Date: 2013-10-03 09:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e6ee45d834cb [TEST-ONLY] Updated NGRegionTest to make sure that swapping backgrounds on a Region always causes the opaque region to be marked invalid ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGRegionTest.java Changeset: abc606e761fb Author: rbair Date: 2013-10-03 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/abc606e761fb [IDEA-ONLY] Added IntelliJ IDEA project support for "system" tests + .idea/SystemTests.iml ! .idea/modules.xml Changeset: da16b3edc363 Author: rbair Date: 2013-10-03 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/da16b3edc363 [IDEA-ONLY] Fixed bad path to test/java ! .idea/SystemTests.iml From hang.vo at oracle.com Thu Oct 3 09:18:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 16:18:31 +0000 Subject: hg: openjfx/8/graphics/rt: [REFACTOR-ONLY]: Added some tests for NGRegion, and also did some very coarse refactoring by breaking the render method up into several sub methods. The only actual code change I made was to a copy/paste bug that existed where bottom was using "right" in its computation. All region tests continue passing. Some new region tests are ignored because of existing bugs. I'm pushing this refactor first, so I can then fix those bugs I found. Message-ID: <20131003161846.8C19762D03@hg.openjdk.java.net> Changeset: 26fbef1eb521 Author: rbair Date: 2013-10-03 09:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/26fbef1eb521 [REFACTOR-ONLY]: Added some tests for NGRegion, and also did some very coarse refactoring by breaking the render method up into several sub methods. The only actual code change I made was to a copy/paste bug that existed where bottom was using "right" in its computation. All region tests continue passing. Some new region tests are ignored because of existing bugs. I'm pushing this refactor first, so I can then fix those bugs I found. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java + modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGRegionTest.java From sven.reimers at gmail.com Thu Oct 3 10:44:17 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 3 Oct 2013 19:44:17 +0200 Subject: Small API Tweak to Task (Worker) In-Reply-To: References: Message-ID: What I probably was thinking about is task that written with the intention that they should not be cancelled, e.g. calculations you want a result of. It is not so much about you could not make them cancelable, but to show this is not intended to be cancelled... Hope I could clarify my train thought. Thanks for listening -Sven On Thu, Sep 26, 2013 at 10:39 PM, Richard Bair wrote: > What are some examples of tasks that would not be cancelable? > > Richard > > On Sep 2, 2013, at 9:13 AM, Sven Reimers wrote: > > > Hi, > > > > I am trying to build a UI representation of a Task (using a ProgressBar > and > > other things). > > > > Since Tasks are cancellabe I thought about adding a button to cancel the > > underlying Task. So far so good. > > > > Is there any reason why a Task can not express, if it is intended for the > > task to act cooperative to a call to cancel? Something along the > following > > lines > > > > public boolean isCancellable() { return true; } // default > > > > This would enable users of the API to distinguish between Tasks which > > really can be cancelled from those which just fulfill the API contract. > > > > Comments? > > > > -Sven > > > > -- > > Sven Reimers > > > > * Senior Expert Software Architect > > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > > * Community Leader NetBeans: http://community.java.net/netbeans > > Desktop Java: > > http://community.java.net/javadesktop > > * Duke's Choice Award Winner 2009 > > * Blog: http://nbguru.blogspot.com > > > > * XING: https://www.xing.com/profile/Sven_Reimers8 > > * LinkedIn: http://www.linkedin.com/in/svenreimers > > > > Join the NetBeans Groups: > > * XING: http://www.xing.com/group-20148.82db20 > > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > > http://www.linkedin.com/groups?gid=107402 > > http://www.linkedin.com/groups?gid=1684717 > > * Oracle: https://mix.oracle.com/groups/18497 > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From hang.vo at oracle.com Thu Oct 3 10:18:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 17:18:33 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32249 fixing Full Screen overly hint Message-ID: <20131003171901.C02E762D09@hg.openjdk.java.net> Changeset: f7b87969cd45 Author: David Hill Date: 2013-10-03 13:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f7b87969cd45 RT-32249 fixing Full Screen overly hint Summary: Changing full screen overlay hint when the default exit key has been changed Reviewed-by: kcr, bair ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/OverlayWarning.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java ! modules/graphics/src/main/java/javafx/stage/Stage.java ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_de.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_es.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_fr.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_it.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_ja.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_ko.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_pt_BR.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_sv.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_zh_CN.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_zh_TW.properties From hang.vo at oracle.com Thu Oct 3 10:29:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 17:29:46 +0000 Subject: hg: openjfx/8/master/rt: 60 new changesets Message-ID: <20131003175544.22F4362D12@hg.openjdk.java.net> Changeset: 50a4af3f8b03 Author: jgiles Date: 2013-09-18 12:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/50a4af3f8b03 RT-31100: LCD text not rendering on cached node unless background is set Contributed-by: jasper Reviewed-by: felipe, jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 5031afa0b69d Author: anashaty Date: 2013-09-19 15:56 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5031afa0b69d RT-31393: Wrong widget is selected if another had focus before it Reviewed-by: jgiles,dmarkov ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java Changeset: 8db542421315 Author: psomashe Date: 2013-09-19 09:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8db542421315 RT-29433 ChoiceBox keeps selected item when underlying collection is replaced. unit test : checkSelectedItemAfterReplacingDataWithEmptyList() ! modules/controls/src/main/java/javafx/scene/control/ChoiceBox.java ! modules/controls/src/test/java/javafx/scene/control/ChoiceBoxTest.java Changeset: 2441235395a4 Author: leifs Date: 2013-09-20 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2441235395a4 RT-27199: HTML Editor, in ja and ko locales, can't open "Font Size" menu. Reviewed-by: mickf ! modules/web/src/main/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java Changeset: 047354976850 Author: leifs Date: 2013-09-23 15:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/047354976850 RT-33074: [DatePicker] Fix issues in Modena CSS ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: ac217689464d Author: David Grieve Date: 2013-09-24 11:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ac217689464d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: dbcbfaf3abb4 Author: jgiles Date: 2013-09-25 10:01 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dbcbfaf3abb4 RT-32908: Scrolling mousewheel quickly with virtualised controls can result in incorrect layout of cells Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: a1c13e1ce899 Author: psomashe Date: 2013-09-24 15:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a1c13e1ce899 RT-32996 MenuButton text should be left aligned. reviewed by Jonathan. ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 26e00f0c1674 Author: jgiles Date: 2013-09-25 11:28 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/26e00f0c1674 RT-33148: Allow ComboBox subclasses to disable autohide when the ListView popup is clicked Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 35ed95c6f4ed Author: jgiles Date: 2013-09-25 11:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/35ed95c6f4ed [DOC ONLY] RT-32182: Incorrect Javadoc for TitledPane ! modules/controls/src/main/java/javafx/scene/control/TitledPane.java Changeset: d61aca2e2f9b Author: jgiles Date: 2013-09-25 12:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d61aca2e2f9b RT-25059: ListView scroll bar thumb resizes wildly Contributed-by: rbair Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java ! modules/controls/src/test/java/javafx/scene/control/ListViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java Changeset: b97f4a5bcfb2 Author: jgiles Date: 2013-09-25 15:06 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b97f4a5bcfb2 RT-33150: NPE in Ensemble 8 app when scrolling main screen with mouse wheel Cell culling was occurring slightly too early, leading to blank spots in the virtualised controls. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 8a99b06d9c22 Author: David Grieve Date: 2013-09-25 15:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8a99b06d9c22 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: d67eca687eef Author: jgiles Date: 2013-09-26 10:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d67eca687eef Backed out changeset d61aca2e2f9b (Fix for RT-25059) as it introduced RT-33172: 8.0-controls-scrum-849: up to 40% performance regression in Controls.ListView and Controls.TreeView benchmarks ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java ! modules/controls/src/test/java/javafx/scene/control/ListViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java Changeset: acf01d7fdc73 Author: jgiles Date: 2013-09-26 14:08 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/acf01d7fdc73 RT-33101: Unable to collapse/expand tree item by mouse click Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java Changeset: 240636b0c18c Author: jgiles Date: 2013-09-26 14:14 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/240636b0c18c RT-27447: [TableView] [TreeTableView] When multiple cells are selected in horizontal direction, control doesn't scroll to tle last selected item. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java Changeset: 4d3df4e0c494 Author: mickf Date: 2013-09-27 16:11 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4d3df4e0c494 RT-32966 : Multiline text is rendered outside of control bounds, reviewed by Leif ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: bdc3f404c931 Author: leifs Date: 2013-09-27 11:15 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bdc3f404c931 RT-33075: [DatePicker] Fix issues in Caspian CSS Reviewed-by: jdinga ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 62e08c34a629 Author: David Grieve Date: 2013-09-30 14:52 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/62e08c34a629 RT-31168: reset CssFlag to clean so css will be reapplied if the node is added back later. + modules/controls/src/test/java/javafx/scene/control/MiscellaneousTests.java ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: 88a48547ab6c Author: jgiles Date: 2013-09-27 14:07 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/88a48547ab6c RT-32592: CSS: Table header render is incorrectly when set style "-fx-border-*" from Platform.runLater Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 42e0d1d0e0a5 Author: jgiles Date: 2013-09-30 09:38 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/42e0d1d0e0a5 RT-25375: CSS : shadow not visible on ProgressBar, TitledPane,TabPane This patch only resolves the remaining issue in TitledPane - the issue is no longer reproducible for ProgressBar or TabPane. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: d3f0a56c635c Author: jgiles Date: 2013-09-30 13:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d3f0a56c635c RT-26604: [TreeView] ctrl shift down doesn't make visible area to follow the selection. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java Changeset: e0f5c9318547 Author: jgiles Date: 2013-09-30 14:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e0f5c9318547 RT-25484: [TableView, TreeTableView] pageUp/pageDown and ctrl+pageDown/pageUp navigates to the partly visible line. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 2c2b8f13d1cb Author: leifs Date: 2013-09-30 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2c2b8f13d1cb RT-26861: RTL orientation, ColorPicker palette position issue. Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 5475dfc3d98a Author: mickf Date: 2013-10-01 13:13 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5475dfc3d98a RT-30206 : [Button] default and cancel accelerator removing is implemented incorrectly in behavior set to false, reviewed by Leif ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ButtonSkin.java Changeset: 5a67a3c94fee Author: mickf Date: 2013-10-01 14:38 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5a67a3c94fee RT-29334 : Split pane doesn't change its rendering after items has changed order, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java Changeset: 8319071566e7 Author: mickf Date: 2013-10-01 14:57 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8319071566e7 RT-32380 - ScrollPane: Content does not scroll using keyboard, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java Changeset: 6039c1e69ed7 Author: David Grieve Date: 2013-10-01 10:00 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6039c1e69ed7 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 69bd8e6330ac Author: dmasada Date: 2013-09-24 14:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/69bd8e6330ac RT-33105 Ensemble8: OvservableList has inaccurate description ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/language/collections/observablelist/ObservableListApp.java Changeset: fa7e3cbe1ded Author: dmasada Date: 2013-09-24 14:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fa7e3cbe1ded DukePad: add gradle script (assumes local jars) + apps/experiments/DukePad/build.gradle + apps/experiments/DukePad/settings.gradle Changeset: 15579a6ca5b8 Author: flar Date: 2013-09-24 23:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/15579a6ca5b8 Fix RT-28459: Exception in LinearGradient on J2D pipeline when endpoints are coincident Reviewed by: kcr ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java Changeset: e5e4a26f2a09 Author: Petr Pchelko Date: 2013-09-25 12:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e5e4a26f2a09 RT-32699: NPE on changing resolutions with sw pipeline Reviewed-by: anthony, zvegintsev, flar ! modules/graphics/src/main/java/com/sun/glass/ui/Screen.java ! modules/graphics/src/main/java/com/sun/glass/ui/Window.java ! modules/graphics/src/main/native-glass/gtk/GlassApplication.cpp ! modules/graphics/src/main/native-glass/gtk/glass_general.cpp ! modules/graphics/src/main/native-glass/gtk/glass_general.h + modules/graphics/src/main/native-glass/gtk/glass_screen.cpp + modules/graphics/src/main/native-glass/gtk/glass_screen.h ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp ! modules/graphics/src/main/native-glass/ios/GlassApplication.m ! modules/graphics/src/main/native-glass/mac/GlassScreen.h ! modules/graphics/src/main/native-glass/mac/GlassScreen.m ! modules/graphics/src/main/native-glass/mac/GlassWindow+Java.m ! modules/graphics/src/main/native-glass/mac/GlassWindow.m ! modules/graphics/src/main/native-glass/win/GlassScreen.cpp ! modules/graphics/src/main/native-glass/win/GlassScreen.h ! modules/graphics/src/main/native-glass/win/GlassWindow.cpp Changeset: d7772ae23f15 Author: Yao Wang Date: 2013-09-25 10:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d7772ae23f15 RT-30264 3D shapes' getBoundsInLocal() fail to update when dimension changes Summary: When invalidate dimension property, it should call impl_geomChanged() to mark bounds dirty. Reviewed-by: kcr ! modules/graphics/src/main/java/javafx/scene/shape/Box.java ! modules/graphics/src/main/java/javafx/scene/shape/Cylinder.java ! modules/graphics/src/main/java/javafx/scene/shape/Sphere.java Changeset: ca4cca436907 Author: dmasada Date: 2013-09-26 10:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ca4cca436907 RT-30410 Ensemble8: 3D Cubes looks very strange ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/cube/CubeApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/cubesystem/CubeSystemApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/simple3dbox/Simple3DBoxApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/xylophone/XylophoneApp.java Changeset: 1ee95ccfc4f9 Author: dmasada Date: 2013-09-26 13:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1ee95ccfc4f9 RT-33027 Modena.jar: can't switch RadioButton 1 and RadioButton 2 [consistently] ! apps/experiments/Modena/src/main/java/modena/SimpleWindowPage.java ! apps/experiments/Modena/src/main/resources/modena/simple-window.fxml Changeset: 145c3b420819 Author: snorthov Date: 2013-09-26 17:57 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/145c3b420819 RT-33147: 8.0-b107: performance logger is broken Summary: The problem was that the sun.perflog is a String, not a boolean Reviewed-by: kcr ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PerformanceTrackerHelper.java ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java Changeset: 5137e3d135ee Author: rbair Date: 2013-09-26 16:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5137e3d135ee RT-33015: Unit test failures in controls *test_rt21375_scenario* Reviewed-by: jgiles ! modules/controls/src/test/java/javafx/scene/control/ListViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 0f199384c1d6 Author: Felipe Heidrich Date: 2013-09-27 09:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0f199384c1d6 RT-30863: Nodes that is cached with cacheHint SPEED doesn't draw ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/CacheFilter.java Changeset: c368675b0728 Author: Felipe Heidrich Date: 2013-09-27 09:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c368675b0728 RT-31536: Some websites are rendered poorly ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java Changeset: 4f279342c9b3 Author: Felipe Heidrich Date: 2013-09-27 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4f279342c9b3 RT-32705: TextField/TextArea: on Windows, ArrayIndexOutOfBoundsException for complex Thai characters. ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/JFXTextRenderer.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/OS.java ! modules/graphics/src/main/native-font/directwrite.cpp Changeset: d8f1608ffe71 Author: Felipe Heidrich Date: 2013-09-27 11:25 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d8f1608ffe71 RT-32255 [mac only] ! modules/graphics/src/main/java/com/sun/javafx/font/CompositeStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontStrike.java - modules/graphics/src/main/java/com/sun/javafx/font/coretext/CFRange.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/OS.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/main/native-font/coretext.c Changeset: 817ffac6c818 Author: rbair Date: 2013-09-27 14:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/817ffac6c818 RT-33235: Remove unused code in com.sun.javafx.Utils ! modules/graphics/src/main/java/com/sun/javafx/Utils.java Changeset: d29c1c555d01 Author: rbair Date: 2013-09-27 15:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d29c1c555d01 RT-33041: ScheduledService lastValueProperty() is missing generics Reviewed-by: jgiles ! modules/graphics/src/main/java/javafx/concurrent/ScheduledService.java Changeset: 1a55aa923188 Author: rbair Date: 2013-09-27 16:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1a55aa923188 [TEST ONLY] RT-30173: Possible race condition in javafx.concurrent implementation or unit tests ! modules/graphics/src/main/java/javafx/concurrent/ScheduledService.java ! modules/graphics/src/main/java/javafx/concurrent/Service.java ! modules/graphics/src/main/java/javafx/concurrent/Task.java ! modules/graphics/src/test/java/javafx/concurrent/ScheduledServiceTest.java ! modules/graphics/src/test/java/javafx/concurrent/ServiceLifecycleTest.java Changeset: cc58b4072446 Author: mo.chicharro Date: 2013-09-27 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cc58b4072446 Changed Modena app css paths to match new repository locations ! apps/experiments/Modena/src/main/java/modena/Modena.java Changeset: aa2b54350f69 Author: dmasada Date: 2013-09-27 16:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/aa2b54350f69 RT-31427 Ensemble8: [Cursor sample content overlaps description area] ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/events/cursor/CursorApp.java Changeset: e9eb2ae5945d Author: Chien Yang Date: 2013-09-28 09:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e9eb2ae5945d Fix to RT-28138: FX crash on linux using launcher Reviewed-by: Kevin Rushforth, Felipe Heidrich ! modules/graphics/src/main/native-prism-es2/x11/X11GLFactory.c Changeset: a903be4a8453 Author: Seeon Birger Date: 2013-09-29 12:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a903be4a8453 RT-33125: [Virtual Keyboard] Keys layout need to be uniform on all VK types ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/NumericBoard.txt ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/TextBoard.txt ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/UrlBoard.txt ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/images/backspace-icon.png Changeset: 0148423079ac Author: Lubomir Nerad Date: 2013-09-30 14:09 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0148423079ac Reverted accidental part of fix for RT-29891 ! modules/graphics/src/main/java/com/sun/javafx/stage/PopupWindowPeerListener.java Changeset: af515f1eeb5d Author: tb115823 Date: 2013-09-30 15:55 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/af515f1eeb5d Android: Use lens multitouch and gestures support. ! modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java ! modules/graphics/src/main/native-glass/lens/android/android.c ! modules/graphics/src/main/native-glass/lens/android/android.h ! modules/graphics/src/main/native-glass/lens/android/com_oracle_dalvik_FXActivity.h ! modules/graphics/src/main/native-glass/lens/android/com_oracle_dalvik_FXActivity_InternalSurfaceView.h ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.h Changeset: a984a34eca51 Author: rbair Date: 2013-09-30 14:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a984a34eca51 [DOC ONLY] RT-31687: Some concurrent package classes have empty javadocs Partial fix ! modules/graphics/src/main/java/javafx/concurrent/WorkerStateEvent.java Changeset: 50c8083b3df6 Author: Felipe Heidrich Date: 2013-09-30 19:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/50c8083b3df6 RT-33194: Wrapping width affects not always ! modules/graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java Changeset: d049142f7145 Author: Martin Sladecek Date: 2013-10-01 09:50 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d049142f7145 RT-32415 NullPointerException when using fx:include Reviewed-by: ekrejcir ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java Changeset: 105b4c1ce770 Author: Pavel Safrata Date: 2013-10-01 10:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/105b4c1ce770 RT-30637: used proper near/far clipping planes for default perspective camera. ! apps/toys/FX8-3DFeatures/src/fx83dfeatures/NearAndFarClipTest.java ! modules/graphics/src/main/java/com/sun/javafx/geom/PickRay.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/PerspectiveCamera.java ! modules/graphics/src/test/java/javafx/scene/Mouse3DTest.java Changeset: cd993475e253 Author: Martin Sladecek Date: 2013-10-01 15:46 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cd993475e253 RT-33092 GridPane column with Hgrow should be able to grow above children max width Reviewed-by: ekrejcir ! modules/graphics/src/main/java/javafx/scene/layout/GridPane.java ! modules/graphics/src/test/java/javafx/scene/layout/GridPaneTest.java Changeset: fb7da215b220 Author: Martin Sladecek Date: 2013-10-01 15:48 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fb7da215b220 RT-33092 (cont.) [variable rename] ! modules/graphics/src/main/java/javafx/scene/layout/GridPane.java Changeset: 604ebe0585ea Author: Eva Krejcirova Date: 2013-10-01 15:02 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/604ebe0585ea [DOC-ONLY] RT-32979: Example of boundsInParent & boundsInLocal in javafx.scene.Node documentation is confusing - modules/graphics/src/main/docs/javafx/scene/doc-files/bounds-complex.png + modules/graphics/src/main/docs/javafx/scene/doc-files/boundsLocal.png + modules/graphics/src/main/docs/javafx/scene/doc-files/boundsParent.png ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: ac845cbafb49 Author: art Date: 2013-10-01 19:52 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ac845cbafb49 RT-27540: Swing application with JFXPanel does not terminate properly RT-21404: JFXPanel: If Platform implicitExit flag is false when the last window exits, setting it back to true will have no effect Reviewed-by: Kevin Rushforth ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java ! modules/swing/src/main/java/javafx/embed/swing/JFXPanel.java ! tests/system/src/test/java/com/sun/javafx/application/SwingExitCommon.java ! tests/system/src/test/java/com/sun/javafx/application/SwingExitExplicit2Test.java + tests/system/src/test/java/com/sun/javafx/application/SwingNoExit.java Changeset: 0eb503d2b567 Author: jgodinez Date: 2013-10-01 10:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0eb503d2b567 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/graphics/src/main/docs/javafx/scene/doc-files/bounds-complex.png - modules/graphics/src/main/java/com/sun/javafx/font/coretext/CFRange.java ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: 085053c47663 Author: hudson Date: 2013-10-03 08:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/085053c47663 Added tag 8.0-b110 for changeset 0eb503d2b567 ! .hgtags From hang.vo at oracle.com Thu Oct 3 11:04:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 18:04:06 +0000 Subject: hg: openjfx/8/graphics/rt: RT-20391: Mnemonic-parsing with special characters Message-ID: <20131003180459.9C7DD62D13@hg.openjdk.java.net> Changeset: 8b1a40fed5c8 Author: leifs Date: 2013-10-03 10:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8b1a40fed5c8 RT-20391: Mnemonic-parsing with special characters Reviewed-by: mickf ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/ButtonSkinTest.java From petr.pchelko at oracle.com Thu Oct 3 11:24:26 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 3 Oct 2013 22:24:26 +0400 Subject: Default methods in JFX-8 Message-ID: Hello, OpenJFX Community. There's a question about using Java 8 features in FX. I've been working on the support for InputMethods in JFXPanel which is an important feature for many users who speak hieroglyphic languages. The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 In order to have a high-quality support we need to change javafx.scene.input.InputMethodRequests interface and introduce 3 new methods. This is not needed for pure FX applications right now, but absolutely required for InputMethods in the JFXPanel. However, the interface is public and it was present since FX2.0, so changing it would become a breaking change. So the only way to avoid the problem is using the default methods. Those would return some stub values, the JDK is OK with that, as it would not crash or throw exceptions, but text composition would not work correctly. I know that we want to avoid using the Java 8 features in the JFX-8, so I wanted to ask - is it OK to use the default methods here? Here's the questioned API: /** * Returns the offset of the return position in the committed text contained in the text editing node */ default int getInsertPositionOffset() { return 0;} /** * Gets the entire text contained in the text editing node except the uncommitted text. */ default String getCommitedText(int begin, int end) {return "";} /** * Gets the length of the entire text contained in the text editing node */ default int getCommitedTextLength() {return 0;} Thank you. With best regards. Petr. From richard.bair at oracle.com Thu Oct 3 13:00:32 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 3 Oct 2013 13:00:32 -0700 Subject: Default methods in JFX-8 In-Reply-To: References: Message-ID: <41D96753-3289-4866-9E55-59AFF04D9C25@oracle.com> I don't think returning 0 from getInsertPositionOffset() or getCommittedTextLength() is correct, because 0 is a legitimate value to return from those methods when they're working correctly. How do you distinguish between a legitimate value of 0, and an illegitimate one? It seems rather that the defaults could be -1 and null, and that code calling these methods would understand these values to mean "not implemented" and deal accordingly. I'm thinking here of 3rd party code that calls methods on InputMethodRequest. Initially of course they won't be calling these new methods, so no change in behavior for them. However once they start calling these methods, they may need to be able to distinguish between an implementor that fully implements InputMethodRequests, and one that doesn't. It seems like the successful uses of default methods have been when adding some method that could be implemented in terms of the existing API on the interface, such that it fits seamlessly into the existing interface as though it were always there, and where an implementor could create a more efficient implementation of the method, but doesn't really have to. In this case it seems like these methods really won't fit well into the existing interface. I don't know enough about the domain to know what other options you have, besides adding InputMethodRequests2 or whatever and having to do an instanceof test and cast. But that might actually be the better way to handle this situation. What code needs to call these new methods? Richard On Oct 3, 2013, at 11:24 AM, Petr Pchelko wrote: > Hello, OpenJFX Community. > > There's a question about using Java 8 features in FX. > > I've been working on the support for InputMethods in JFXPanel which is an important feature for many users who speak hieroglyphic languages. > The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 > > In order to have a high-quality support we need to change javafx.scene.input.InputMethodRequests interface and introduce 3 new methods. This is not needed for pure FX applications right now, but absolutely required for InputMethods in the JFXPanel. However, the interface is public and it was present since FX2.0, so changing it would become a breaking change. So the only way to avoid the problem is using the default methods. Those would return some stub values, the JDK is OK with that, as it would not crash or throw exceptions, but text composition would not work correctly. > > I know that we want to avoid using the Java 8 features in the JFX-8, so I wanted to ask - is it OK to use the default methods here? > > Here's the questioned API: > > /** > * Returns the offset of the return position in the committed text contained in the text editing node > */ > default int getInsertPositionOffset() { return 0;} > > /** > * Gets the entire text contained in the text editing node except the uncommitted text. > */ > default String getCommitedText(int begin, int end) {return "";} > > /** > * Gets the length of the entire text contained in the text editing node > */ > default int getCommitedTextLength() {return 0;} > > Thank you. > With best regards. Petr. > From petr.pchelko at oracle.com Thu Oct 3 13:14:55 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Oct 2013 00:14:55 +0400 Subject: Default methods in JFX-8 In-Reply-To: <41D96753-3289-4866-9E55-59AFF04D9C25@oracle.com> References: <41D96753-3289-4866-9E55-59AFF04D9C25@oracle.com> Message-ID: <9900EB06-5CCE-47AC-AC36-F77094619500@oracle.com> Hello, Richard. Thank you. > What code needs to call these new methods? These are used in the JFXPanel to provide the needed information to the AWT/Swing, so that it could properly position the text composition window and track what is going on with the text. > I don't know enough about the domain to know what other options you have, besides adding InputMethodRequests2 or whatever and having to do an instanceof test and cast. But that might actually be the better way to handle this situation We could add some internal extension of the interface and use instanceof checks. It would be done in a single place and would not make a lot of harm. The only problem with this approach is that third-party text-input component would not be able to support IM inside the JFXPanel. So, if you think JFXPanel does not worth adding new public API which is not required by FX itself I could try to reimplement the feature using some internal extension. With best regards. Petr. On Oct 4, 2013, at 12:00 AM, Richard Bair wrote: > I don't think returning 0 from getInsertPositionOffset() or getCommittedTextLength() is correct, because 0 is a legitimate value to return from those methods when they're working correctly. How do you distinguish between a legitimate value of 0, and an illegitimate one? It seems rather that the defaults could be -1 and null, and that code calling these methods would understand these values to mean "not implemented" and deal accordingly. > > I'm thinking here of 3rd party code that calls methods on InputMethodRequest. Initially of course they won't be calling these new methods, so no change in behavior for them. However once they start calling these methods, they may need to be able to distinguish between an implementor that fully implements InputMethodRequests, and one that doesn't. > > It seems like the successful uses of default methods have been when adding some method that could be implemented in terms of the existing API on the interface, such that it fits seamlessly into the existing interface as though it were always there, and where an implementor could create a more efficient implementation of the method, but doesn't really have to. In this case it seems like these methods really won't fit well into the existing interface. I don't know enough about the domain to know what other options you have, besides adding InputMethodRequests2 or whatever and having to do an instanceof test and cast. But that might actually be the better way to handle this situation. What code needs to call these new methods? > > Richard > > On Oct 3, 2013, at 11:24 AM, Petr Pchelko wrote: > >> Hello, OpenJFX Community. >> >> There's a question about using Java 8 features in FX. >> >> I've been working on the support for InputMethods in JFXPanel which is an important feature for many users who speak hieroglyphic languages. >> The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 >> >> In order to have a high-quality support we need to change javafx.scene.input.InputMethodRequests interface and introduce 3 new methods. This is not needed for pure FX applications right now, but absolutely required for InputMethods in the JFXPanel. However, the interface is public and it was present since FX2.0, so changing it would become a breaking change. So the only way to avoid the problem is using the default methods. Those would return some stub values, the JDK is OK with that, as it would not crash or throw exceptions, but text composition would not work correctly. >> >> I know that we want to avoid using the Java 8 features in the JFX-8, so I wanted to ask - is it OK to use the default methods here? >> >> Here's the questioned API: >> >> /** >> * Returns the offset of the return position in the committed text contained in the text editing node >> */ >> default int getInsertPositionOffset() { return 0;} >> >> /** >> * Gets the entire text contained in the text editing node except the uncommitted text. >> */ >> default String getCommitedText(int begin, int end) {return "";} >> >> /** >> * Gets the length of the entire text contained in the text editing node >> */ >> default int getCommitedTextLength() {return 0;} >> >> Thank you. >> With best regards. Petr. >> > From danno.ferrin at shemnon.com Thu Oct 3 13:39:21 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Thu, 3 Oct 2013 14:39:21 -0600 Subject: Default methods in JFX-8 In-Reply-To: References: Message-ID: On Thu, Oct 3, 2013 at 12:24 PM, Petr Pchelko wrote: > Hello, OpenJFX Community. > > There's a question about using Java 8 features in FX. > > I've been working on the support for InputMethods in JFXPanel which is an > important feature for many users who speak hieroglyphic languages. > The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 > > In order to have a high-quality support we need to change > javafx.scene.input.InputMethodRequests interface and introduce 3 new > methods. This is not needed for pure FX applications right now, but > absolutely required for InputMethods in the JFXPanel. However, the > interface is public and it was present since FX2.0, so changing it would > become a breaking change. So the only way to avoid the problem is using the > default methods. Those would return some stub values, the JDK is OK with > that, as it would not crash or throw exceptions, but text composition would > not work correctly. > > I know that we want to avoid using the Java 8 features in the JFX-8, so I > wanted to ask - is it OK to use the default methods here? > > If you are staying away from JDK8 features for the JFX78 backport, don't worry. There are more issues with new JDK8 APIs than with the new language features. For example there were default methods put into some collections classes that we solved by pushing them down to the first implements. But the Date and Time picker depends on the new time package. The threeten backport won't be updated until after 8 ships, so that has been removed so far. I'de be interested to know what a wholesale lamdaization would result in speed wise and code size wise (both source and compiled). From what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the backport more of a busy work proposition. If there were performance gains it would also make a great front page story in the next java magazine or a case study.. From richard.bair at oracle.com Thu Oct 3 13:45:22 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 3 Oct 2013 13:45:22 -0700 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: Message-ID: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> > Hello, OpenJFX Community. > > There's a question about using Java 8 features in FX. > > I've been working on the support for InputMethods in JFXPanel which is an important feature for many users who speak hieroglyphic languages. > The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 > > In order to have a high-quality support we need to change javafx.scene.input.InputMethodRequests interface and introduce 3 new methods. This is not needed for pure FX applications right now, but absolutely required for InputMethods in the JFXPanel. However, the interface is public and it was present since FX2.0, so changing it would become a breaking change. So the only way to avoid the problem is using the default methods. Those would return some stub values, the JDK is OK with that, as it would not crash or throw exceptions, but text composition would not work correctly. > > I know that we want to avoid using the Java 8 features in the JFX-8, so I wanted to ask - is it OK to use the default methods here? > > > If you are staying away from JDK8 features for the JFX78 backport, don't worry. There are more issues with new JDK8 APIs than with the new language features. > > For example there were default methods put into some collections classes that we solved by pushing them down to the first implements. But the Date and Time picker depends on the new time package. The threeten backport won't be updated until after 8 ships, so that has been removed so far. > > I'de be interested to know what a wholesale lamdaization would result in speed wise and code size wise (both source and compiled). From what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the backport more of a busy work proposition. If there were performance gains it would also make a great front page story in the next java magazine or a case study.. After having used Lambda's for JavaOne, I'd love to make the conversion, even if in the end the performance was the same, because the savings in noise in the Java files is so big. At one time I just took the concurrent classes and lambda-ized them to measure the impact on those classes. You could maybe pick a package and just lambda-ize that one package and see what happens in terms of size reduction. We might see: + A reduction in the overall class size (not pack-200'd) - An increase in startup time (have to spin up synthetic classes created at usage time) +/- And increase or decrease in performance + A decrease in source code It would be interesting to get some data for these points and see what effect lambda's have. Especially if an IDE can just do it in bulk? Richard From richard.bair at oracle.com Thu Oct 3 13:48:08 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 3 Oct 2013 13:48:08 -0700 Subject: Default methods in JFX-8 In-Reply-To: <9900EB06-5CCE-47AC-AC36-F77094619500@oracle.com> References: <41D96753-3289-4866-9E55-59AFF04D9C25@oracle.com> <9900EB06-5CCE-47AC-AC36-F77094619500@oracle.com> Message-ID: >> What code needs to call these new methods? > > These are used in the JFXPanel to provide the needed information to the AWT/Swing, so that it could properly position the text composition window and track what is going on with the text. > >> I don't know enough about the domain to know what other options you have, besides adding InputMethodRequests2 or whatever and having to do an instanceof test and cast. But that might actually be the better way to handle this situation > We could add some internal extension of the interface and use instanceof checks. It would be done in a single place and would not make a lot of harm. > The only problem with this approach is that third-party text-input component would not be able to support IM inside the JFXPanel. I'm not sure there are any 3rd party text input controls that don't extend from TextInputControl. If a 3rd party text input control does extend from TextInputControl / TextInputControlSkin, will it work? If we use an internal interface, will this fact "leak" through the public API? That is, if I enumerated the hierarchy of a public API member, will I see this non-public interface somewhere on it? Or is the only way to get a hold of some internal object and cast it? I'm wondering if we can punt on the problem until somebody encounters it, and in the meantime just use a private interface. Thanks Richard From herve.girod at gmail.com Thu Oct 3 13:48:33 2013 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Thu, 3 Oct 2013 22:48:33 +0200 Subject: Default methods in JFX-8 In-Reply-To: References: Message-ID: <7B7567A7-365E-48EC-BB5D-E85C317BD4E3@gmail.com> There are already obvious and potentially huge performance gain when using parallel, even now. Sent from my iPhone > On 3 oct. 2013, at 22:39, Danno Ferrin wrote: > > On Thu, Oct 3, 2013 at 12:24 PM, Petr Pchelko wrote: > >> Hello, OpenJFX Community. >> >> There's a question about using Java 8 features in FX. >> >> I've been working on the support for InputMethods in JFXPanel which is an >> important feature for many users who speak hieroglyphic languages. >> The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 >> >> In order to have a high-quality support we need to change >> javafx.scene.input.InputMethodRequests interface and introduce 3 new >> methods. This is not needed for pure FX applications right now, but >> absolutely required for InputMethods in the JFXPanel. However, the >> interface is public and it was present since FX2.0, so changing it would >> become a breaking change. So the only way to avoid the problem is using the >> default methods. Those would return some stub values, the JDK is OK with >> that, as it would not crash or throw exceptions, but text composition would >> not work correctly. >> >> I know that we want to avoid using the Java 8 features in the JFX-8, so I >> wanted to ask - is it OK to use the default methods here? > If you are staying away from JDK8 features for the JFX78 backport, don't > worry. There are more issues with new JDK8 APIs than with the new language > features. > > For example there were default methods put into some collections classes > that we solved by pushing them down to the first implements. But the Date > and Time picker depends on the new time package. The threeten backport > won't be updated until after 8 ships, so that has been removed so far. > > I'de be interested to know what a wholesale lamdaization would result in > speed wise and code size wise (both source and compiled). From what I can > tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the > backport more of a busy work proposition. If there were performance gains > it would also make a great front page story in the next java magazine or a > case study.. From hang.vo at oracle.com Thu Oct 3 13:48:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 20:48:39 +0000 Subject: hg: openjfx/8/graphics/rt: 4 new changesets Message-ID: <20131003205013.7EAF762D37@hg.openjdk.java.net> Changeset: 4f55a53bfabd Author: Felipe Heidrich Date: 2013-10-03 09:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4f55a53bfabd RT-32255 [linux only] ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTGlyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/PangoFactory.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/PangoGlyphLayout.java ! modules/graphics/src/main/native-font/freetype.c Changeset: 50b282551554 Author: jgiles Date: 2013-10-03 11:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50b282551554 [TEST ONLY] RT-30739: UNIT-TEST: test_rt29930 failures in Controls unit tests. Fixing and re-enabling tests related to RT-29930. ! modules/controls/src/test/java/javafx/scene/control/ListViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 006b0519158b Author: jgiles Date: 2013-10-03 12:50 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/006b0519158b RT-29320: ChoiceBoxTableCell ChoiceBox does not use TableCell's StringConverter ! modules/controls/src/main/java/javafx/scene/control/cell/CellUtils.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxListCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxListCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeTableCell.java ! modules/controls/src/test/java/javafx/scene/control/cell/ChoiceBoxListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ChoiceBoxTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ChoiceBoxTreeCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ChoiceBoxTreeTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ComboBoxListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ComboBoxTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ComboBoxTreeCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ComboBoxTreeTableCellTest.java Changeset: a217f67b7af6 Author: jgiles Date: 2013-10-03 13:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a217f67b7af6 RT-27177: [TreeTableView] ctrl+shift+up/down don't make scrolling. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java From petr.pchelko at oracle.com Thu Oct 3 13:54:31 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Oct 2013 00:54:31 +0400 Subject: Default methods in JFX-8 In-Reply-To: References: <41D96753-3289-4866-9E55-59AFF04D9C25@oracle.com> <9900EB06-5CCE-47AC-AC36-F77094619500@oracle.com> Message-ID: <5D78342C-8DA2-468E-899E-5B09BDEDC9B6@oracle.com> > I'm not sure there are any 3rd party text input controls that don't extend from TextInputControl. If a 3rd party text input control does extend from TextInputControl / TextInputControlSkin, will it work? I'm suppose it should work, but this question requires deeper investigation. > If we use an internal interface, will this fact "leak" through the public API? That is, if I enumerated the hierarchy of a public API member, will I see this non-public interface somewhere on it? No. It would be absolutely internal. All the public APIs would still return and take InputMethodRequests interface. Just TextInputControl and WebView would implement an internal extended version and we will typecast it to the extended version inside JFXPanel. > I'm wondering if we can punt on the problem until somebody encounters it, and in the meantime just use a private interface. I agree. I will change the fix than. Thank you. With best regards. Petr. On Oct 4, 2013, at 12:48 AM, Richard Bair wrote: >>> What code needs to call these new methods? >> >> These are used in the JFXPanel to provide the needed information to the AWT/Swing, so that it could properly position the text composition window and track what is going on with the text. >> >>> I don't know enough about the domain to know what other options you have, besides adding InputMethodRequests2 or whatever and having to do an instanceof test and cast. But that might actually be the better way to handle this situation >> We could add some internal extension of the interface and use instanceof checks. It would be done in a single place and would not make a lot of harm. >> The only problem with this approach is that third-party text-input component would not be able to support IM inside the JFXPanel. > > I'm not sure there are any 3rd party text input controls that don't extend from TextInputControl. If a 3rd party text input control does extend from TextInputControl / TextInputControlSkin, will it work? > > If we use an internal interface, will this fact "leak" through the public API? That is, if I enumerated the hierarchy of a public API member, will I see this non-public interface somewhere on it? Or is the only way to get a hold of some internal object and cast it? > > I'm wondering if we can punt on the problem until somebody encounters it, and in the meantime just use a private interface. > > Thanks > Richard From hang.vo at oracle.com Thu Oct 3 14:03:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 03 Oct 2013 21:03:47 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33300: AIOOBE in DWGlyphLayout Message-ID: <20131003210422.F414F62D40@hg.openjdk.java.net> Changeset: 40bfec414944 Author: Felipe Heidrich Date: 2013-10-03 13:46 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/40bfec414944 RT-33300: AIOOBE in DWGlyphLayout Reviewed-by: Philip Race ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/JFXTextRenderer.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/OS.java ! modules/graphics/src/main/native-font/directwrite.cpp From sven.reimers at gmail.com Thu Oct 3 14:16:14 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 3 Oct 2013 23:16:14 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> Message-ID: You can do this using NetBeans 7.4 RC 2 - select Inspect and Transform and go hunting for "Use Lambda"... I tried it on a legacy codebase and it worked out of the box without any problems. -Sven On Thu, Oct 3, 2013 at 10:45 PM, Richard Bair wrote: > > Hello, OpenJFX Community. > > > > There's a question about using Java 8 features in FX. > > > > I've been working on the support for InputMethods in JFXPanel which is > an important feature for many users who speak hieroglyphic languages. > > The issue is tracked under: > https://javafx-jira.kenai.com/browse/RT-13248 > > > > In order to have a high-quality support we need to change > javafx.scene.input.InputMethodRequests interface and introduce 3 new > methods. This is not needed for pure FX applications right now, but > absolutely required for InputMethods in the JFXPanel. However, the > interface is public and it was present since FX2.0, so changing it would > become a breaking change. So the only way to avoid the problem is using the > default methods. Those would return some stub values, the JDK is OK with > that, as it would not crash or throw exceptions, but text composition would > not work correctly. > > > > I know that we want to avoid using the Java 8 features in the JFX-8, so > I wanted to ask - is it OK to use the default methods here? > > > > > > If you are staying away from JDK8 features for the JFX78 backport, don't > worry. There are more issues with new JDK8 APIs than with the new language > features. > > > > For example there were default methods put into some collections classes > that we solved by pushing them down to the first implements. But the Date > and Time picker depends on the new time package. The threeten backport > won't be updated until after 8 ships, so that has been removed so far. > > > > I'de be interested to know what a wholesale lamdaization would result in > speed wise and code size wise (both source and compiled). From what I can > tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the > backport more of a busy work proposition. If there were performance gains > it would also make a great front page story in the next java magazine or a > case study.. > > After having used Lambda's for JavaOne, I'd love to make the conversion, > even if in the end the performance was the same, because the savings in > noise in the Java files is so big. At one time I just took the concurrent > classes and lambda-ized them to measure the impact on those classes. You > could maybe pick a package and just lambda-ize that one package and see > what happens in terms of size reduction. We might see: > > + A reduction in the overall class size (not pack-200'd) > - An increase in startup time (have to spin up synthetic classes > created at usage time) > +/- And increase or decrease in performance > + A decrease in source code > > It would be interesting to get some data for these points and see what > effect lambda's have. Especially if an IDE can just do it in bulk? > > Richard -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From david.grieve at oracle.com Thu Oct 3 15:20:51 2013 From: david.grieve at oracle.com (David Grieve) Date: Thu, 3 Oct 2013 18:20:51 -0400 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> Message-ID: And what about Stream? I like the declarative code that comes from using Stream and I can see places in the code where Stream could be used, but I wonder about its performance relative to iterators and/or enhanced for loops. On Oct 3, 2013, at 4:45 PM, Richard Bair wrote: >> Hello, OpenJFX Community. >> >> There's a question about using Java 8 features in FX. >> >> I've been working on the support for InputMethods in JFXPanel which is an important feature for many users who speak hieroglyphic languages. >> The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 >> >> In order to have a high-quality support we need to change javafx.scene.input.InputMethodRequests interface and introduce 3 new methods. This is not needed for pure FX applications right now, but absolutely required for InputMethods in the JFXPanel. However, the interface is public and it was present since FX2.0, so changing it would become a breaking change. So the only way to avoid the problem is using the default methods. Those would return some stub values, the JDK is OK with that, as it would not crash or throw exceptions, but text composition would not work correctly. >> >> I know that we want to avoid using the Java 8 features in the JFX-8, so I wanted to ask - is it OK to use the default methods here? >> >> >> If you are staying away from JDK8 features for the JFX78 backport, don't worry. There are more issues with new JDK8 APIs than with the new language features. >> >> For example there were default methods put into some collections classes that we solved by pushing them down to the first implements. But the Date and Time picker depends on the new time package. The threeten backport won't be updated until after 8 ships, so that has been removed so far. >> >> I'de be interested to know what a wholesale lamdaization would result in speed wise and code size wise (both source and compiled). From what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the backport more of a busy work proposition. If there were performance gains it would also make a great front page story in the next java magazine or a case study.. > > After having used Lambda's for JavaOne, I'd love to make the conversion, even if in the end the performance was the same, because the savings in noise in the Java files is so big. At one time I just took the concurrent classes and lambda-ized them to measure the impact on those classes. You could maybe pick a package and just lambda-ize that one package and see what happens in terms of size reduction. We might see: > > + A reduction in the overall class size (not pack-200'd) > - An increase in startup time (have to spin up synthetic classes created at usage time) > +/- And increase or decrease in performance > + A decrease in source code > > It would be interesting to get some data for these points and see what effect lambda's have. Especially if an IDE can just do it in bulk? > > Richard From herve.girod at gmail.com Thu Oct 3 15:33:24 2013 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Fri, 4 Oct 2013 00:33:24 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> Message-ID: <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> Here is a nice example, taking advantage of the ease of going parallel. Apparently the performance without parallel will also further improve. http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ Herv? Sent from my iPad > On 4 oct. 2013, at 00:20, David Grieve wrote: > > And what about Stream? I like the declarative code that comes from using Stream and I can see places in the code where Stream could be used, but I wonder about its performance relative to iterators and/or enhanced for loops. > > On Oct 3, 2013, at 4:45 PM, Richard Bair wrote: > >>> Hello, OpenJFX Community. >>> >>> There's a question about using Java 8 features in FX. >>> >>> I've been working on the support for InputMethods in JFXPanel which is an important feature for many users who speak hieroglyphic languages. >>> The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 >>> >>> In order to have a high-quality support we need to change javafx.scene.input.InputMethodRequests interface and introduce 3 new methods. This is not needed for pure FX applications right now, but absolutely required for InputMethods in the JFXPanel. However, the interface is public and it was present since FX2.0, so changing it would become a breaking change. So the only way to avoid the problem is using the default methods. Those would return some stub values, the JDK is OK with that, as it would not crash or throw exceptions, but text composition would not work correctly. >>> >>> I know that we want to avoid using the Java 8 features in the JFX-8, so I wanted to ask - is it OK to use the default methods here? >>> >>> >>> If you are staying away from JDK8 features for the JFX78 backport, don't worry. There are more issues with new JDK8 APIs than with the new language features. >>> >>> For example there were default methods put into some collections classes that we solved by pushing them down to the first implements. But the Date and Time picker depends on the new time package. The threeten backport won't be updated until after 8 ships, so that has been removed so far. >>> >>> I'de be interested to know what a wholesale lamdaization would result in speed wise and code size wise (both source and compiled). From what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the backport more of a busy work proposition. If there were performance gains it would also make a great front page story in the next java magazine or a case study.. >> >> After having used Lambda's for JavaOne, I'd love to make the conversion, even if in the end the performance was the same, because the savings in noise in the Java files is so big. At one time I just took the concurrent classes and lambda-ized them to measure the impact on those classes. You could maybe pick a package and just lambda-ize that one package and see what happens in terms of size reduction. We might see: >> >> + A reduction in the overall class size (not pack-200'd) >> - An increase in startup time (have to spin up synthetic classes created at usage time) >> +/- And increase or decrease in performance >> + A decrease in source code >> >> It would be interesting to get some data for these points and see what effect lambda's have. Especially if an IDE can just do it in bulk? >> >> Richard > From richard.bair at oracle.com Thu Oct 3 16:35:43 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 3 Oct 2013 16:35:43 -0700 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> Message-ID: <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> Brian was telling me at J1 that whether parallel gets you performance or not depends on the size of the collection and the complexity of the work to perform. There is definitely a point at which parallel helps -- and a point at which it hurts. Richard On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: > Here is a nice example, taking advantage of the ease of going parallel. Apparently the performance without parallel will also further improve. http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ > > Herv? > > Sent from my iPad > >> On 4 oct. 2013, at 00:20, David Grieve wrote: >> >> And what about Stream? I like the declarative code that comes from using Stream and I can see places in the code where Stream could be used, but I wonder about its performance relative to iterators and/or enhanced for loops. >> >> On Oct 3, 2013, at 4:45 PM, Richard Bair wrote: >> >>>> Hello, OpenJFX Community. >>>> >>>> There's a question about using Java 8 features in FX. >>>> >>>> I've been working on the support for InputMethods in JFXPanel which is an important feature for many users who speak hieroglyphic languages. >>>> The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 >>>> >>>> In order to have a high-quality support we need to change javafx.scene.input.InputMethodRequests interface and introduce 3 new methods. This is not needed for pure FX applications right now, but absolutely required for InputMethods in the JFXPanel. However, the interface is public and it was present since FX2.0, so changing it would become a breaking change. So the only way to avoid the problem is using the default methods. Those would return some stub values, the JDK is OK with that, as it would not crash or throw exceptions, but text composition would not work correctly. >>>> >>>> I know that we want to avoid using the Java 8 features in the JFX-8, so I wanted to ask - is it OK to use the default methods here? >>>> >>>> >>>> If you are staying away from JDK8 features for the JFX78 backport, don't worry. There are more issues with new JDK8 APIs than with the new language features. >>>> >>>> For example there were default methods put into some collections classes that we solved by pushing them down to the first implements. But the Date and Time picker depends on the new time package. The threeten backport won't be updated until after 8 ships, so that has been removed so far. >>>> >>>> I'de be interested to know what a wholesale lamdaization would result in speed wise and code size wise (both source and compiled). From what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the backport more of a busy work proposition. If there were performance gains it would also make a great front page story in the next java magazine or a case study.. >>> >>> After having used Lambda's for JavaOne, I'd love to make the conversion, even if in the end the performance was the same, because the savings in noise in the Java files is so big. At one time I just took the concurrent classes and lambda-ized them to measure the impact on those classes. You could maybe pick a package and just lambda-ize that one package and see what happens in terms of size reduction. We might see: >>> >>> + A reduction in the overall class size (not pack-200'd) >>> - An increase in startup time (have to spin up synthetic classes created at usage time) >>> +/- And increase or decrease in performance >>> + A decrease in source code >>> >>> It would be interesting to get some data for these points and see what effect lambda's have. Especially if an IDE can just do it in bulk? >>> >>> Richard >> From tbee at tbee.org Thu Oct 3 21:55:27 2013 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 04 Oct 2013 06:55:27 +0200 Subject: bugfix mode Message-ID: <524E4A3F.6030407@tbee.org> Dear JFX team, There are a number of issues in my open source projects with JFX8 that need looking at, but I'm postponing that until JFX8 reaches a level of maturity that will limit the risk on having to redo things, aka that JFX8 is going into bugfix mode, prior to release. Are there any estimates on when that phase will begin? I think I remember a recent mail with that topic. Regards, Tom From hang.vo at oracle.com Thu Oct 3 23:48:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 06:48:56 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131004065033.441BB62D51@hg.openjdk.java.net> Changeset: 17d67b5a5a00 Author: Martin Sladecek Date: 2013-10-04 08:42 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/17d67b5a5a00 RT-33097 NPE when calling FXMLLoader.load() in a background thread Reviewed by: ekrejcir ! modules/fxml/src/main/java/com/sun/javafx/fxml/BeanAdapter.java Changeset: b05c5b6ee71c Author: Martin Sladecek Date: 2013-10-04 08:45 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b05c5b6ee71c RT-28121 FXMLLoader with setTemplate(true) doesn't allow Controller specification in fxml Reviewed by: rbair, ekrejcir ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java From petr.pchelko at oracle.com Fri Oct 4 01:40:07 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Fri, 4 Oct 2013 12:40:07 +0400 Subject: Enabling Glass thread checks Message-ID: Hello, OpenJFX. FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. The following exception would mean that you've hit a thread check: IllegalStateException("This operation is permitted on the event thread only"). In that case please check your threading and if everything seems correct - please contact the Glass team. Thank you. With best regards. Petr. From hang.vo at oracle.com Fri Oct 4 01:48:32 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 08:48:32 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26891: Re-enable glass thread checks by default once depenedent issues are fixed Message-ID: <20131004084951.DA19762D5A@hg.openjdk.java.net> Changeset: b3c81e6a32d0 Author: Petr Pchelko Date: 2013-10-04 12:41 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b3c81e6a32d0 RT-26891: Re-enable glass thread checks by default once depenedent issues are fixed ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java From hang.vo at oracle.com Fri Oct 4 02:04:20 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 09:04:20 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28121 - remove related test files Message-ID: <20131004090530.835E362D5E@hg.openjdk.java.net> Changeset: 7a8c5feb8c49 Author: Martin Sladecek Date: 2013-10-04 10:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7a8c5feb8c49 RT-28121 - remove related test files - modules/fxml/src/test/java/javafx/fxml/RT_23413Test.java - modules/fxml/src/test/resources/javafx/fxml/rt_23413.fxml From vargas.torres.oscar at gmail.com Fri Oct 4 03:59:59 2013 From: vargas.torres.oscar at gmail.com (Oscar Vargas Torres) Date: Fri, 4 Oct 2013 05:59:59 -0500 Subject: Cannot compile following the OpenJFX instructions at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX Message-ID: This is the error I keep getting: http://pastie.org/8377161 I am using Ubuntu Linux 13.04 64 bits. I have installed jdk8 b109 in my machine. I have tried for several hours now. I need some guidance!! What I understand is that I need antlr but the gradle build is not able to find it. Thanks From anthony.petrov at oracle.com Fri Oct 4 04:13:08 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 04 Oct 2013 15:13:08 +0400 Subject: Cannot compile following the OpenJFX instructions at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX In-Reply-To: References: Message-ID: <524EA2C4.5030904@oracle.com> See this: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-October/010592.html -- best regards, Anthony On 10/04/2013 02:59 PM, Oscar Vargas Torres wrote: > This is the error I keep getting: > > http://pastie.org/8377161 > I am using Ubuntu Linux 13.04 64 bits. I have installed jdk8 b109 in my > machine. I have tried for several hours now. I need some guidance!! > > What I understand is that I need antlr but the gradle build is not able to > find it. > > Thanks > From sven.reimers at gmail.com Fri Oct 4 05:05:23 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 4 Oct 2013 14:05:23 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> Message-ID: Ok. Here you go... I just did an inspection run for the controls module and my IDE came up with (drum roll) 888 possible lambda conversions.. Looking through them I discovered that usage of <> (aka diamond syntax) is not used (or at least not used a lot) in at least the controls modules. My IDE showed me 1171 occurrences. Is there a good reason not to use diamonds? Will now try to apply all those changes and figure out if this still builds... up next: go through the other modules... -Sven On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote: > Brian was telling me at J1 that whether parallel gets you performance or > not depends on the size of the collection and the complexity of the work to > perform. There is definitely a point at which parallel helps -- and a point > at which it hurts. > > Richard > > On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: > > > Here is a nice example, taking advantage of the ease of going parallel. > Apparently the performance without parallel will also further improve. > http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ > > > > Herv? > > > > Sent from my iPad > > > >> On 4 oct. 2013, at 00:20, David Grieve wrote: > >> > >> And what about Stream? I like the declarative code that comes from > using Stream and I can see places in the code where Stream could be used, > but I wonder about its performance relative to iterators and/or enhanced > for loops. > >> > >> On Oct 3, 2013, at 4:45 PM, Richard Bair > wrote: > >> > >>>> Hello, OpenJFX Community. > >>>> > >>>> There's a question about using Java 8 features in FX. > >>>> > >>>> I've been working on the support for InputMethods in JFXPanel which > is an important feature for many users who speak hieroglyphic languages. > >>>> The issue is tracked under: > https://javafx-jira.kenai.com/browse/RT-13248 > >>>> > >>>> In order to have a high-quality support we need to change > javafx.scene.input.InputMethodRequests interface and introduce 3 new > methods. This is not needed for pure FX applications right now, but > absolutely required for InputMethods in the JFXPanel. However, the > interface is public and it was present since FX2.0, so changing it would > become a breaking change. So the only way to avoid the problem is using the > default methods. Those would return some stub values, the JDK is OK with > that, as it would not crash or throw exceptions, but text composition would > not work correctly. > >>>> > >>>> I know that we want to avoid using the Java 8 features in the JFX-8, > so I wanted to ask - is it OK to use the default methods here? > >>>> > >>>> > >>>> If you are staying away from JDK8 features for the JFX78 backport, > don't worry. There are more issues with new JDK8 APIs than with the new > language features. > >>>> > >>>> For example there were default methods put into some collections > classes that we solved by pushing them down to the first implements. But > the Date and Time picker depends on the new time package. The threeten > backport won't be updated until after 8 ships, so that has been removed so > far. > >>>> > >>>> I'de be interested to know what a wholesale lamdaization would result > in speed wise and code size wise (both source and compiled). From what I > can tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes > the backport more of a busy work proposition. If there were performance > gains it would also make a great front page story in the next java magazine > or a case study.. > >>> > >>> After having used Lambda's for JavaOne, I'd love to make the > conversion, even if in the end the performance was the same, because the > savings in noise in the Java files is so big. At one time I just took the > concurrent classes and lambda-ized them to measure the impact on those > classes. You could maybe pick a package and just lambda-ize that one > package and see what happens in terms of size reduction. We might see: > >>> > >>> + A reduction in the overall class size (not pack-200'd) > >>> - An increase in startup time (have to spin up synthetic classes > created at usage time) > >>> +/- And increase or decrease in performance > >>> + A decrease in source code > >>> > >>> It would be interesting to get some data for these points and see what > effect lambda's have. Especially if an IDE can just do it in bulk? > >>> > >>> Richard > >> > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From hang.vo at oracle.com Fri Oct 4 05:03:40 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 12:03:40 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31943: Gtk: jni_GetStringUTFChars segfault while running in jruby/jrubyfx Message-ID: <20131004120433.379D262D6E@hg.openjdk.java.net> Changeset: 60ad6d456028 Author: Anthony Petrov Date: 2013-10-04 15:53 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/60ad6d456028 RT-31943: Gtk: jni_GetStringUTFChars segfault while running in jruby/jrubyfx Reviewed-by: Alexander Zvegintsev ! modules/graphics/src/main/native-glass/gtk/glass_general.h ! modules/graphics/src/main/native-glass/gtk/glass_screen.cpp From sven.reimers at gmail.com Fri Oct 4 05:19:27 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 4 Oct 2013 14:19:27 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> Message-ID: Oh and btw - would you go for lambda with or without additional type info before parameter name? -Sven On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers wrote: > Ok. Here you go... > > I just did an inspection run for the controls module and my IDE came up > with (drum roll) 888 possible lambda conversions.. > > Looking through them I discovered that usage of <> (aka diamond syntax) is > not used (or at least not used a lot) in at least the controls modules. > My IDE showed me 1171 occurrences. > > Is there a good reason not to use diamonds? > > Will now try to apply all those changes and figure out if this still > builds... up next: go through the other modules... > > -Sven > > > On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote: > >> Brian was telling me at J1 that whether parallel gets you performance or >> not depends on the size of the collection and the complexity of the work to >> perform. There is definitely a point at which parallel helps -- and a point >> at which it hurts. >> >> Richard >> >> On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: >> >> > Here is a nice example, taking advantage of the ease of going parallel. >> Apparently the performance without parallel will also further improve. >> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >> > >> > Herv? >> > >> > Sent from my iPad >> > >> >> On 4 oct. 2013, at 00:20, David Grieve >> wrote: >> >> >> >> And what about Stream? I like the declarative code that comes from >> using Stream and I can see places in the code where Stream could be used, >> but I wonder about its performance relative to iterators and/or enhanced >> for loops. >> >> >> >> On Oct 3, 2013, at 4:45 PM, Richard Bair >> wrote: >> >> >> >>>> Hello, OpenJFX Community. >> >>>> >> >>>> There's a question about using Java 8 features in FX. >> >>>> >> >>>> I've been working on the support for InputMethods in JFXPanel which >> is an important feature for many users who speak hieroglyphic languages. >> >>>> The issue is tracked under: >> https://javafx-jira.kenai.com/browse/RT-13248 >> >>>> >> >>>> In order to have a high-quality support we need to change >> javafx.scene.input.InputMethodRequests interface and introduce 3 new >> methods. This is not needed for pure FX applications right now, but >> absolutely required for InputMethods in the JFXPanel. However, the >> interface is public and it was present since FX2.0, so changing it would >> become a breaking change. So the only way to avoid the problem is using the >> default methods. Those would return some stub values, the JDK is OK with >> that, as it would not crash or throw exceptions, but text composition would >> not work correctly. >> >>>> >> >>>> I know that we want to avoid using the Java 8 features in the JFX-8, >> so I wanted to ask - is it OK to use the default methods here? >> >>>> >> >>>> >> >>>> If you are staying away from JDK8 features for the JFX78 backport, >> don't worry. There are more issues with new JDK8 APIs than with the new >> language features. >> >>>> >> >>>> For example there were default methods put into some collections >> classes that we solved by pushing them down to the first implements. But >> the Date and Time picker depends on the new time package. The threeten >> backport won't be updated until after 8 ships, so that has been removed so >> far. >> >>>> >> >>>> I'de be interested to know what a wholesale lamdaization would >> result in speed wise and code size wise (both source and compiled). From >> what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut >> makes the backport more of a busy work proposition. If there were >> performance gains it would also make a great front page story in the next >> java magazine or a case study.. >> >>> >> >>> After having used Lambda's for JavaOne, I'd love to make the >> conversion, even if in the end the performance was the same, because the >> savings in noise in the Java files is so big. At one time I just took the >> concurrent classes and lambda-ized them to measure the impact on those >> classes. You could maybe pick a package and just lambda-ize that one >> package and see what happens in terms of size reduction. We might see: >> >>> >> >>> + A reduction in the overall class size (not pack-200'd) >> >>> - An increase in startup time (have to spin up synthetic classes >> created at usage time) >> >>> +/- And increase or decrease in performance >> >>> + A decrease in source code >> >>> >> >>> It would be interesting to get some data for these points and see >> what effect lambda's have. Especially if an IDE can just do it in bulk? >> >>> >> >>> Richard >> >> >> >> > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From hang.vo at oracle.com Fri Oct 4 06:03:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 13:03:53 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30898 - Regression : Tab travsersal issue with ScrollPane, reviewed by David Message-ID: <20131004130554.99BDB62D73@hg.openjdk.java.net> Changeset: 080c7905568c Author: mickf Date: 2013-10-04 13:53 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/080c7905568c RT-30898 - Regression : Tab travsersal issue with ScrollPane, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java From hang.vo at oracle.com Fri Oct 4 06:33:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 13:33:31 +0000 Subject: hg: openjfx/8/graphics/rt: ECLIPSE: work around Eclipse jdk8 compiler problem Message-ID: <20131004133419.CA6B162D76@hg.openjdk.java.net> Changeset: 0917b41c31ac Author: snorthov Date: 2013-10-04 09:29 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0917b41c31ac ECLIPSE: work around Eclipse jdk8 compiler problem ! modules/graphics/src/main/java/javafx/concurrent/Task.java From hang.vo at oracle.com Fri Oct 4 06:48:19 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 13:48:19 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33145: In SkinBase computeMinHeight and computeMinWidth, initialize minY/minX to max value and maxY/maxX to min value. Message-ID: <20131004134858.1BFDE62D77@hg.openjdk.java.net> Changeset: 78ee0e010484 Author: David Grieve Date: 2013-10-04 09:44 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/78ee0e010484 RT-33145: In SkinBase computeMinHeight and computeMinWidth, initialize minY/minX to max value and maxY/maxX to min value. Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java ! modules/graphics/src/main/java/javafx/scene/layout/Region.java From richard.bair at oracle.com Fri Oct 4 07:03:55 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 4 Oct 2013 07:03:55 -0700 Subject: bugfix mode In-Reply-To: <524E4A3F.6030407@tbee.org> References: <524E4A3F.6030407@tbee.org> Message-ID: <77B6D1CD-542F-4FA7-92AE-D3D42BE8B2A7@oracle.com> We are presently in full-on bug fixing mode. After October 24 only major, critical, and blocker bugs are being looked at, and December 4 is the last day, with only show stopper bugs fixable past that date. So if you have bugs, by all means now is the time to file and fix. It might already be too late to fix any additional minor or medium bugs unless they come with a patch and test attached. Richard > On Oct 3, 2013, at 9:55 PM, Tom Eugelink wrote: > > > Dear JFX team, > > There are a number of issues in my open source projects with JFX8 that need looking at, but I'm postponing that until JFX8 reaches a level of maturity that will limit the risk on having to redo things, aka that JFX8 is going into bugfix mode, prior to release. Are there any estimates on when that phase will begin? I think I remember a recent mail with that topic. > > Regards, > > Tom > > From tbee at tbee.org Fri Oct 4 07:24:34 2013 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 04 Oct 2013 16:24:34 +0200 Subject: bugfix mode In-Reply-To: <77B6D1CD-542F-4FA7-92AE-D3D42BE8B2A7@oracle.com> References: <524E4A3F.6030407@tbee.org> <77B6D1CD-542F-4FA7-92AE-D3D42BE8B2A7@oracle.com> Message-ID: <524ECFA2.2070109@tbee.org> Ok, clear. Then it is time I start looking at the issues that are reported on MigLayout and the CSS errors I"m getting. Tom On 2013-10-04 16:03, Richard Bair wrote: > We are presently in full-on bug fixing mode. After October 24 only major, critical, and blocker bugs are being looked at, and December 4 is the last day, with only show stopper bugs fixable past that date. > > So if you have bugs, by all means now is the time to file and fix. It might already be too late to fix any additional minor or medium bugs unless they come with a patch and test attached. > > Richard > >> On Oct 3, 2013, at 9:55 PM, Tom Eugelink wrote: >> >> >> Dear JFX team, >> >> There are a number of issues in my open source projects with JFX8 that need looking at, but I'm postponing that until JFX8 reaches a level of maturity that will limit the risk on having to redo things, aka that JFX8 is going into bugfix mode, prior to release. Are there any estimates on when that phase will begin? I think I remember a recent mail with that topic. >> >> Regards, >> >> Tom >> >> From kevin.rushforth at oracle.com Fri Oct 4 08:57:37 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 04 Oct 2013 08:57:37 -0700 Subject: Cannot compile following the OpenJFX instructions at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX In-Reply-To: References: Message-ID: <524EE571.1000807@oracle.com> There is a known bug introduced in JDK 8 b108. See: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-October/010592.html It is fixed in b110. -- Kevin Oscar Vargas Torres wrote: > This is the error I keep getting: > > http://pastie.org/8377161 > I am using Ubuntu Linux 13.04 64 bits. I have installed jdk8 b109 in my > machine. I have tried for several hours now. I need some guidance!! > > What I understand is that I need antlr but the gradle build is not able to > find it. > > Thanks > From richard.bair at oracle.com Fri Oct 4 09:20:02 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 4 Oct 2013 09:20:02 -0700 Subject: bugfix mode In-Reply-To: <524ECFA2.2070109@tbee.org> References: <524E4A3F.6030407@tbee.org> <77B6D1CD-542F-4FA7-92AE-D3D42BE8B2A7@oracle.com> <524ECFA2.2070109@tbee.org> Message-ID: <640F541C-95F4-460F-A965-A8691460754A@oracle.com> This page http://openjdk.java.net/projects/jdk8/milestones has the actual dates for JDK 8. The only place where we have a waiver to deviate for JavaFX is that our ZBB and Rampdown phase 2 are both scheduled for December 4. Richard On Oct 4, 2013, at 7:24 AM, Tom Eugelink wrote: > > Ok, clear. Then it is time I start looking at the issues that are reported on MigLayout and the CSS errors I"m getting. > > Tom > > > On 2013-10-04 16:03, Richard Bair wrote: >> We are presently in full-on bug fixing mode. After October 24 only major, critical, and blocker bugs are being looked at, and December 4 is the last day, with only show stopper bugs fixable past that date. >> >> So if you have bugs, by all means now is the time to file and fix. It might already be too late to fix any additional minor or medium bugs unless they come with a patch and test attached. >> >> Richard >> >>> On Oct 3, 2013, at 9:55 PM, Tom Eugelink wrote: >>> >>> >>> Dear JFX team, >>> >>> There are a number of issues in my open source projects with JFX8 that need looking at, but I'm postponing that until JFX8 reaches a level of maturity that will limit the risk on having to redo things, aka that JFX8 is going into bugfix mode, prior to release. Are there any estimates on when that phase will begin? I think I remember a recent mail with that topic. >>> >>> Regards, >>> >>> Tom >>> >>> > > From richard.bair at oracle.com Fri Oct 4 09:28:54 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 4 Oct 2013 09:28:54 -0700 Subject: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable Message-ID: Why are they not? It isn't immediately obvious to me why these are not mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd. Richard From hang.vo at oracle.com Fri Oct 4 10:03:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 17:03:35 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33357: CSS Parser dies on image-pattern and repeating-image-pattern with -ea flag Message-ID: <20131004170421.5986862D8A@hg.openjdk.java.net> Changeset: 6a633413eba4 Author: rbair Date: 2013-10-04 09:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6a633413eba4 RT-33357: CSS Parser dies on image-pattern and repeating-image-pattern with -ea flag Reviewed-by: dgrieve ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java From hang.vo at oracle.com Fri Oct 4 10:48:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 17:48:47 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Add TreeTableView sample Message-ID: <20131004174939.4586B62D8B@hg.openjdk.java.net> Changeset: 53288988ddf1 Author: dmasada Date: 2013-10-04 10:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/53288988ddf1 Ensemble8: Add TreeTableView sample ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/Inventory.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/Part.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/TreeTableViewApp.java + apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/treetableview/preview.png + apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/treetableview/preview at 2x.png From hang.vo at oracle.com Fri Oct 4 11:18:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 18:18:16 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32841: Paper.Units does not need to be public Message-ID: <20131004181921.42B0962D8D@hg.openjdk.java.net> Changeset: c71c80693664 Author: prr Date: 2013-10-04 11:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c71c80693664 RT-32841: Paper.Units does not need to be public Reviewed by: kcr, jgodinez ! modules/graphics/src/main/java/com/sun/javafx/print/PrintHelper.java + modules/graphics/src/main/java/com/sun/javafx/print/Units.java ! modules/graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java ! modules/graphics/src/main/java/javafx/print/Paper.java ! modules/graphics/src/main/java/javafx/print/Printer.java + modules/graphics/src/test/java/test/javafx/print/PaperUnitsTest.java From chien.yang at oracle.com Fri Oct 4 11:22:26 2013 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 04 Oct 2013 11:22:26 -0700 Subject: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable In-Reply-To: References: Message-ID: <524F0762.2060802@oracle.com> We did discuss making divisions in the predefined 3D shapes mutable in earlier meeting. However we decided against it since it is a heavy weight operation as the supporting mesh will has to be regenerated. I believe the constructor with the divisions argument will not have much use in the future when we move away from mesh implementation of our predefined 3D shapes. The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the camera and once set it shouldn't be changed. The perspective projection matrix is constructed differently depending on the flag. In the default mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that simple adding of 3D shapes into a 2D scene looks intuitive. The other mode, where eye is fixed a camera zero, is well suitable for movable camera in the 3d space. - Chien On 10/4/2013 9:28 AM, Richard Bair wrote: > Why are they not? It isn't immediately obvious to me why these are not mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd. > > Richard From John_Smith at symantec.com Fri Oct 4 11:45:48 2013 From: John_Smith at symantec.com (John Smith) Date: Fri, 4 Oct 2013 11:45:48 -0700 Subject: Enabling Glass thread checks In-Reply-To: References: Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22168A058F81@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > IllegalStateException("This operation is permitted on the event thread only") What is the event thread? Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: JavaFX Application Thread The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: JavaFX application thread: This is the primary thread used by JavaFX application developers. Any "live" scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Petr Pchelko Sent: Friday, October 04, 2013 1:40 AM To: OpenJFX list Subject: Enabling Glass thread checks Hello, OpenJFX. FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. The following exception would mean that you've hit a thread check: IllegalStateException("This operation is permitted on the event thread only"). In that case please check your threading and if everything seems correct - please contact the Glass team. Thank you. With best regards. Petr. From steve.x.northover at oracle.com Fri Oct 4 12:00:54 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 04 Oct 2013 15:00:54 -0400 Subject: Enabling Glass thread checks In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22168A058F81@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <411E73D23DEC4C46BA48F2B6D8BF3D22168A058F81@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <524F1066.4020003@oracle.com> It's the JavaFX Application Thread. We tend to use the term "event thread" and "UI thread" to indicate that the thread is a distinguished UI thread that processes operating system events by running an event loop. Steve On 04/10/2013 2:45 PM, John Smith wrote: >> IllegalStateException("This operation is permitted on the event thread only") > What is the event thread? > > Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): > > Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 > > It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. > > If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: > > JavaFX Application Thread > > The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: > > JavaFX application thread: This is the primary thread used by JavaFX application developers. Any "live" scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. > > Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. > > Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Petr Pchelko > Sent: Friday, October 04, 2013 1:40 AM > To: OpenJFX list > Subject: Enabling Glass thread checks > > Hello, OpenJFX. > > FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 > > We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. > > The following exception would mean that you've hit a thread check: IllegalStateException("This operation is permitted on the event thread only"). > In that case please check your threading and if everything seems correct - please contact the Glass team. > > Thank you. > With best regards. Petr. From richard.bair at oracle.com Fri Oct 4 12:36:33 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 4 Oct 2013 12:36:33 -0700 Subject: Enabling Glass thread checks In-Reply-To: <524F1066.4020003@oracle.com> References: <411E73D23DEC4C46BA48F2B6D8BF3D22168A058F81@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <524F1066.4020003@oracle.com> Message-ID: <0374DFB8-BDB9-414D-AAFF-9AD0999C126E@oracle.com> Ya, "event thread", "fx thread", "ui thread", "app thread", "FX Application thread" --- they're all the same thing. It would be better if we settled on one name. Richard On Oct 4, 2013, at 12:00 PM, steve.x.northover at oracle.com wrote: > It's the JavaFX Application Thread. We tend to use the term "event thread" and "UI thread" to indicate that the thread is a distinguished UI thread that processes operating system events by running an event loop. > > Steve > > On 04/10/2013 2:45 PM, John Smith wrote: >>> IllegalStateException("This operation is permitted on the event thread only") >> What is the event thread? >> >> Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): >> >> Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 >> >> It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. >> >> If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: >> >> JavaFX Application Thread >> >> The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: >> >> JavaFX application thread: This is the primary thread used by JavaFX application developers. Any "live" scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. >> >> Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. >> >> Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Petr Pchelko >> Sent: Friday, October 04, 2013 1:40 AM >> To: OpenJFX list >> Subject: Enabling Glass thread checks >> >> Hello, OpenJFX. >> >> FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 >> >> We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. >> >> The following exception would mean that you've hit a thread check: IllegalStateException("This operation is permitted on the event thread only"). >> In that case please check your threading and if everything seems correct - please contact the Glass team. >> >> Thank you. >> With best regards. Petr. > From steve.x.northover at oracle.com Fri Oct 4 12:38:25 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 04 Oct 2013 15:38:25 -0400 Subject: Enabling Glass thread checks In-Reply-To: <0374DFB8-BDB9-414D-AAFF-9AD0999C126E@oracle.com> References: <411E73D23DEC4C46BA48F2B6D8BF3D22168A058F81@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <524F1066.4020003@oracle.com> <0374DFB8-BDB9-414D-AAFF-9AD0999C126E@oracle.com> Message-ID: <524F1931.9090505@oracle.com> We are BAD. It should really be "FX Application Thread" but the "GUI", "event" nature of the thread is critical to what it is. That's why the terms keep getting added. Steve On 04/10/2013 3:36 PM, Richard Bair wrote: > Ya, "event thread", "fx thread", "ui thread", "app thread", "FX Application thread" --- they're all the same thing. It would be better if we settled on one name. > > Richard > > On Oct 4, 2013, at 12:00 PM, steve.x.northover at oracle.com wrote: > >> It's the JavaFX Application Thread. We tend to use the term "event thread" and "UI thread" to indicate that the thread is a distinguished UI thread that processes operating system events by running an event loop. >> >> Steve >> >> On 04/10/2013 2:45 PM, John Smith wrote: >>>> IllegalStateException("This operation is permitted on the event thread only") >>> What is the event thread? >>> >>> Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): >>> >>> Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 >>> >>> It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. >>> >>> If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: >>> >>> JavaFX Application Thread >>> >>> The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: >>> >>> JavaFX application thread: This is the primary thread used by JavaFX application developers. Any "live" scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. >>> >>> Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. >>> >>> Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Petr Pchelko >>> Sent: Friday, October 04, 2013 1:40 AM >>> To: OpenJFX list >>> Subject: Enabling Glass thread checks >>> >>> Hello, OpenJFX. >>> >>> FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 >>> >>> We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. >>> >>> The following exception would mean that you've hit a thread check: IllegalStateException("This operation is permitted on the event thread only"). >>> In that case please check your threading and if everything seems correct - please contact the Glass team. >>> >>> Thank you. >>> With best regards. Petr. From kevin.rushforth at oracle.com Fri Oct 4 12:46:03 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 04 Oct 2013 12:46:03 -0700 Subject: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable In-Reply-To: <524F0762.2060802@oracle.com> References: <524F0762.2060802@oracle.com> Message-ID: <524F1AFB.8090105@oracle.com> Yes, that pretty much captures the thinking behind it. My thought is that there is no real reason that subdivisions need to be immutable, although I wouldn't want to change it at this late date for FX 8 unless it is needed for FXML support. The fixedEyeAtCameraZero mode is not something I think should be mutable, since the camera behaves fairly differently in each mode. Having said that, there is no reason it couldn't be made mutable in a subsequent release if there was a good reason to do so. -- Kevin Chien Yang wrote: > We did discuss making divisions in the predefined 3D shapes mutable in > earlier meeting. However we decided against it since it is a heavy > weight operation as the supporting mesh will has to be regenerated. I > believe the constructor with the divisions argument will not have much > use in the future when we move away from mesh implementation of our > predefined 3D shapes. > > The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to > the camera and once set it shouldn't be changed. The perspective > projection matrix is constructed differently depending on the flag. In > the default mode, JavaFX controls the eye to achieve a projection > plane at Z=0 so that simple adding of 3D shapes into a 2D scene looks > intuitive. The other mode, where eye is fixed a camera zero, is well > suitable for movable camera in the 3d space. > > - Chien > > On 10/4/2013 9:28 AM, Richard Bair wrote: >> Why are they not? It isn't immediately obvious to me why these are >> not mutable? I was reading >> https://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd. >> >> Richard From richard.bair at oracle.com Fri Oct 4 12:50:53 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 4 Oct 2013 12:50:53 -0700 Subject: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable In-Reply-To: <524F1AFB.8090105@oracle.com> References: <524F0762.2060802@oracle.com> <524F1AFB.8090105@oracle.com> Message-ID: <79BA77F5-CA19-4802-8265-728560B419D0@oracle.com> I would turn that around and say that unless there is a compelling reason for something to be immutable, it should be mutable. Mutability is important for tools as well as for FXML as well as for developers. Immutable state is awesome for thread-safety or any type of concurrency. But these types of classes are not of that nature, they're UI only classes, and as such their state should be mutable (and like all mutable state in FX, the range of possible values should not be hindered by the evil "unbind" pattern). Richard On Oct 4, 2013, at 12:46 PM, Kevin Rushforth wrote: > Yes, that pretty much captures the thinking behind it. > > My thought is that there is no real reason that subdivisions need to be immutable, although I wouldn't want to change it at this late date for FX 8 unless it is needed for FXML support. > > The fixedEyeAtCameraZero mode is not something I think should be mutable, since the camera behaves fairly differently in each mode. Having said that, there is no reason it couldn't be made mutable in a subsequent release if there was a good reason to do so. > > -- Kevin > > > Chien Yang wrote: >> We did discuss making divisions in the predefined 3D shapes mutable in earlier meeting. However we decided against it since it is a heavy weight operation as the supporting mesh will has to be regenerated. I believe the constructor with the divisions argument will not have much use in the future when we move away from mesh implementation of our predefined 3D shapes. >> >> The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the camera and once set it shouldn't be changed. The perspective projection matrix is constructed differently depending on the flag. In the default mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that simple adding of 3D shapes into a 2D scene looks intuitive. The other mode, where eye is fixed a camera zero, is well suitable for movable camera in the 3d space. >> >> - Chien >> >> On 10/4/2013 9:28 AM, Richard Bair wrote: >>> Why are they not? It isn't immediately obvious to me why these are not mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd. >>> >>> Richard From richard.bair at oracle.com Fri Oct 4 12:53:01 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 4 Oct 2013 12:53:01 -0700 Subject: Enabling Glass thread checks In-Reply-To: <524F1931.9090505@oracle.com> References: <411E73D23DEC4C46BA48F2B6D8BF3D22168A058F81@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <524F1066.4020003@oracle.com> <0374DFB8-BDB9-414D-AAFF-9AD0999C126E@oracle.com> <524F1931.9090505@oracle.com> Message-ID: I always disliked FX Application thread, which is why I don't use it. The FXAT or FAT are acronyms we ought to avoid. EDT was great for Swing because it was super short, but we don't want to reuse EDT because that would be confusing. Personally I tend to use FX Thread because it is clear that this is the thread for JavaFX (and as far as users of the toolkit goes, the only thread that matters). Oh well. On Oct 4, 2013, at 12:38 PM, steve.x.northover at oracle.com wrote: > We are BAD. It should really be "FX Application Thread" but the "GUI", "event" nature of the thread is critical to what it is. That's why the terms keep getting added. > > Steve > > On 04/10/2013 3:36 PM, Richard Bair wrote: >> Ya, "event thread", "fx thread", "ui thread", "app thread", "FX Application thread" --- they're all the same thing. It would be better if we settled on one name. >> >> Richard >> >> On Oct 4, 2013, at 12:00 PM, steve.x.northover at oracle.com wrote: >> >>> It's the JavaFX Application Thread. We tend to use the term "event thread" and "UI thread" to indicate that the thread is a distinguished UI thread that processes operating system events by running an event loop. >>> >>> Steve >>> >>> On 04/10/2013 2:45 PM, John Smith wrote: >>>>> IllegalStateException("This operation is permitted on the event thread only") >>>> What is the event thread? >>>> >>>> Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): >>>> >>>> Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 >>>> >>>> It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. >>>> >>>> If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: >>>> >>>> JavaFX Application Thread >>>> >>>> The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: >>>> >>>> JavaFX application thread: This is the primary thread used by JavaFX application developers. Any "live" scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. >>>> >>>> Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. >>>> >>>> Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. >>>> >>>> -----Original Message----- >>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Petr Pchelko >>>> Sent: Friday, October 04, 2013 1:40 AM >>>> To: OpenJFX list >>>> Subject: Enabling Glass thread checks >>>> >>>> Hello, OpenJFX. >>>> >>>> FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 >>>> >>>> We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. >>>> >>>> The following exception would mean that you've hit a thread check: IllegalStateException("This operation is permitted on the event thread only"). >>>> In that case please check your threading and if everything seems correct - please contact the Glass team. >>>> >>>> Thank you. >>>> With best regards. Petr. > From thor.johannesson at oracle.com Fri Oct 4 13:07:42 2013 From: thor.johannesson at oracle.com (Thor Johannesson) Date: Fri, 4 Oct 2013 13:07:42 -0700 Subject: Enabling Glass thread checks In-Reply-To: References: <411E73D23DEC4C46BA48F2B6D8BF3D22168A058F81@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <524F1066.4020003@oracle.com> <0374DFB8-BDB9-414D-AAFF-9AD0999C126E@oracle.com> <524F1931.9090505@oracle.com> Message-ID: <1F2659E4-6F2E-4DCB-9CC1-C0E64914102C@oracle.com> +1 for FX Thread. -Thor On Oct 4, 2013, at 12:53 PM, Richard Bair wrote: > I always disliked FX Application thread, which is why I don't use it. The FXAT or FAT are acronyms we ought to avoid. EDT was great for Swing because it was super short, but we don't want to reuse EDT because that would be confusing. Personally I tend to use FX Thread because it is clear that this is the thread for JavaFX (and as far as users of the toolkit goes, the only thread that matters). Oh well. > > > On Oct 4, 2013, at 12:38 PM, steve.x.northover at oracle.com wrote: > >> We are BAD. It should really be "FX Application Thread" but the "GUI", "event" nature of the thread is critical to what it is. That's why the terms keep getting added. >> >> Steve >> >> On 04/10/2013 3:36 PM, Richard Bair wrote: >>> Ya, "event thread", "fx thread", "ui thread", "app thread", "FX Application thread" --- they're all the same thing. It would be better if we settled on one name. >>> >>> Richard >>> >>> On Oct 4, 2013, at 12:00 PM, steve.x.northover at oracle.com wrote: >>> >>>> It's the JavaFX Application Thread. We tend to use the term "event thread" and "UI thread" to indicate that the thread is a distinguished UI thread that processes operating system events by running an event loop. >>>> >>>> Steve >>>> >>>> On 04/10/2013 2:45 PM, John Smith wrote: >>>>>> IllegalStateException("This operation is permitted on the event thread only") >>>>> What is the event thread? >>>>> >>>>> Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): >>>>> >>>>> Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 >>>>> >>>>> It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. >>>>> >>>>> If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: >>>>> >>>>> JavaFX Application Thread >>>>> >>>>> The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: >>>>> >>>>> JavaFX application thread: This is the primary thread used by JavaFX application developers. Any "live" scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. >>>>> >>>>> Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. >>>>> >>>>> Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. >>>>> >>>>> -----Original Message----- >>>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Petr Pchelko >>>>> Sent: Friday, October 04, 2013 1:40 AM >>>>> To: OpenJFX list >>>>> Subject: Enabling Glass thread checks >>>>> >>>>> Hello, OpenJFX. >>>>> >>>>> FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 >>>>> >>>>> We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. >>>>> >>>>> The following exception would mean that you've hit a thread check: IllegalStateException("This operation is permitted on the event thread only"). >>>>> In that case please check your threading and if everything seems correct - please contact the Glass team. >>>>> >>>>> Thank you. >>>>> With best regards. Petr. >> > From kevin.rushforth at oracle.com Fri Oct 4 13:08:05 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 04 Oct 2013 13:08:05 -0700 Subject: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable In-Reply-To: <79BA77F5-CA19-4802-8265-728560B419D0@oracle.com> References: <524F0762.2060802@oracle.com> <524F1AFB.8090105@oracle.com> <79BA77F5-CA19-4802-8265-728560B419D0@oracle.com> Message-ID: <524F2025.7050104@oracle.com> Certainly for divisions there is no reason to keep them immutable. For fixedEyeAtCameraZero, I don't think the reasons for keeping it immutable are compelling. Making either change in FX 8 is a different matter, though, given how late we are. The implementation assumes immutability and we would need to change it, implement it, test it, and then fix any bugs as a result. Seems like we could add mutability in a subsequent release. -- Kevin Richard Bair wrote: > I would turn that around and say that unless there is a compelling reason for something to be immutable, it should be mutable. Mutability is important for tools as well as for FXML as well as for developers. > > Immutable state is awesome for thread-safety or any type of concurrency. But these types of classes are not of that nature, they're UI only classes, and as such their state should be mutable (and like all mutable state in FX, the range of possible values should not be hindered by the evil "unbind" pattern). > > Richard > > On Oct 4, 2013, at 12:46 PM, Kevin Rushforth wrote: > > >> Yes, that pretty much captures the thinking behind it. >> >> My thought is that there is no real reason that subdivisions need to be immutable, although I wouldn't want to change it at this late date for FX 8 unless it is needed for FXML support. >> >> The fixedEyeAtCameraZero mode is not something I think should be mutable, since the camera behaves fairly differently in each mode. Having said that, there is no reason it couldn't be made mutable in a subsequent release if there was a good reason to do so. >> >> -- Kevin >> >> >> Chien Yang wrote: >> >>> We did discuss making divisions in the predefined 3D shapes mutable in earlier meeting. However we decided against it since it is a heavy weight operation as the supporting mesh will has to be regenerated. I believe the constructor with the divisions argument will not have much use in the future when we move away from mesh implementation of our predefined 3D shapes. >>> >>> The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the camera and once set it shouldn't be changed. The perspective projection matrix is constructed differently depending on the flag. In the default mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that simple adding of 3D shapes into a 2D scene looks intuitive. The other mode, where eye is fixed a camera zero, is well suitable for movable camera in the 3d space. >>> >>> - Chien >>> >>> On 10/4/2013 9:28 AM, Richard Bair wrote: >>> >>>> Why are they not? It isn't immediately obvious to me why these are not mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd. >>>> >>>> Richard >>>> > > From hang.vo at oracle.com Fri Oct 4 12:33:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 04 Oct 2013 19:33:16 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30750 Jitter on Resize Reviewed by: KevinR, SteveN, Artem, DaveH Message-ID: <20131004193357.A5D8E62D91@hg.openjdk.java.net> Changeset: 137e59786fc1 Author: "Joseph Andresen" Date: 2013-10-04 12:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/137e59786fc1 RT-30750 Jitter on Resize Reviewed by: KevinR, SteveN, Artem, DaveH ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedState.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/SceneState.java From richard.bair at oracle.com Fri Oct 4 13:51:10 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 4 Oct 2013 13:51:10 -0700 Subject: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable In-Reply-To: <524F2025.7050104@oracle.com> References: <524F0762.2060802@oracle.com> <524F1AFB.8090105@oracle.com> <79BA77F5-CA19-4802-8265-728560B419D0@oracle.com> <524F2025.7050104@oracle.com> Message-ID: Depends on whether it is usable from SceneBuilder and FXML, and the following: - We must *not* expose a ReadOnly property for these properties (and I don't think we do) - The FXML changes must be backwards compatible (they should be but we need to verify) - The SceneBuilder can do something reasonable as is (not sure). Richard On Oct 4, 2013, at 1:08 PM, Kevin Rushforth wrote: > Certainly for divisions there is no reason to keep them immutable. For fixedEyeAtCameraZero, I don't think the reasons for keeping it immutable are compelling. > > Making either change in FX 8 is a different matter, though, given how late we are. The implementation assumes immutability and we would need to change it, implement it, test it, and then fix any bugs as a result. Seems like we could add mutability in a subsequent release. > > -- Kevin > > > Richard Bair wrote: >> >> I would turn that around and say that unless there is a compelling reason for something to be immutable, it should be mutable. Mutability is important for tools as well as for FXML as well as for developers. >> >> Immutable state is awesome for thread-safety or any type of concurrency. But these types of classes are not of that nature, they're UI only classes, and as such their state should be mutable (and like all mutable state in FX, the range of possible values should not be hindered by the evil "unbind" pattern). >> >> Richard >> >> On Oct 4, 2013, at 12:46 PM, Kevin Rushforth wrote: >> >> >>> Yes, that pretty much captures the thinking behind it. >>> >>> My thought is that there is no real reason that subdivisions need to be immutable, although I wouldn't want to change it at this late date for FX 8 unless it is needed for FXML support. >>> >>> The fixedEyeAtCameraZero mode is not something I think should be mutable, since the camera behaves fairly differently in each mode. Having said that, there is no reason it couldn't be made mutable in a subsequent release if there was a good reason to do so. >>> >>> -- Kevin >>> >>> >>> Chien Yang wrote: >>> >>>> We did discuss making divisions in the predefined 3D shapes mutable in earlier meeting. However we decided against it since it is a heavy weight operation as the supporting mesh will has to be regenerated. I believe the constructor with the divisions argument will not have much use in the future when we move away from mesh implementation of our predefined 3D shapes. >>>> >>>> The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the camera and once set it shouldn't be changed. The perspective projection matrix is constructed differently depending on the flag. In the default mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that simple adding of 3D shapes into a 2D scene looks intuitive. The other mode, where eye is fixed a camera zero, is well suitable for movable camera in the 3d space. >>>> >>>> - Chien >>>> >>>> On 10/4/2013 9:28 AM, Richard Bair wrote: >>>> >>>>> Why are they not? It isn't immediately obvious to me why these are not mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd. >>>>> >>>>> Richard >>>>> >> >> From kevin.rushforth at oracle.com Fri Oct 4 14:10:43 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 04 Oct 2013 14:10:43 -0700 Subject: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable In-Reply-To: References: <524F0762.2060802@oracle.com> <524F1AFB.8090105@oracle.com> <79BA77F5-CA19-4802-8265-728560B419D0@oracle.com> <524F2025.7050104@oracle.com> Message-ID: <524F2ED3.7060002@oracle.com> Sounds good. > Depends on whether it is usable from SceneBuilder and FXML, and the > following: > - We must *not* expose a ReadOnly property for these properties > (and I don't think we do) No, we don't. > - The FXML changes must be backwards compatible (they should be but > we need to verify) I'll add a note to the JIRA and the FXML folks can reply. > - The SceneBuilder can do something reasonable as is (not sure). Chien or I can reach out to the SB team. -- Kevin Richard Bair wrote: > Depends on whether it is usable from SceneBuilder and FXML, and the > following: > - We must *not* expose a ReadOnly property for these properties > (and I don't think we do) > - The FXML changes must be backwards compatible (they should be but > we need to verify) > - The SceneBuilder can do something reasonable as is (not sure). > > Richard > > On Oct 4, 2013, at 1:08 PM, Kevin Rushforth > > wrote: > >> Certainly for divisions there is no reason to keep them immutable. >> For fixedEyeAtCameraZero, I don't think the reasons for keeping it >> immutable are compelling. >> >> Making either change in FX 8 is a different matter, though, given how >> late we are. The implementation assumes immutability and we would >> need to change it, implement it, test it, and then fix any bugs as a >> result. Seems like we could add mutability in a subsequent release. >> >> -- Kevin >> >> >> Richard Bair wrote: >>> I would turn that around and say that unless there is a compelling reason for something to be immutable, it should be mutable. Mutability is important for tools as well as for FXML as well as for developers. >>> >>> Immutable state is awesome for thread-safety or any type of concurrency. But these types of classes are not of that nature, they're UI only classes, and as such their state should be mutable (and like all mutable state in FX, the range of possible values should not be hindered by the evil "unbind" pattern). >>> >>> Richard >>> >>> On Oct 4, 2013, at 12:46 PM, Kevin Rushforth wrote: >>> >>> >>>> Yes, that pretty much captures the thinking behind it. >>>> >>>> My thought is that there is no real reason that subdivisions need to be immutable, although I wouldn't want to change it at this late date for FX 8 unless it is needed for FXML support. >>>> >>>> The fixedEyeAtCameraZero mode is not something I think should be mutable, since the camera behaves fairly differently in each mode. Having said that, there is no reason it couldn't be made mutable in a subsequent release if there was a good reason to do so. >>>> >>>> -- Kevin >>>> >>>> >>>> Chien Yang wrote: >>>> >>>>> We did discuss making divisions in the predefined 3D shapes mutable in earlier meeting. However we decided against it since it is a heavy weight operation as the supporting mesh will has to be regenerated. I believe the constructor with the divisions argument will not have much use in the future when we move away from mesh implementation of our predefined 3D shapes. >>>>> >>>>> The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the camera and once set it shouldn't be changed. The perspective projection matrix is constructed differently depending on the flag. In the default mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that simple adding of 3D shapes into a 2D scene looks intuitive. The other mode, where eye is fixed a camera zero, is well suitable for movable camera in the 3d space. >>>>> >>>>> - Chien >>>>> >>>>> On 10/4/2013 9:28 AM, Richard Bair wrote: >>>>> >>>>>> Why are they not? It isn't immediately obvious to me why these are not mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd. >>>>>> >>>>>> Richard >>>>>> >>> >>> > From hang.vo at oracle.com Fri Oct 4 17:03:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 05 Oct 2013 00:03:29 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28335 ArrayIndexOutOfBounds in canvas polys ReviewedBy: Jim, Kevin Message-ID: <20131005000419.147EA62DA1@hg.openjdk.java.net> Changeset: 66325e8963ef Author: "Joseph Andresen" Date: 2013-10-04 16:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/66325e8963ef RT-28335 ArrayIndexOutOfBounds in canvas polys ReviewedBy: Jim,Kevin ! modules/graphics/src/main/java/javafx/scene/canvas/GraphicsContext.java From herve.girod at gmail.com Sat Oct 5 04:15:40 2013 From: herve.girod at gmail.com (Herve Girod) Date: Sat, 5 Oct 2013 13:15:40 +0200 Subject: bugfix mode In-Reply-To: <640F541C-95F4-460F-A965-A8691460754A@oracle.com> References: <524E4A3F.6030407@tbee.org> <77B6D1CD-542F-4FA7-92AE-D3D42BE8B2A7@oracle.com> <524ECFA2.2070109@tbee.org> <640F541C-95F4-460F-A965-A8691460754A@oracle.com> Message-ID: Do you plan to add the AlwaysOnTop feature for JavaFX 8? The JIRA ( https://javafx-jira.kenai.com/browse/RT-153) is very old ;) 2013/10/4 Richard Bair > This page http://openjdk.java.net/projects/jdk8/milestones has the actual > dates for JDK 8. The only place where we have a waiver to deviate for > JavaFX is that our ZBB and Rampdown phase 2 are both scheduled for December > 4. > > Richard > > On Oct 4, 2013, at 7:24 AM, Tom Eugelink wrote: > > > > > Ok, clear. Then it is time I start looking at the issues that are > reported on MigLayout and the CSS errors I"m getting. > > > > Tom > > > > > > On 2013-10-04 16:03, Richard Bair wrote: > >> We are presently in full-on bug fixing mode. After October 24 only > major, critical, and blocker bugs are being looked at, and December 4 is > the last day, with only show stopper bugs fixable past that date. > >> > >> So if you have bugs, by all means now is the time to file and fix. It > might already be too late to fix any additional minor or medium bugs unless > they come with a patch and test attached. > >> > >> Richard > >> > >>> On Oct 3, 2013, at 9:55 PM, Tom Eugelink wrote: > >>> > >>> > >>> Dear JFX team, > >>> > >>> There are a number of issues in my open source projects with JFX8 that > need looking at, but I'm postponing that until JFX8 reaches a level of > maturity that will limit the risk on having to redo things, aka that JFX8 > is going into bugfix mode, prior to release. Are there any estimates on > when that phase will begin? I think I remember a recent mail with that > topic. > >>> > >>> Regards, > >>> > >>> Tom > >>> > >>> > > > > > > From daniel.blaukopf at oracle.com Sun Oct 6 00:39:49 2013 From: daniel.blaukopf at oracle.com (Daniel Blaukopf) Date: Sun, 6 Oct 2013 10:39:49 +0300 Subject: CFV: New OpenJDK Committer: Lisa Selle In-Reply-To: <5243019D.90301@oracle.com> References: <5243019D.90301@oracle.com> Message-ID: <5174CAA0-E5E9-4CE3-B262-198EC4FC06E4@oracle.com> Vote: yes Daniel On Sep 25, 2013, at 6:30 PM, Artem Ananiev wrote: > > I hereby nominate Lisa Selle to OpenJFX Committer. > > Lisa is a member of JavaFX Embedded team. Her changes are all over the JavaFX code, from cursors and input events to makefiles and virtual keyboard. The list of Lisa's commits in the workspace: > > hg log -u "Lisa Selle" > hg log -u "Lisa.Selle" > > Incomplete list is also available by the following link: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=selle > > Votes are due to Oct 09, 2013. > > Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From daniel.blaukopf at oracle.com Sun Oct 6 00:41:04 2013 From: daniel.blaukopf at oracle.com (Daniel Blaukopf) Date: Sun, 6 Oct 2013 10:41:04 +0300 Subject: CFV: New OpenJFX Committer: Joseph Andresen In-Reply-To: <5242FE9D.3050205@oracle.com> References: <5242FE9D.3050205@oracle.com> Message-ID: <4632E1C2-7BF4-4B2C-9AD6-BED509D54C40@oracle.com> Vote: yes Daniel On Sep 25, 2013, at 6:17 PM, Artem Ananiev wrote: > > I hereby nominate Joe Andresen to OpenJFX Committer. > > Joe is a member of JavaFX Graphics team at Oracle. His first changeset in Prism is dated by 2009, and total number of commits is close to one hundred. Full list of Joe's changesets in the open workspace is available from command line: > > hg log -u "Joseph Andresen" > > Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Artem From sven.reimers at gmail.com Sun Oct 6 07:58:57 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 6 Oct 2013 16:58:57 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> Message-ID: Ok. So here are the results of trying to add lambda and diamond to the controls module: 1. A lot of generics and typing to be fixed (esp. in tests). Seems you can get some anonymous inner classes type checked by the compiler, but not the lambda equivalent.. very interesting. 2. 279 Files modified (including tests) 3. A lot of the automatic replacements could probably be nicer e.g. ft.setOnFinished(new EventHandler() { @Override public void handle(ActionEvent actionEvent) { getChildren().remove(tm.textNode); } }); was replaced to: ft.setOnFinished((ActionEvent actionEvent) -> { getChildren().remove(tm.textNode); }); most unobtrusive code probably: ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); 4. A lot of illegal forward reference errors - these were result of missing this in the automatic transformation from anonymous inner to lambdas (seems the rules are not identical - you have to add "this." as prefix if using lambdas - not sure this is the expected way it should work) 5. Should we enable more -Xlint warnings in OpenJFX build? 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings 7. Probably more things I just can't think of at the moment... How to take this forward? If there is interest in the change I could make available... Comments? Ideas? -Sven On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers wrote: > Oh and btw - would you go for lambda with or without additional type info > before parameter name? > > -Sven > > > On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers wrote: > >> Ok. Here you go... >> >> I just did an inspection run for the controls module and my IDE came up >> with (drum roll) 888 possible lambda conversions.. >> >> Looking through them I discovered that usage of <> (aka diamond syntax) >> is not used (or at least not used a lot) in at least the controls >> modules. My IDE showed me 1171 occurrences. >> >> Is there a good reason not to use diamonds? >> >> Will now try to apply all those changes and figure out if this still >> builds... up next: go through the other modules... >> >> -Sven >> >> >> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote: >> >>> Brian was telling me at J1 that whether parallel gets you performance or >>> not depends on the size of the collection and the complexity of the work to >>> perform. There is definitely a point at which parallel helps -- and a point >>> at which it hurts. >>> >>> Richard >>> >>> On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: >>> >>> > Here is a nice example, taking advantage of the ease of going >>> parallel. Apparently the performance without parallel will also further >>> improve. >>> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >>> > >>> > Herv? >>> > >>> > Sent from my iPad >>> > >>> >> On 4 oct. 2013, at 00:20, David Grieve >>> wrote: >>> >> >>> >> And what about Stream? I like the declarative code that comes from >>> using Stream and I can see places in the code where Stream could be used, >>> but I wonder about its performance relative to iterators and/or enhanced >>> for loops. >>> >> >>> >> On Oct 3, 2013, at 4:45 PM, Richard Bair >>> wrote: >>> >> >>> >>>> Hello, OpenJFX Community. >>> >>>> >>> >>>> There's a question about using Java 8 features in FX. >>> >>>> >>> >>>> I've been working on the support for InputMethods in JFXPanel which >>> is an important feature for many users who speak hieroglyphic languages. >>> >>>> The issue is tracked under: >>> https://javafx-jira.kenai.com/browse/RT-13248 >>> >>>> >>> >>>> In order to have a high-quality support we need to change >>> javafx.scene.input.InputMethodRequests interface and introduce 3 new >>> methods. This is not needed for pure FX applications right now, but >>> absolutely required for InputMethods in the JFXPanel. However, the >>> interface is public and it was present since FX2.0, so changing it would >>> become a breaking change. So the only way to avoid the problem is using the >>> default methods. Those would return some stub values, the JDK is OK with >>> that, as it would not crash or throw exceptions, but text composition would >>> not work correctly. >>> >>>> >>> >>>> I know that we want to avoid using the Java 8 features in the >>> JFX-8, so I wanted to ask - is it OK to use the default methods here? >>> >>>> >>> >>>> >>> >>>> If you are staying away from JDK8 features for the JFX78 backport, >>> don't worry. There are more issues with new JDK8 APIs than with the new >>> language features. >>> >>>> >>> >>>> For example there were default methods put into some collections >>> classes that we solved by pushing them down to the first implements. But >>> the Date and Time picker depends on the new time package. The threeten >>> backport won't be updated until after 8 ships, so that has been removed so >>> far. >>> >>>> >>> >>>> I'de be interested to know what a wholesale lamdaization would >>> result in speed wise and code size wise (both source and compiled). From >>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut >>> makes the backport more of a busy work proposition. If there were >>> performance gains it would also make a great front page story in the next >>> java magazine or a case study.. >>> >>> >>> >>> After having used Lambda's for JavaOne, I'd love to make the >>> conversion, even if in the end the performance was the same, because the >>> savings in noise in the Java files is so big. At one time I just took the >>> concurrent classes and lambda-ized them to measure the impact on those >>> classes. You could maybe pick a package and just lambda-ize that one >>> package and see what happens in terms of size reduction. We might see: >>> >>> >>> >>> + A reduction in the overall class size (not pack-200'd) >>> >>> - An increase in startup time (have to spin up synthetic classes >>> created at usage time) >>> >>> +/- And increase or decrease in performance >>> >>> + A decrease in source code >>> >>> >>> >>> It would be interesting to get some data for these points and see >>> what effect lambda's have. Especially if an IDE can just do it in bulk? >>> >>> >>> >>> Richard >>> >> >>> >>> >> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java: >> http://community.java.net/javadesktop >> * Duke's Choice Award Winner 2009 >> * Blog: http://nbguru.blogspot.com >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> Join the NetBeans Groups: >> * XING: http://www.xing.com/group-20148.82db20 >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> http://www.linkedin.com/groups?gid=107402 >> http://www.linkedin.com/groups?gid=1684717 >> * Oracle: https://mix.oracle.com/groups/18497 >> > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From pedro.duquevieira at gmail.com Sun Oct 6 15:40:18 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sun, 6 Oct 2013 23:40:18 +0100 Subject: Keyboard events Message-ID: Hi, I have the following use case: When the user presses shift and the mouse is hover the chart component the cursor must change to an open hand cursor signaling to the user that the chart is ready for a panning action. The problem is that for this to be possible I want the chart to be able to listen to keyboard events even when it doesn't have focus. I think this is not possible and I wonder why. Swing was the same, you could only listen to keyboard events if the control had focus. Is this a technical limitation? If there is no technical limitation I think it would be better to remove this restriction, I think it is limiting and the above scenario is a good use case to show that. Thanks, best regards, -- Pedro Duque Vieira From danno.ferrin at shemnon.com Sun Oct 6 16:58:32 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Sun, 6 Oct 2013 17:58:32 -0600 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> Message-ID: What are the metrics? Lines of code saved, size of jar, number of generated classes, runtime performance? On Sun, Oct 6, 2013 at 8:58 AM, Sven Reimers wrote: > Ok. So here are the results of trying to add lambda and diamond to the > controls module: > > 1. A lot of generics and typing to be fixed (esp. in tests). Seems you can > get some anonymous inner classes type checked by the compiler, but not the > lambda equivalent.. very interesting. > > 2. 279 Files modified (including tests) > > 3. A lot of the automatic replacements could probably be nicer e.g. > > ft.setOnFinished(new EventHandler() { > @Override public void handle(ActionEvent > actionEvent) { > getChildren().remove(tm.textNode); > } > }); > > was replaced to: > > ft.setOnFinished((ActionEvent actionEvent) -> { > getChildren().remove(tm.textNode); > }); > > This is actually better for the jfx78 backport, merging the lines would create more false diffs when the only change is lambdafication. > most unobtrusive code probably: > > ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); > > 4. A lot of illegal forward reference errors - these were result of missing > this in the automatic transformation from anonymous inner to lambdas (seems > the rules are not identical - you have to add "this." as prefix if using > lambdas - not sure this is the expected way it should work) > > 5. Should we enable more -Xlint warnings in OpenJFX build? > > 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings > > 7. Probably more things I just can't think of at the moment... > > How to take this forward? If there is interest in the change I could make > available... > > Comments? Ideas? > > -Sven > > > > On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers > wrote: > > > Oh and btw - would you go for lambda with or without additional type info > > before parameter name? > > > > -Sven > > > > > > On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers >wrote: > > > >> Ok. Here you go... > >> > >> I just did an inspection run for the controls module and my IDE came up > >> with (drum roll) 888 possible lambda conversions.. > >> > >> Looking through them I discovered that usage of <> (aka diamond syntax) > >> is not used (or at least not used a lot) in at least the controls > >> modules. My IDE showed me 1171 occurrences. > >> > >> Is there a good reason not to use diamonds? > >> > >> Will now try to apply all those changes and figure out if this still > >> builds... up next: go through the other modules... > >> > >> -Sven > >> > >> > >> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair >wrote: > >> > >>> Brian was telling me at J1 that whether parallel gets you performance > or > >>> not depends on the size of the collection and the complexity of the > work to > >>> perform. There is definitely a point at which parallel helps -- and a > point > >>> at which it hurts. > >>> > >>> Richard > >>> > >>> On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: > >>> > >>> > Here is a nice example, taking advantage of the ease of going > >>> parallel. Apparently the performance without parallel will also further > >>> improve. > >>> > http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ > >>> > > >>> > Herv? > >>> > > >>> > Sent from my iPad > >>> > > >>> >> On 4 oct. 2013, at 00:20, David Grieve > >>> wrote: > >>> >> > >>> >> And what about Stream? I like the declarative code that comes from > >>> using Stream and I can see places in the code where Stream could be > used, > >>> but I wonder about its performance relative to iterators and/or > enhanced > >>> for loops. > >>> >> > >>> >> On Oct 3, 2013, at 4:45 PM, Richard Bair > >>> wrote: > >>> >> > >>> >>>> Hello, OpenJFX Community. > >>> >>>> > >>> >>>> There's a question about using Java 8 features in FX. > >>> >>>> > >>> >>>> I've been working on the support for InputMethods in JFXPanel > which > >>> is an important feature for many users who speak hieroglyphic > languages. > >>> >>>> The issue is tracked under: > >>> https://javafx-jira.kenai.com/browse/RT-13248 > >>> >>>> > >>> >>>> In order to have a high-quality support we need to change > >>> javafx.scene.input.InputMethodRequests interface and introduce 3 new > >>> methods. This is not needed for pure FX applications right now, but > >>> absolutely required for InputMethods in the JFXPanel. However, the > >>> interface is public and it was present since FX2.0, so changing it > would > >>> become a breaking change. So the only way to avoid the problem is > using the > >>> default methods. Those would return some stub values, the JDK is OK > with > >>> that, as it would not crash or throw exceptions, but text composition > would > >>> not work correctly. > >>> >>>> > >>> >>>> I know that we want to avoid using the Java 8 features in the > >>> JFX-8, so I wanted to ask - is it OK to use the default methods here? > >>> >>>> > >>> >>>> > >>> >>>> If you are staying away from JDK8 features for the JFX78 backport, > >>> don't worry. There are more issues with new JDK8 APIs than with the > new > >>> language features. > >>> >>>> > >>> >>>> For example there were default methods put into some collections > >>> classes that we solved by pushing them down to the first implements. > But > >>> the Date and Time picker depends on the new time package. The threeten > >>> backport won't be updated until after 8 ships, so that has been > removed so > >>> far. > >>> >>>> > >>> >>>> I'de be interested to know what a wholesale lamdaization would > >>> result in speed wise and code size wise (both source and compiled). > From > >>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it > jsut > >>> makes the backport more of a busy work proposition. If there were > >>> performance gains it would also make a great front page story in the > next > >>> java magazine or a case study.. > >>> >>> > >>> >>> After having used Lambda's for JavaOne, I'd love to make the > >>> conversion, even if in the end the performance was the same, because > the > >>> savings in noise in the Java files is so big. At one time I just took > the > >>> concurrent classes and lambda-ized them to measure the impact on those > >>> classes. You could maybe pick a package and just lambda-ize that one > >>> package and see what happens in terms of size reduction. We might see: > >>> >>> > >>> >>> + A reduction in the overall class size (not pack-200'd) > >>> >>> - An increase in startup time (have to spin up synthetic classes > >>> created at usage time) > >>> >>> +/- And increase or decrease in performance > >>> >>> + A decrease in source code > >>> >>> > >>> >>> It would be interesting to get some data for these points and see > >>> what effect lambda's have. Especially if an IDE can just do it in bulk? > >>> >>> > >>> >>> Richard > >>> >> > >>> > >>> > >> > >> > >> -- > >> Sven Reimers > >> > >> * Senior Expert Software Architect > >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >> * Community Leader NetBeans: http://community.java.net/netbeans > >> Desktop Java: > >> http://community.java.net/javadesktop > >> * Duke's Choice Award Winner 2009 > >> * Blog: http://nbguru.blogspot.com > >> > >> * XING: https://www.xing.com/profile/Sven_Reimers8 > >> * LinkedIn: http://www.linkedin.com/in/svenreimers > >> > >> Join the NetBeans Groups: > >> * XING: http://www.xing.com/group-20148.82db20 > >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >> http://www.linkedin.com/groups?gid=107402 > >> http://www.linkedin.com/groups?gid=1684717 > >> * Oracle: https://mix.oracle.com/groups/18497 > >> > > > > > > > > -- > > Sven Reimers > > > > * Senior Expert Software Architect > > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > > * Community Leader NetBeans: http://community.java.net/netbeans > > Desktop Java: > > http://community.java.net/javadesktop > > * Duke's Choice Award Winner 2009 > > * Blog: http://nbguru.blogspot.com > > > > * XING: https://www.xing.com/profile/Sven_Reimers8 > > * LinkedIn: http://www.linkedin.com/in/svenreimers > > > > Join the NetBeans Groups: > > * XING: http://www.xing.com/group-20148.82db20 > > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > > http://www.linkedin.com/groups?gid=107402 > > http://www.linkedin.com/groups?gid=1684717 > > * Oracle: https://mix.oracle.com/groups/18497 > > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > From hang.vo at oracle.com Sun Oct 6 18:48:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 01:48:07 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33108: CheckBoxTableCell unexpected behavior when TableView is sorted (items indexes change) Message-ID: <20131007014851.B470162DDF@hg.openjdk.java.net> Changeset: b085eb56ae11 Author: jgiles Date: 2013-10-04 15:51 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b085eb56ae11 RT-33108: CheckBoxTableCell unexpected behavior when TableView is sorted (items indexes change) ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java ! modules/controls/src/test/java/javafx/scene/control/ListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableCellTest.java From tbee at tbee.org Sun Oct 6 22:01:20 2013 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 07 Oct 2013 07:01:20 +0200 Subject: Keyboard events In-Reply-To: References: Message-ID: <52524020.10904@tbee.org> If I remember correctly, in Swing I solved something similar by setting a generic keyboard listener to the frame and then determine on shift-press what component the mouse was over using the coordinates. Maybe that works here as well. Tom On 2013-10-07 00:40, Pedro Duque Vieira wrote: > Hi, > > I have the following use case: > When the user presses shift and the mouse is hover the chart component the > cursor must change to an open hand cursor signaling to the user that the > chart is ready for a panning action. > The problem is that for this to be possible I want the chart to be able to > listen to keyboard events even when it doesn't have focus. > > I think this is not possible and I wonder why. Swing was the same, you > could only listen to keyboard events if the control had focus. Is this a > technical limitation? If there is no technical limitation I think it would > be better to remove this restriction, I think it is limiting and the above > scenario is a good use case to show that. > > Thanks, best regards, > From hang.vo at oracle.com Sun Oct 6 23:03:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 06:03:15 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing Message-ID: <20131007060331.2E93B62DE3@hg.openjdk.java.net> Changeset: 0e6e79ce4263 Author: Alexander Kouznetsov Date: 2013-10-07 10:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0e6e79ce4263 Ensemble8: Fix for RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePage.java ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/BouncingBallsApp.java From hang.vo at oracle.com Sun Oct 6 23:48:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 06:48:01 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Additional fix for RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing Message-ID: <20131007064835.4E6AF62DE6@hg.openjdk.java.net> Changeset: 84878f14f71b Author: Alexander Kouznetsov Date: 2013-10-07 10:37 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/84878f14f71b Ensemble8: Additional fix for RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing ! apps/samples/Ensemble8/src/compiletime/java/ensemble/compiletime/BuildSamplesList.java ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java From hang.vo at oracle.com Mon Oct 7 00:03:40 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 07:03:40 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Samples.java cleanup (Removed ".save" files, fixed "B?zier") Message-ID: <20131007070356.6181362DE7@hg.openjdk.java.net> Changeset: a554b76b5ee6 Author: Alexander Kouznetsov Date: 2013-10-07 10:49 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a554b76b5ee6 Ensemble8: Samples.java cleanup (Removed ".save" files, fixed "B?zier") ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java From tobi at ultramixer.com Mon Oct 7 00:26:34 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 7 Oct 2013 09:26:34 +0200 Subject: JavaFX on Android: JavaSELauncher? References: <0A87CF81-6950-47FF-A9FB-49B2691AAF4A@ultramixer.com> Message-ID: <5B59E376-3C1E-442C-8E2D-B2441F0127BD@ultramixer.com> Next try :) @Oracle: which JVM uses the new JavaSELauncher class in the com.oracle.dalvik package? How to use this class to start JFX on Android? Best, Tobi Anfang der weitergeleiteten Nachricht: > Von: Tobias Bley > Betreff: JavaFX on Android: JavaSELauncher? > Datum: 1. Oktober 2013 11:29:12 MESZ > An: "openjfx-dev at openjdk.java.net Mailing" > > @Oracle: > > which JVM uses the new JavaSELauncher class in the com.oracle.dalvik package? How to use this class to start JFX on Android? > > Best, > Tobi > From hang.vo at oracle.com Mon Oct 7 00:58:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 07:58:05 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Explicitly specify UTF-8 encoding for streams in code generation phase. Message-ID: <20131007075831.4C86B62DEA@hg.openjdk.java.net> Changeset: 93c09655d6a8 Author: Alexander Kouznetsov Date: 2013-10-07 11:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/93c09655d6a8 Ensemble8: Explicitly specify UTF-8 encoding for streams in code generation phase. ! apps/samples/Ensemble8/src/compiletime/java/ensemble/compiletime/BuildSamplesList.java From hang.vo at oracle.com Mon Oct 7 02:17:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 09:17:54 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131007091852.6E0F462DED@hg.openjdk.java.net> Changeset: b275a99ef7f5 Author: Alexander Kouznetsov Date: 2013-10-07 13:10 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b275a99ef7f5 Ensemble8: Removed builders from PlaygroundTabs.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/PlaygroundTabs.java Changeset: 70b8c27e00e0 Author: Alexander Kouznetsov Date: 2013-10-07 13:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/70b8c27e00e0 Ensemble8: Guarded XYDataVisualizer against NPEs. ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/XYDataVisualizer.java From hang.vo at oracle.com Mon Oct 7 02:32:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 09:32:57 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Removed builders from XYDataVisualizer.java. Message-ID: <20131007093535.0EC7462DEF@hg.openjdk.java.net> Changeset: 77c02e6ffbe6 Author: Alexander Kouznetsov Date: 2013-10-07 13:26 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/77c02e6ffbe6 Ensemble8: Removed builders from XYDataVisualizer.java. ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/XYDataVisualizer.java From hang.vo at oracle.com Mon Oct 7 03:32:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 10:32:42 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28763 FB: Rename LensApplication.startNativeEventLoop() to nativeEventLoop() Message-ID: <20131007103316.5BED062DF1@hg.openjdk.java.net> Changeset: b20673c09b07 Author: Daniel Blaukopf Date: 2013-10-07 13:25 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b20673c09b07 RT-28763 FB: Rename LensApplication.startNativeEventLoop() to nativeEventLoop() Summary: Cosmetic change so that a more appropriate function name shows up in logs Reviewed-by: Assaf Yavnai, Rafi Tayar ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java ! modules/graphics/src/main/native-glass/lens/LensApplication.c From artem.ananiev at oracle.com Mon Oct 7 03:56:00 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 07 Oct 2013 14:56:00 +0400 Subject: Keyboard events In-Reply-To: References: Message-ID: <52529340.4080205@oracle.com> On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: > Hi, > > I have the following use case: > When the user presses shift and the mouse is hover the chart component the > cursor must change to an open hand cursor signaling to the user that the > chart is ready for a panning action. > The problem is that for this to be possible I want the chart to be able to > listen to keyboard events even when it doesn't have focus. > > I think this is not possible and I wonder why. Swing was the same, you > could only listen to keyboard events if the control had focus. Is this a > technical limitation? If there is no technical limitation I think it would > be better to remove this restriction, I think it is limiting and the above > scenario is a good use case to show that. This is not a technical limitation, it's just the way how it's supposed to work. All the key events are dispatched to the component in focus, this is what input focus is. Scenario you described should be easier to implement in FX than in Swing. In AWT/Swing, input events are dispatched to a single component, while FX is much more flexible. All the events are delivered to a Scene first, then dispatched to the focused component (or component under mouse, for mouse events), then bubbled up back to the Scene. What you need is to register a custom event filter for the scene and listen to all the key events. See Scene.addEventFilter() and Scene.addEventHandler() for details. Thanks, Artem > Thanks, best regards, > From hang.vo at oracle.com Mon Oct 7 04:17:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 11:17:43 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-30138 Ensemble8: Stacked Bar Chart: class cast exception Message-ID: <20131007111815.2BCF962DF5@hg.openjdk.java.net> Changeset: 093616690092 Author: Alexander Kouznetsov Date: 2013-10-07 15:02 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/093616690092 Ensemble8: Fix for RT-30138 Ensemble8: Stacked Bar Chart: class cast exception ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/XYDataVisualizer.java From kevin.rushforth at oracle.com Mon Oct 7 04:26:44 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Oct 2013 04:26:44 -0700 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> Message-ID: <52529A74.9080500@oracle.com> > > 5. Should we enable more -Xlint warnings in OpenJFX build? > > 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and getting rid of warnings would be a P4 bug. I guess it depends on how intrusive the changes are and whether someone has time to review it in the next two weeks. -- Kevin Sven Reimers wrote: > Ok. So here are the results of trying to add lambda and diamond to the > controls module: > > 1. A lot of generics and typing to be fixed (esp. in tests). Seems you can > get some anonymous inner classes type checked by the compiler, but not the > lambda equivalent.. very interesting. > > 2. 279 Files modified (including tests) > > 3. A lot of the automatic replacements could probably be nicer e.g. > > ft.setOnFinished(new EventHandler() { > @Override public void handle(ActionEvent > actionEvent) { > getChildren().remove(tm.textNode); > } > }); > > was replaced to: > > ft.setOnFinished((ActionEvent actionEvent) -> { > getChildren().remove(tm.textNode); > }); > > most unobtrusive code probably: > > ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); > > 4. A lot of illegal forward reference errors - these were result of missing > this in the automatic transformation from anonymous inner to lambdas (seems > the rules are not identical - you have to add "this." as prefix if using > lambdas - not sure this is the expected way it should work) > > 5. Should we enable more -Xlint warnings in OpenJFX build? > > 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings > > 7. Probably more things I just can't think of at the moment... > > How to take this forward? If there is interest in the change I could make > available... > > Comments? Ideas? > > -Sven > > > > On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers wrote: > > >> Oh and btw - would you go for lambda with or without additional type info >> before parameter name? >> >> -Sven >> >> >> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers wrote: >> >> >>> Ok. Here you go... >>> >>> I just did an inspection run for the controls module and my IDE came up >>> with (drum roll) 888 possible lambda conversions.. >>> >>> Looking through them I discovered that usage of <> (aka diamond syntax) >>> is not used (or at least not used a lot) in at least the controls >>> modules. My IDE showed me 1171 occurrences. >>> >>> Is there a good reason not to use diamonds? >>> >>> Will now try to apply all those changes and figure out if this still >>> builds... up next: go through the other modules... >>> >>> -Sven >>> >>> >>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote: >>> >>> >>>> Brian was telling me at J1 that whether parallel gets you performance or >>>> not depends on the size of the collection and the complexity of the work to >>>> perform. There is definitely a point at which parallel helps -- and a point >>>> at which it hurts. >>>> >>>> Richard >>>> >>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: >>>> >>>> >>>>> Here is a nice example, taking advantage of the ease of going >>>>> >>>> parallel. Apparently the performance without parallel will also further >>>> improve. >>>> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >>>> >>>>> Herv? >>>>> >>>>> Sent from my iPad >>>>> >>>>> >>>>>> On 4 oct. 2013, at 00:20, David Grieve >>>>>> >>>> wrote: >>>> >>>>>> And what about Stream? I like the declarative code that comes from >>>>>> >>>> using Stream and I can see places in the code where Stream could be used, >>>> but I wonder about its performance relative to iterators and/or enhanced >>>> for loops. >>>> >>>>>> On Oct 3, 2013, at 4:45 PM, Richard Bair >>>>>> >>>> wrote: >>>> >>>>>>>> Hello, OpenJFX Community. >>>>>>>> >>>>>>>> There's a question about using Java 8 features in FX. >>>>>>>> >>>>>>>> I've been working on the support for InputMethods in JFXPanel which >>>>>>>> >>>> is an important feature for many users who speak hieroglyphic languages. >>>> >>>>>>>> The issue is tracked under: >>>>>>>> >>>> https://javafx-jira.kenai.com/browse/RT-13248 >>>> >>>>>>>> In order to have a high-quality support we need to change >>>>>>>> >>>> javafx.scene.input.InputMethodRequests interface and introduce 3 new >>>> methods. This is not needed for pure FX applications right now, but >>>> absolutely required for InputMethods in the JFXPanel. However, the >>>> interface is public and it was present since FX2.0, so changing it would >>>> become a breaking change. So the only way to avoid the problem is using the >>>> default methods. Those would return some stub values, the JDK is OK with >>>> that, as it would not crash or throw exceptions, but text composition would >>>> not work correctly. >>>> >>>>>>>> I know that we want to avoid using the Java 8 features in the >>>>>>>> >>>> JFX-8, so I wanted to ask - is it OK to use the default methods here? >>>> >>>>>>>> If you are staying away from JDK8 features for the JFX78 backport, >>>>>>>> >>>> don't worry. There are more issues with new JDK8 APIs than with the new >>>> language features. >>>> >>>>>>>> For example there were default methods put into some collections >>>>>>>> >>>> classes that we solved by pushing them down to the first implements. But >>>> the Date and Time picker depends on the new time package. The threeten >>>> backport won't be updated until after 8 ships, so that has been removed so >>>> far. >>>> >>>>>>>> I'de be interested to know what a wholesale lamdaization would >>>>>>>> >>>> result in speed wise and code size wise (both source and compiled). From >>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut >>>> makes the backport more of a busy work proposition. If there were >>>> performance gains it would also make a great front page story in the next >>>> java magazine or a case study.. >>>> >>>>>>> After having used Lambda's for JavaOne, I'd love to make the >>>>>>> >>>> conversion, even if in the end the performance was the same, because the >>>> savings in noise in the Java files is so big. At one time I just took the >>>> concurrent classes and lambda-ized them to measure the impact on those >>>> classes. You could maybe pick a package and just lambda-ize that one >>>> package and see what happens in terms of size reduction. We might see: >>>> >>>>>>> + A reduction in the overall class size (not pack-200'd) >>>>>>> - An increase in startup time (have to spin up synthetic classes >>>>>>> >>>> created at usage time) >>>> >>>>>>> +/- And increase or decrease in performance >>>>>>> + A decrease in source code >>>>>>> >>>>>>> It would be interesting to get some data for these points and see >>>>>>> >>>> what effect lambda's have. Especially if an IDE can just do it in bulk? >>>> >>>>>>> Richard >>>>>>> >>>> >>> -- >>> Sven Reimers >>> >>> * Senior Expert Software Architect >>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> * Community Leader NetBeans: http://community.java.net/netbeans >>> Desktop Java: >>> http://community.java.net/javadesktop >>> * Duke's Choice Award Winner 2009 >>> * Blog: http://nbguru.blogspot.com >>> >>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >>> Join the NetBeans Groups: >>> * XING: http://www.xing.com/group-20148.82db20 >>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>> http://www.linkedin.com/groups?gid=107402 >>> http://www.linkedin.com/groups?gid=1684717 >>> * Oracle: https://mix.oracle.com/groups/18497 >>> >>> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java: >> http://community.java.net/javadesktop >> * Duke's Choice Award Winner 2009 >> * Blog: http://nbguru.blogspot.com >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> Join the NetBeans Groups: >> * XING: http://www.xing.com/group-20148.82db20 >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> http://www.linkedin.com/groups?gid=107402 >> http://www.linkedin.com/groups?gid=1684717 >> * Oracle: https://mix.oracle.com/groups/18497 >> >> > > > > From hang.vo at oracle.com Mon Oct 7 04:32:41 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 11:32:41 +0000 Subject: hg: openjfx/8/graphics/rt: Ensemble8: Additional fix for RT-31427 Cursor sample in Ensemble8 doesn't look well with latest Lombard bits Message-ID: <20131007113326.A747C62DF6@hg.openjdk.java.net> Changeset: 8f1dc4526871 Author: Alexander Kouznetsov Date: 2013-10-07 15:20 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8f1dc4526871 Ensemble8: Additional fix for RT-31427 Cursor sample in Ensemble8 doesn't look well with latest Lombard bits ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/events/cursor/CursorApp.java From hang.vo at oracle.com Mon Oct 7 04:47:39 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 11:47:39 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28495: Implement Platform.isSupported(INPUT_METHOD) Message-ID: <20131007114811.E8E4C62DF9@hg.openjdk.java.net> Changeset: cee9deb1d5e9 Author: art Date: 2013-10-07 15:40 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cee9deb1d5e9 RT-28495: Implement Platform.isSupported(INPUT_METHOD) Reviewed-by: kcr, snorthov ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java ! modules/graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinApplication.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java From eric.le.ponner at oracle.com Mon Oct 7 05:48:00 2013 From: eric.le.ponner at oracle.com (Eric Le Ponner) Date: Mon, 7 Oct 2013 14:48:00 +0200 Subject: Cylinder divisions and PerspectiveCamera fixedEyePosition should be mutable Message-ID: <879D1EAF-F059-4689-A95C-A3C126BC44D2@oracle.com> As long as Cylinder/divisions/PerspectiveCamera/fixedEyePosition can be encoded in FXML, that should be fine for Scene Builder. Having setters for those properties can be a way to optimize previewing. But it's not mandatory. Eric > Date: Fri, 04 Oct 2013 14:10:43 -0700 > From: Kevin Rushforth > Subject: Re: Cylinder divisions and PerspectiveCamera fixedEyePosition > should be mutable > To: Richard Bair > Cc: "openjfx-dev at openjdk.java.net list" > Message-ID: <524F2ED3.7060002 at oracle.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Sounds good. > > >> Depends on whether it is usable from SceneBuilder and FXML, and the >> following: >> - We must *not* expose a ReadOnly property for these properties >> (and I don't think we do) > > No, we don't. > >> - The FXML changes must be backwards compatible (they should be but >> we need to verify) > > I'll add a note to the JIRA and the FXML folks can reply. > > >> - The SceneBuilder can do something reasonable as is (not sure). > > Chien or I can reach out to the SB team. > > -- Kevin > > > Richard Bair wrote: >> Depends on whether it is usable from SceneBuilder and FXML, and the >> following: >> - We must *not* expose a ReadOnly property for these properties >> (and I don't think we do) >> - The FXML changes must be backwards compatible (they should be but >> we need to verify) >> - The SceneBuilder can do something reasonable as is (not sure). >> >> Richard >> >> On Oct 4, 2013, at 1:08 PM, Kevin Rushforth >> > wrote: >> >>> Certainly for divisions there is no reason to keep them immutable. >>> For fixedEyeAtCameraZero, I don't think the reasons for keeping it >>> immutable are compelling. >>> >>> Making either change in FX 8 is a different matter, though, given how >>> late we are. The implementation assumes immutability and we would >>> need to change it, implement it, test it, and then fix any bugs as a >>> result. Seems like we could add mutability in a subsequent release. >>> >>> -- Kevin >>> >>> >>> Richard Bair wrote: >>>> I would turn that around and say that unless there is a compelling reason for something to be immutable, it should be mutable. Mutability is important for tools as well as for FXML as well as for developers. >>>> >>>> Immutable state is awesome for thread-safety or any type of concurrency. But these types of classes are not of that nature, they're UI only classes, and as such their state should be mutable (and like all mutable state in FX, the range of possible values should not be hindered by the evil "unbind" pattern). >>>> >>>> Richard >>>> >>>> On Oct 4, 2013, at 12:46 PM, Kevin Rushforth wrote: >>>> >>>> >>>>> Yes, that pretty much captures the thinking behind it. >>>>> >>>>> My thought is that there is no real reason that subdivisions need to be immutable, although I wouldn't want to change it at this late date for FX 8 unless it is needed for FXML support. >>>>> >>>>> The fixedEyeAtCameraZero mode is not something I think should be mutable, since the camera behaves fairly differently in each mode. Having said that, there is no reason it couldn't be made mutable in a subsequent release if there was a good reason to do so. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Chien Yang wrote: >>>>> >>>>>> We did discuss making divisions in the predefined 3D shapes mutable in earlier meeting. However we decided against it since it is a heavy weight operation as the supporting mesh will has to be regenerated. I believe the constructor with the divisions argument will not have much use in the future when we move away from mesh implementation of our predefined 3D shapes. >>>>>> >>>>>> The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the camera and once set it shouldn't be changed. The perspective projection matrix is constructed differently depending on the flag. In the default mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that simple adding of 3D shapes into a 2D scene looks intuitive. The other mode, where eye is fixed a camera zero, is well suitable for movable camera in the 3d space. >>>>>> >>>>>> - Chien >>>>>> >>>>>> On 10/4/2013 9:28 AM, Richard Bair wrote: >>>>>> >>>>>>> Why are they not? It isn't immediately obvious to me why these are not mutable? I was readinghttps://javafx-jira.kenai.com/browse/RT-29577 and this struck me as odd. >>>>>>> >>>>>>> Richard >>>>>>> >>>> >>>> >> > From hang.vo at oracle.com Mon Oct 7 05:47:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 12:47:46 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: PiscesRenderer refactoring (RT-32170) Message-ID: <20131007124836.4482A62DFE@hg.openjdk.java.net> Changeset: 70451c5d10df Author: Martin Soch Date: 2013-10-07 14:44 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/70451c5d10df SW pipeline: PiscesRenderer refactoring (RT-32170) ! modules/graphics/src/main/java/com/sun/pisces/PiscesRenderer.java ! modules/graphics/src/main/native-prism-sw/JPiscesRenderer.c From tomas.mikula at gmail.com Mon Oct 7 06:48:14 2013 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 7 Oct 2013 15:48:14 +0200 Subject: [announce] CodeAreaFX: text area with styled ranges of text Message-ID: Hi all, I implemented a text control that supports assigning style classes to portions of text. It is meant to be used for syntax highlighting. https://github.com/TomasMikula/CodeAreaFX The code is based on the original TextArea code. This implies the license to be GPLv2 with the Classpath Exception. I would be happy to contribute it back to the OpenJFX project. The idea of using a ListView of TextFlows is borrowed from Tom Schindl's StyledTextArea (http://fxexperience.com/2013/02/interview-with-tom-schindl-2/). Check out the demos and the APIs. Feedback really appreciated. Any help with the issues (https://github.com/TomasMikula/CodeAreaFX/wiki/Known-Issues) would be awesome. Best, Tomas From sven.reimers at gmail.com Mon Oct 7 07:16:33 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 7 Oct 2013 16:16:33 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: <52529A74.9080500@oracle.com> References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> Message-ID: Ok. So I will file a P4 saying Lambdafication for Controls and send the diff to Richard/Kevin/Jonathan to be attached.. should I base the change on b110 (master)? I could create a public bitbucket branch based on master and add my changes there - better idea? What approach is most simple for review? Should I split test and library code changes? -Sven P.S. Shall I try to get this done as well for other modules? Which would be preferred? (Just in case I have some more time to spend) On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth wrote: > ** > > 5. Should we enable more -Xlint warnings in OpenJFX build? > > 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings > > > We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and > getting rid of warnings would be a P4 bug. I guess it depends on how > intrusive the changes are and whether someone has time to review it in the > next two weeks. > > -- Kevin > > > > > Sven Reimers wrote: > > Ok. So here are the results of trying to add lambda and diamond to the > controls module: > > 1. A lot of generics and typing to be fixed (esp. in tests). Seems you can > get some anonymous inner classes type checked by the compiler, but not the > lambda equivalent.. very interesting. > > 2. 279 Files modified (including tests) > > 3. A lot of the automatic replacements could probably be nicer e.g. > > ft.setOnFinished(new EventHandler() { > @Override public void handle(ActionEvent > actionEvent) { > getChildren().remove(tm.textNode); > } > }); > > was replaced to: > > ft.setOnFinished((ActionEvent actionEvent) -> { > getChildren().remove(tm.textNode); > }); > > most unobtrusive code probably: > > ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); > > 4. A lot of illegal forward reference errors - these were result of missing > this in the automatic transformation from anonymous inner to lambdas (seems > the rules are not identical - you have to add "this." as prefix if using > lambdas - not sure this is the expected way it should work) > > 5. Should we enable more -Xlint warnings in OpenJFX build? > > 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings > > 7. Probably more things I just can't think of at the moment... > > How to take this forward? If there is interest in the change I could make > available... > > Comments? Ideas? > > -Sven > > > > On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers wrote: > > > > Oh and btw - would you go for lambda with or without additional type info > before parameter name? > > -Sven > > > On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers wrote: > > > > Ok. Here you go... > > I just did an inspection run for the controls module and my IDE came up > with (drum roll) 888 possible lambda conversions.. > > Looking through them I discovered that usage of <> (aka diamond syntax) > is not used (or at least not used a lot) in at least the controls > modules. My IDE showed me 1171 occurrences. > > Is there a good reason not to use diamonds? > > Will now try to apply all those changes and figure out if this still > builds... up next: go through the other modules... > > -Sven > > > On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote: > > > > Brian was telling me at J1 that whether parallel gets you performance or > not depends on the size of the collection and the complexity of the work to > perform. There is definitely a point at which parallel helps -- and a point > at which it hurts. > > Richard > > On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: > > > > Here is a nice example, taking advantage of the ease of going > > > parallel. Apparently the performance without parallel will also further > improve.http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ > > Herv? > > Sent from my iPad > > > > On 4 oct. 2013, at 00:20, David Grieve > > wrote: > > > And what about Stream? I like the declarative code that comes from > > > using Stream and I can see places in the code where Stream could be used, > but I wonder about its performance relative to iterators and/or enhanced > for loops. > > > On Oct 3, 2013, at 4:45 PM, Richard Bair > > wrote: > > > Hello, OpenJFX Community. > > There's a question about using Java 8 features in FX. > > I've been working on the support for InputMethods in JFXPanel which > > > is an important feature for many users who speak hieroglyphic languages. > > > The issue is tracked under: > > > https://javafx-jira.kenai.com/browse/RT-13248 > > In order to have a high-quality support we need to change > > > javafx.scene.input.InputMethodRequests interface and introduce 3 new > methods. This is not needed for pure FX applications right now, but > absolutely required for InputMethods in the JFXPanel. However, the > interface is public and it was present since FX2.0, so changing it would > become a breaking change. So the only way to avoid the problem is using the > default methods. Those would return some stub values, the JDK is OK with > that, as it would not crash or throw exceptions, but text composition would > not work correctly. > > > I know that we want to avoid using the Java 8 features in the > > > JFX-8, so I wanted to ask - is it OK to use the default methods here? > > > If you are staying away from JDK8 features for the JFX78 backport, > > > don't worry. There are more issues with new JDK8 APIs than with the new > language features. > > > For example there were default methods put into some collections > > > classes that we solved by pushing them down to the first implements. But > the Date and Time picker depends on the new time package. The threeten > backport won't be updated until after 8 ships, so that has been removed so > far. > > > I'de be interested to know what a wholesale lamdaization would > > > result in speed wise and code size wise (both source and compiled). From > what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut > makes the backport more of a busy work proposition. If there were > performance gains it would also make a great front page story in the next > java magazine or a case study.. > > > After having used Lambda's for JavaOne, I'd love to make the > > > conversion, even if in the end the performance was the same, because the > savings in noise in the Java files is so big. At one time I just took the > concurrent classes and lambda-ized them to measure the impact on those > classes. You could maybe pick a package and just lambda-ize that one > package and see what happens in terms of size reduction. We might see: > > > + A reduction in the overall class size (not pack-200'd) > - An increase in startup time (have to spin up synthetic classes > > > created at usage time) > > > +/- And increase or decrease in performance > + A decrease in source code > > It would be interesting to get some data for these points and see > > > what effect lambda's have. Especially if an IDE can just do it in bulk? > > > Richard > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java:http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java:http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From tom.schindl at bestsolution.at Mon Oct 7 07:21:51 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 07 Oct 2013 16:21:51 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> Message-ID: <5252C37F.5030506@bestsolution.at> ... I can't see any real improvement for using lambdas beside that you killed off warnings which could be fixed otherwise as well. So I really don't get what it would help us beside making e.g. RoboVM our sole chance to get FX on iOS harder to maintain. Tom On 07.10.13 16:16, Sven Reimers wrote: > Ok. So I will file a P4 saying Lambdafication for Controls > and send the diff to Richard/Kevin/Jonathan to be attached.. > > should I base the change on b110 (master)? > > I could create a public bitbucket branch based on master and add my changes > there - better idea? > > What approach is most simple for review? > > Should I split test and library code changes? > > -Sven > > P.S. Shall I try to get this done as well for other modules? Which would be > preferred? (Just in case I have some more time to spend) > > > > On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth > wrote: > >> ** >> >> 5. Should we enable more -Xlint warnings in OpenJFX build? >> >> 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings >> >> >> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and >> getting rid of warnings would be a P4 bug. I guess it depends on how >> intrusive the changes are and whether someone has time to review it in the >> next two weeks. >> >> -- Kevin >> >> >> >> >> Sven Reimers wrote: >> >> Ok. So here are the results of trying to add lambda and diamond to the >> controls module: >> >> 1. A lot of generics and typing to be fixed (esp. in tests). Seems you can >> get some anonymous inner classes type checked by the compiler, but not the >> lambda equivalent.. very interesting. >> >> 2. 279 Files modified (including tests) >> >> 3. A lot of the automatic replacements could probably be nicer e.g. >> >> ft.setOnFinished(new EventHandler() { >> @Override public void handle(ActionEvent >> actionEvent) { >> getChildren().remove(tm.textNode); >> } >> }); >> >> was replaced to: >> >> ft.setOnFinished((ActionEvent actionEvent) -> { >> getChildren().remove(tm.textNode); >> }); >> >> most unobtrusive code probably: >> >> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); >> >> 4. A lot of illegal forward reference errors - these were result of missing >> this in the automatic transformation from anonymous inner to lambdas (seems >> the rules are not identical - you have to add "this." as prefix if using >> lambdas - not sure this is the expected way it should work) >> >> 5. Should we enable more -Xlint warnings in OpenJFX build? >> >> 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings >> >> 7. Probably more things I just can't think of at the moment... >> >> How to take this forward? If there is interest in the change I could make >> available... >> >> Comments? Ideas? >> >> -Sven >> >> >> >> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers wrote: >> >> >> >> Oh and btw - would you go for lambda with or without additional type info >> before parameter name? >> >> -Sven >> >> >> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers wrote: >> >> >> >> Ok. Here you go... >> >> I just did an inspection run for the controls module and my IDE came up >> with (drum roll) 888 possible lambda conversions.. >> >> Looking through them I discovered that usage of <> (aka diamond syntax) >> is not used (or at least not used a lot) in at least the controls >> modules. My IDE showed me 1171 occurrences. >> >> Is there a good reason not to use diamonds? >> >> Will now try to apply all those changes and figure out if this still >> builds... up next: go through the other modules... >> >> -Sven >> >> >> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote: >> >> >> >> Brian was telling me at J1 that whether parallel gets you performance or >> not depends on the size of the collection and the complexity of the work to >> perform. There is definitely a point at which parallel helps -- and a point >> at which it hurts. >> >> Richard >> >> On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: >> >> >> >> Here is a nice example, taking advantage of the ease of going >> >> >> parallel. Apparently the performance without parallel will also further >> improve.http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >> >> Herv? >> >> Sent from my iPad >> >> >> >> On 4 oct. 2013, at 00:20, David Grieve >> >> wrote: >> >> >> And what about Stream? I like the declarative code that comes from >> >> >> using Stream and I can see places in the code where Stream could be used, >> but I wonder about its performance relative to iterators and/or enhanced >> for loops. >> >> >> On Oct 3, 2013, at 4:45 PM, Richard Bair >> >> wrote: >> >> >> Hello, OpenJFX Community. >> >> There's a question about using Java 8 features in FX. >> >> I've been working on the support for InputMethods in JFXPanel which >> >> >> is an important feature for many users who speak hieroglyphic languages. >> >> >> The issue is tracked under: >> >> >> https://javafx-jira.kenai.com/browse/RT-13248 >> >> In order to have a high-quality support we need to change >> >> >> javafx.scene.input.InputMethodRequests interface and introduce 3 new >> methods. This is not needed for pure FX applications right now, but >> absolutely required for InputMethods in the JFXPanel. However, the >> interface is public and it was present since FX2.0, so changing it would >> become a breaking change. So the only way to avoid the problem is using the >> default methods. Those would return some stub values, the JDK is OK with >> that, as it would not crash or throw exceptions, but text composition would >> not work correctly. >> >> >> I know that we want to avoid using the Java 8 features in the >> >> >> JFX-8, so I wanted to ask - is it OK to use the default methods here? >> >> >> If you are staying away from JDK8 features for the JFX78 backport, >> >> >> don't worry. There are more issues with new JDK8 APIs than with the new >> language features. >> >> >> For example there were default methods put into some collections >> >> >> classes that we solved by pushing them down to the first implements. But >> the Date and Time picker depends on the new time package. The threeten >> backport won't be updated until after 8 ships, so that has been removed so >> far. >> >> >> I'de be interested to know what a wholesale lamdaization would >> >> >> result in speed wise and code size wise (both source and compiled). From >> what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut >> makes the backport more of a busy work proposition. If there were >> performance gains it would also make a great front page story in the next >> java magazine or a case study.. >> >> >> After having used Lambda's for JavaOne, I'd love to make the >> >> >> conversion, even if in the end the performance was the same, because the >> savings in noise in the Java files is so big. At one time I just took the >> concurrent classes and lambda-ized them to measure the impact on those >> classes. You could maybe pick a package and just lambda-ize that one >> package and see what happens in terms of size reduction. We might see: >> >> >> + A reduction in the overall class size (not pack-200'd) >> - An increase in startup time (have to spin up synthetic classes >> >> >> created at usage time) >> >> >> +/- And increase or decrease in performance >> + A decrease in source code >> >> It would be interesting to get some data for these points and see >> >> >> what effect lambda's have. Especially if an IDE can just do it in bulk? >> >> >> Richard >> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java:http://community.java.net/javadesktop >> * Duke's Choice Award Winner 2009 >> * Blog: http://nbguru.blogspot.com >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> Join the NetBeans Groups: >> * XING: http://www.xing.com/group-20148.82db20 >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> http://www.linkedin.com/groups?gid=107402 >> http://www.linkedin.com/groups?gid=1684717 >> * Oracle: https://mix.oracle.com/groups/18497 >> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java:http://community.java.net/javadesktop >> * Duke's Choice Award Winner 2009 >> * Blog: http://nbguru.blogspot.com >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> Join the NetBeans Groups: >> * XING: http://www.xing.com/group-20148.82db20 >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> http://www.linkedin.com/groups?gid=107402 >> http://www.linkedin.com/groups?gid=1684717 >> * Oracle: https://mix.oracle.com/groups/18497 >> >> >> >> > > From steve.x.northover at oracle.com Mon Oct 7 07:45:23 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Mon, 07 Oct 2013 10:45:23 -0400 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: <5252C37F.5030506@bestsolution.at> References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: <5252C903.4040001@oracle.com> It is still interesting to see the results and compare with the non-lambda version. Steve On 2013-10-07 10:21 AM, Tom Schindl wrote: > ... I can't see any real improvement for using lambdas beside that you > killed off warnings which could be fixed otherwise as well. > > So I really don't get what it would help us beside making e.g. RoboVM > our sole chance to get FX on iOS harder to maintain. > > Tom > > On 07.10.13 16:16, Sven Reimers wrote: >> Ok. So I will file a P4 saying Lambdafication for Controls >> and send the diff to Richard/Kevin/Jonathan to be attached.. >> >> should I base the change on b110 (master)? >> >> I could create a public bitbucket branch based on master and add my changes >> there - better idea? >> >> What approach is most simple for review? >> >> Should I split test and library code changes? >> >> -Sven >> >> P.S. Shall I try to get this done as well for other modules? Which would be >> preferred? (Just in case I have some more time to spend) >> >> >> >> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth >> wrote: >> >>> ** >>> >>> 5. Should we enable more -Xlint warnings in OpenJFX build? >>> >>> 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings >>> >>> >>> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and >>> getting rid of warnings would be a P4 bug. I guess it depends on how >>> intrusive the changes are and whether someone has time to review it in the >>> next two weeks. >>> >>> -- Kevin >>> >>> >>> >>> >>> Sven Reimers wrote: >>> >>> Ok. So here are the results of trying to add lambda and diamond to the >>> controls module: >>> >>> 1. A lot of generics and typing to be fixed (esp. in tests). Seems you can >>> get some anonymous inner classes type checked by the compiler, but not the >>> lambda equivalent.. very interesting. >>> >>> 2. 279 Files modified (including tests) >>> >>> 3. A lot of the automatic replacements could probably be nicer e.g. >>> >>> ft.setOnFinished(new EventHandler() { >>> @Override public void handle(ActionEvent >>> actionEvent) { >>> getChildren().remove(tm.textNode); >>> } >>> }); >>> >>> was replaced to: >>> >>> ft.setOnFinished((ActionEvent actionEvent) -> { >>> getChildren().remove(tm.textNode); >>> }); >>> >>> most unobtrusive code probably: >>> >>> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); >>> >>> 4. A lot of illegal forward reference errors - these were result of missing >>> this in the automatic transformation from anonymous inner to lambdas (seems >>> the rules are not identical - you have to add "this." as prefix if using >>> lambdas - not sure this is the expected way it should work) >>> >>> 5. Should we enable more -Xlint warnings in OpenJFX build? >>> >>> 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings >>> >>> 7. Probably more things I just can't think of at the moment... >>> >>> How to take this forward? If there is interest in the change I could make >>> available... >>> >>> Comments? Ideas? >>> >>> -Sven >>> >>> >>> >>> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers wrote: >>> >>> >>> >>> Oh and btw - would you go for lambda with or without additional type info >>> before parameter name? >>> >>> -Sven >>> >>> >>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers wrote: >>> >>> >>> >>> Ok. Here you go... >>> >>> I just did an inspection run for the controls module and my IDE came up >>> with (drum roll) 888 possible lambda conversions.. >>> >>> Looking through them I discovered that usage of <> (aka diamond syntax) >>> is not used (or at least not used a lot) in at least the controls >>> modules. My IDE showed me 1171 occurrences. >>> >>> Is there a good reason not to use diamonds? >>> >>> Will now try to apply all those changes and figure out if this still >>> builds... up next: go through the other modules... >>> >>> -Sven >>> >>> >>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote: >>> >>> >>> >>> Brian was telling me at J1 that whether parallel gets you performance or >>> not depends on the size of the collection and the complexity of the work to >>> perform. There is definitely a point at which parallel helps -- and a point >>> at which it hurts. >>> >>> Richard >>> >>> On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: >>> >>> >>> >>> Here is a nice example, taking advantage of the ease of going >>> >>> >>> parallel. Apparently the performance without parallel will also further >>> improve.http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >>> >>> Herv? >>> >>> Sent from my iPad >>> >>> >>> >>> On 4 oct. 2013, at 00:20, David Grieve >>> >>> wrote: >>> >>> >>> And what about Stream? I like the declarative code that comes from >>> >>> >>> using Stream and I can see places in the code where Stream could be used, >>> but I wonder about its performance relative to iterators and/or enhanced >>> for loops. >>> >>> >>> On Oct 3, 2013, at 4:45 PM, Richard Bair >>> >>> wrote: >>> >>> >>> Hello, OpenJFX Community. >>> >>> There's a question about using Java 8 features in FX. >>> >>> I've been working on the support for InputMethods in JFXPanel which >>> >>> >>> is an important feature for many users who speak hieroglyphic languages. >>> >>> >>> The issue is tracked under: >>> >>> >>> https://javafx-jira.kenai.com/browse/RT-13248 >>> >>> In order to have a high-quality support we need to change >>> >>> >>> javafx.scene.input.InputMethodRequests interface and introduce 3 new >>> methods. This is not needed for pure FX applications right now, but >>> absolutely required for InputMethods in the JFXPanel. However, the >>> interface is public and it was present since FX2.0, so changing it would >>> become a breaking change. So the only way to avoid the problem is using the >>> default methods. Those would return some stub values, the JDK is OK with >>> that, as it would not crash or throw exceptions, but text composition would >>> not work correctly. >>> >>> >>> I know that we want to avoid using the Java 8 features in the >>> >>> >>> JFX-8, so I wanted to ask - is it OK to use the default methods here? >>> >>> >>> If you are staying away from JDK8 features for the JFX78 backport, >>> >>> >>> don't worry. There are more issues with new JDK8 APIs than with the new >>> language features. >>> >>> >>> For example there were default methods put into some collections >>> >>> >>> classes that we solved by pushing them down to the first implements. But >>> the Date and Time picker depends on the new time package. The threeten >>> backport won't be updated until after 8 ships, so that has been removed so >>> far. >>> >>> >>> I'de be interested to know what a wholesale lamdaization would >>> >>> >>> result in speed wise and code size wise (both source and compiled). From >>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut >>> makes the backport more of a busy work proposition. If there were >>> performance gains it would also make a great front page story in the next >>> java magazine or a case study.. >>> >>> >>> After having used Lambda's for JavaOne, I'd love to make the >>> >>> >>> conversion, even if in the end the performance was the same, because the >>> savings in noise in the Java files is so big. At one time I just took the >>> concurrent classes and lambda-ized them to measure the impact on those >>> classes. You could maybe pick a package and just lambda-ize that one >>> package and see what happens in terms of size reduction. We might see: >>> >>> >>> + A reduction in the overall class size (not pack-200'd) >>> - An increase in startup time (have to spin up synthetic classes >>> >>> >>> created at usage time) >>> >>> >>> +/- And increase or decrease in performance >>> + A decrease in source code >>> >>> It would be interesting to get some data for these points and see >>> >>> >>> what effect lambda's have. Especially if an IDE can just do it in bulk? >>> >>> >>> Richard >>> >>> >>> -- >>> Sven Reimers >>> >>> * Senior Expert Software Architect >>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> * Community Leader NetBeans: http://community.java.net/netbeans >>> Desktop Java:http://community.java.net/javadesktop >>> * Duke's Choice Award Winner 2009 >>> * Blog: http://nbguru.blogspot.com >>> >>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >>> Join the NetBeans Groups: >>> * XING: http://www.xing.com/group-20148.82db20 >>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>> http://www.linkedin.com/groups?gid=107402 >>> http://www.linkedin.com/groups?gid=1684717 >>> * Oracle: https://mix.oracle.com/groups/18497 >>> >>> >>> -- >>> Sven Reimers >>> >>> * Senior Expert Software Architect >>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> * Community Leader NetBeans: http://community.java.net/netbeans >>> Desktop Java:http://community.java.net/javadesktop >>> * Duke's Choice Award Winner 2009 >>> * Blog: http://nbguru.blogspot.com >>> >>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >>> Join the NetBeans Groups: >>> * XING: http://www.xing.com/group-20148.82db20 >>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>> http://www.linkedin.com/groups?gid=107402 >>> http://www.linkedin.com/groups?gid=1684717 >>> * Oracle: https://mix.oracle.com/groups/18497 >>> >>> >>> >>> >> From richard.bair at oracle.com Mon Oct 7 07:53:43 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 7 Oct 2013 07:53:43 -0700 Subject: Keyboard events In-Reply-To: <52529340.4080205@oracle.com> References: <52529340.4080205@oracle.com> Message-ID: That being said, this seems like a very common use case, and I wonder if there is something more we could do (in the longer term, short term do as Artem suggests) > On Oct 7, 2013, at 3:56 AM, Artem Ananiev wrote: > > >> On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: >> Hi, >> >> I have the following use case: >> When the user presses shift and the mouse is hover the chart component the >> cursor must change to an open hand cursor signaling to the user that the >> chart is ready for a panning action. >> The problem is that for this to be possible I want the chart to be able to >> listen to keyboard events even when it doesn't have focus. >> >> I think this is not possible and I wonder why. Swing was the same, you >> could only listen to keyboard events if the control had focus. Is this a >> technical limitation? If there is no technical limitation I think it would >> be better to remove this restriction, I think it is limiting and the above >> scenario is a good use case to show that. > > This is not a technical limitation, it's just the way how it's supposed to work. All the key events are dispatched to the component in focus, this is what input focus is. > > Scenario you described should be easier to implement in FX than in Swing. In AWT/Swing, input events are dispatched to a single component, while FX is much more flexible. All the events are delivered to a Scene first, then dispatched to the focused component (or component under mouse, for mouse events), then bubbled up back to the Scene. What you need is to register a custom event filter for the scene and listen to all the key events. > > See Scene.addEventFilter() and Scene.addEventHandler() for details. > > Thanks, > > Artem > >> Thanks, best regards, >> From pedro.duquevieira at gmail.com Mon Oct 7 07:57:11 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 7 Oct 2013 15:57:11 +0100 Subject: Keyboard events In-Reply-To: References: <52529340.4080205@oracle.com> Message-ID: Hi Artem, Richard, Thanks for your feedback! There's one more thing which further complicates things and that I've forgot to mention. The chart is embedded in a swing app, so doing as Artem suggests will not work: the scene will have to be focused in order for it to receive keyboard events, right? Thanks, best regards, On Mon, Oct 7, 2013 at 3:53 PM, Richard Bair wrote: > That being said, this seems like a very common use case, and I wonder if > there is something more we could do (in the longer term, short term do as > Artem suggests) > > > On Oct 7, 2013, at 3:56 AM, Artem Ananiev > wrote: > > > > > >> On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: > >> Hi, > >> > >> I have the following use case: > >> When the user presses shift and the mouse is hover the chart component > the > >> cursor must change to an open hand cursor signaling to the user that the > >> chart is ready for a panning action. > >> The problem is that for this to be possible I want the chart to be able > to > >> listen to keyboard events even when it doesn't have focus. > >> > >> I think this is not possible and I wonder why. Swing was the same, you > >> could only listen to keyboard events if the control had focus. Is this a > >> technical limitation? If there is no technical limitation I think it > would > >> be better to remove this restriction, I think it is limiting and the > above > >> scenario is a good use case to show that. > > > > This is not a technical limitation, it's just the way how it's supposed > to work. All the key events are dispatched to the component in focus, this > is what input focus is. > > > > Scenario you described should be easier to implement in FX than in > Swing. In AWT/Swing, input events are dispatched to a single component, > while FX is much more flexible. All the events are delivered to a Scene > first, then dispatched to the focused component (or component under mouse, > for mouse events), then bubbled up back to the Scene. What you need is to > register a custom event filter for the scene and listen to all the key > events. > > > > See Scene.addEventFilter() and Scene.addEventHandler() for details. > > > > Thanks, > > > > Artem > > > >> Thanks, best regards, > >> > -- Pedro Duque Vieira From kevin.rushforth at oracle.com Mon Oct 7 08:17:27 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Oct 2013 08:17:27 -0700 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> Message-ID: <5252D087.4040404@oracle.com> I was just speaking about removing the warnings. Richard and Jonathan should chime in as to whether they are OK doing the lambda-fication in FX 8 (and about how they want to see the review done). Please base any change on 8/graphics/rt Thanks! -- Kevin Sven Reimers wrote: > Ok. So I will file a P4 saying > > > Lambdafication for Controls > > and send the diff to Richard/Kevin/Jonathan to be attached.. > > should I base the change on b110 (master)? > > I could create a public bitbucket branch based on master and add my > changes there - better idea? > > What approach is most simple for review? > > Should I split test and library code changes? > > -Sven > > P.S. Shall I try to get this done as well for other modules? Which > would be preferred? (Just in case I have some more time to spend) > > > > On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth > > wrote: > >> 5. Should we enable more -Xlint warnings in OpenJFX build? >> >> 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings > > We have 2 weeks where we can still accept P4-P5 bugs into FX 8, > and getting rid of warnings would be a P4 bug. I guess it depends > on how intrusive the changes are and whether someone has time to > review it in the next two weeks. > > -- Kevin > > > > > Sven Reimers wrote: >> Ok. So here are the results of trying to add lambda and diamond to the >> controls module: >> >> 1. A lot of generics and typing to be fixed (esp. in tests). Seems you can >> get some anonymous inner classes type checked by the compiler, but not the >> lambda equivalent.. very interesting. >> >> 2. 279 Files modified (including tests) >> >> 3. A lot of the automatic replacements could probably be nicer e.g. >> >> ft.setOnFinished(new EventHandler() { >> @Override public void handle(ActionEvent >> actionEvent) { >> getChildren().remove(tm.textNode); >> } >> }); >> >> was replaced to: >> >> ft.setOnFinished((ActionEvent actionEvent) -> { >> getChildren().remove(tm.textNode); >> }); >> >> most unobtrusive code probably: >> >> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); >> >> 4. A lot of illegal forward reference errors - these were result of missing >> this in the automatic transformation from anonymous inner to lambdas (seems >> the rules are not identical - you have to add "this." as prefix if using >> lambdas - not sure this is the expected way it should work) >> >> 5. Should we enable more -Xlint warnings in OpenJFX build? >> >> 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings >> >> 7. Probably more things I just can't think of at the moment... >> >> How to take this forward? If there is interest in the change I could make >> available... >> >> Comments? Ideas? >> >> -Sven >> >> >> >> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers wrote: >> >> >>> Oh and btw - would you go for lambda with or without additional type info >>> before parameter name? >>> >>> -Sven >>> >>> >>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers wrote: >>> >>> >>>> Ok. Here you go... >>>> >>>> I just did an inspection run for the controls module and my IDE came up >>>> with (drum roll) 888 possible lambda conversions.. >>>> >>>> Looking through them I discovered that usage of <> (aka diamond syntax) >>>> is not used (or at least not used a lot) in at least the controls >>>> modules. My IDE showed me 1171 occurrences. >>>> >>>> Is there a good reason not to use diamonds? >>>> >>>> Will now try to apply all those changes and figure out if this still >>>> builds... up next: go through the other modules... >>>> >>>> -Sven >>>> >>>> >>>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair wrote: >>>> >>>> >>>>> Brian was telling me at J1 that whether parallel gets you performance or >>>>> not depends on the size of the collection and the complexity of the work to >>>>> perform. There is definitely a point at which parallel helps -- and a point >>>>> at which it hurts. >>>>> >>>>> Richard >>>>> >>>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod wrote: >>>>> >>>>> >>>>>> Here is a nice example, taking advantage of the ease of going >>>>>> >>>>> parallel. Apparently the performance without parallel will also further >>>>> improve. >>>>> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >>>>> >>>>>> Herv? >>>>>> >>>>>> Sent from my iPad >>>>>> >>>>>> >>>>>>> On 4 oct. 2013, at 00:20, David Grieve >>>>>>> >>>>> wrote: >>>>> >>>>>>> And what about Stream? I like the declarative code that comes from >>>>>>> >>>>> using Stream and I can see places in the code where Stream could be used, >>>>> but I wonder about its performance relative to iterators and/or enhanced >>>>> for loops. >>>>> >>>>>>> On Oct 3, 2013, at 4:45 PM, Richard Bair >>>>>>> >>>>> wrote: >>>>> >>>>>>>>> Hello, OpenJFX Community. >>>>>>>>> >>>>>>>>> There's a question about using Java 8 features in FX. >>>>>>>>> >>>>>>>>> I've been working on the support for InputMethods in JFXPanel which >>>>>>>>> >>>>> is an important feature for many users who speak hieroglyphic languages. >>>>> >>>>>>>>> The issue is tracked under: >>>>>>>>> >>>>> https://javafx-jira.kenai.com/browse/RT-13248 >>>>> >>>>>>>>> In order to have a high-quality support we need to change >>>>>>>>> >>>>> javafx.scene.input.InputMethodRequests interface and introduce 3 new >>>>> methods. This is not needed for pure FX applications right now, but >>>>> absolutely required for InputMethods in the JFXPanel. However, the >>>>> interface is public and it was present since FX2.0, so changing it would >>>>> become a breaking change. So the only way to avoid the problem is using the >>>>> default methods. Those would return some stub values, the JDK is OK with >>>>> that, as it would not crash or throw exceptions, but text composition would >>>>> not work correctly. >>>>> >>>>>>>>> I know that we want to avoid using the Java 8 features in the >>>>>>>>> >>>>> JFX-8, so I wanted to ask - is it OK to use the default methods here? >>>>> >>>>>>>>> If you are staying away from JDK8 features for the JFX78 backport, >>>>>>>>> >>>>> don't worry. There are more issues with new JDK8 APIs than with the new >>>>> language features. >>>>> >>>>>>>>> For example there were default methods put into some collections >>>>>>>>> >>>>> classes that we solved by pushing them down to the first implements. But >>>>> the Date and Time picker depends on the new time package. The threeten >>>>> backport won't be updated until after 8 ships, so that has been removed so >>>>> far. >>>>> >>>>>>>>> I'de be interested to know what a wholesale lamdaization would >>>>>>>>> >>>>> result in speed wise and code size wise (both source and compiled). From >>>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it jsut >>>>> makes the backport more of a busy work proposition. If there were >>>>> performance gains it would also make a great front page story in the next >>>>> java magazine or a case study.. >>>>> >>>>>>>> After having used Lambda's for JavaOne, I'd love to make the >>>>>>>> >>>>> conversion, even if in the end the performance was the same, because the >>>>> savings in noise in the Java files is so big. At one time I just took the >>>>> concurrent classes and lambda-ized them to measure the impact on those >>>>> classes. You could maybe pick a package and just lambda-ize that one >>>>> package and see what happens in terms of size reduction. We might see: >>>>> >>>>>>>> + A reduction in the overall class size (not pack-200'd) >>>>>>>> - An increase in startup time (have to spin up synthetic classes >>>>>>>> >>>>> created at usage time) >>>>> >>>>>>>> +/- And increase or decrease in performance >>>>>>>> + A decrease in source code >>>>>>>> >>>>>>>> It would be interesting to get some data for these points and see >>>>>>>> >>>>> what effect lambda's have. Especially if an IDE can just do it in bulk? >>>>> >>>>>>>> Richard >>>>>>>> >>>>> >>>> -- >>>> Sven Reimers >>>> >>>> * Senior Expert Software Architect >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>> Desktop Java: >>>> http://community.java.net/javadesktop >>>> * Duke's Choice Award Winner 2009 >>>> * Blog: http://nbguru.blogspot.com >>>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>> >>>> Join the NetBeans Groups: >>>> * XING: http://www.xing.com/group-20148.82db20 >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>> http://www.linkedin.com/groups?gid=107402 >>>> http://www.linkedin.com/groups?gid=1684717 >>>> * Oracle: https://mix.oracle.com/groups/18497 >>>> >>>> >>> -- >>> Sven Reimers >>> >>> * Senior Expert Software Architect >>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> * Community Leader NetBeans: http://community.java.net/netbeans >>> Desktop Java: >>> http://community.java.net/javadesktop >>> * Duke's Choice Award Winner 2009 >>> * Blog: http://nbguru.blogspot.com >>> >>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >>> Join the NetBeans Groups: >>> * XING: http://www.xing.com/group-20148.82db20 >>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>> http://www.linkedin.com/groups?gid=107402 >>> http://www.linkedin.com/groups?gid=1684717 >>> * Oracle: https://mix.oracle.com/groups/18497 >>> >>> >> > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From danno.ferrin at shemnon.com Mon Oct 7 08:19:41 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Mon, 7 Oct 2013 09:19:41 -0600 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: <5252C37F.5030506@bestsolution.at> References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: IntelliJ at least has a decent de-lamba assistant, not sure about NetBeans since it isn't my daily driver. So I am not concerned about the backporting impact if (and this is the big if) there is demonstrable improvement in either jar size, execution speed, or runtime memory impact. Ideally all three. Worth the hassle in that case. But if all we get from this is busy work, then i would then question it's value. On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl wrote: > ... I can't see any real improvement for using lambdas beside that you > killed off warnings which could be fixed otherwise as well. > > So I really don't get what it would help us beside making e.g. RoboVM > our sole chance to get FX on iOS harder to maintain. > > Tom > > On 07.10.13 16:16, Sven Reimers wrote: > > Ok. So I will file a P4 saying Lambdafication for Controls > > and send the diff to Richard/Kevin/Jonathan to be attached.. > > > > should I base the change on b110 (master)? > > > > I could create a public bitbucket branch based on master and add my > changes > > there - better idea? > > > > What approach is most simple for review? > > > > Should I split test and library code changes? > > > > -Sven > > > > P.S. Shall I try to get this done as well for other modules? Which would > be > > preferred? (Just in case I have some more time to spend) > > > > > > > > On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth > > wrote: > > > >> ** > >> > >> 5. Should we enable more -Xlint warnings in OpenJFX build? > >> > >> 6. Any chances anything of this can still go in 8 (e.g. get rid of > warnings > >> > >> > >> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and > >> getting rid of warnings would be a P4 bug. I guess it depends on how > >> intrusive the changes are and whether someone has time to review it in > the > >> next two weeks. > >> > >> -- Kevin > >> > >> > >> > >> > >> Sven Reimers wrote: > >> > >> Ok. So here are the results of trying to add lambda and diamond to the > >> controls module: > >> > >> 1. A lot of generics and typing to be fixed (esp. in tests). Seems you > can > >> get some anonymous inner classes type checked by the compiler, but not > the > >> lambda equivalent.. very interesting. > >> > >> 2. 279 Files modified (including tests) > >> > >> 3. A lot of the automatic replacements could probably be nicer e.g. > >> > >> ft.setOnFinished(new EventHandler() { > >> @Override public void handle(ActionEvent > >> actionEvent) { > >> getChildren().remove(tm.textNode); > >> } > >> }); > >> > >> was replaced to: > >> > >> ft.setOnFinished((ActionEvent actionEvent) -> { > >> getChildren().remove(tm.textNode); > >> }); > >> > >> most unobtrusive code probably: > >> > >> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); > >> > >> 4. A lot of illegal forward reference errors - these were result of > missing > >> this in the automatic transformation from anonymous inner to lambdas > (seems > >> the rules are not identical - you have to add "this." as prefix if using > >> lambdas - not sure this is the expected way it should work) > >> > >> 5. Should we enable more -Xlint warnings in OpenJFX build? > >> > >> 6. Any chances anything of this can still go in 8 (e.g. get rid of > warnings > >> > >> 7. Probably more things I just can't think of at the moment... > >> > >> How to take this forward? If there is interest in the change I could > make > >> available... > >> > >> Comments? Ideas? > >> > >> -Sven > >> > >> > >> > >> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers < > sven.reimers at gmail.com> wrote: > >> > >> > >> > >> Oh and btw - would you go for lambda with or without additional type > info > >> before parameter name? > >> > >> -Sven > >> > >> > >> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers < > sven.reimers at gmail.com>wrote: > >> > >> > >> > >> Ok. Here you go... > >> > >> I just did an inspection run for the controls module and my IDE came up > >> with (drum roll) 888 possible lambda conversions.. > >> > >> Looking through them I discovered that usage of <> (aka diamond syntax) > >> is not used (or at least not used a lot) in at least the controls > >> modules. My IDE showed me 1171 occurrences. > >> > >> Is there a good reason not to use diamonds? > >> > >> Will now try to apply all those changes and figure out if this still > >> builds... up next: go through the other modules... > >> > >> -Sven > >> > >> > >> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair > wrote: > >> > >> > >> > >> Brian was telling me at J1 that whether parallel gets you performance > or > >> not depends on the size of the collection and the complexity of the > work to > >> perform. There is definitely a point at which parallel helps -- and a > point > >> at which it hurts. > >> > >> Richard > >> > >> On Oct 3, 2013, at 3:33 PM, Herv? Girod < > herve.girod at gmail.com> wrote: > >> > >> > >> > >> Here is a nice example, taking advantage of the ease of going > >> > >> > >> parallel. Apparently the performance without parallel will also further > >> improve. > http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ > >> > >> Herv? > >> > >> Sent from my iPad > >> > >> > >> > >> On 4 oct. 2013, at 00:20, David Grieve < > david.grieve at oracle.com> > >> > >> wrote: > >> > >> > >> And what about Stream? I like the declarative code that comes from > >> > >> > >> using Stream and I can see places in the code where Stream could be > used, > >> but I wonder about its performance relative to iterators and/or enhanced > >> for loops. > >> > >> > >> On Oct 3, 2013, at 4:45 PM, Richard Bair < > richard.bair at oracle.com> > >> > >> wrote: > >> > >> > >> Hello, OpenJFX Community. > >> > >> There's a question about using Java 8 features in FX. > >> > >> I've been working on the support for InputMethods in JFXPanel which > >> > >> > >> is an important feature for many users who speak hieroglyphic > languages. > >> > >> > >> The issue is tracked under: > >> > >> > >> https://javafx-jira.kenai.com/browse/RT-13248 > >> > >> In order to have a high-quality support we need to change > >> > >> > >> javafx.scene.input.InputMethodRequests interface and introduce 3 new > >> methods. This is not needed for pure FX applications right now, but > >> absolutely required for InputMethods in the JFXPanel. However, the > >> interface is public and it was present since FX2.0, so changing it would > >> become a breaking change. So the only way to avoid the problem is using > the > >> default methods. Those would return some stub values, the JDK is OK with > >> that, as it would not crash or throw exceptions, but text composition > would > >> not work correctly. > >> > >> > >> I know that we want to avoid using the Java 8 features in the > >> > >> > >> JFX-8, so I wanted to ask - is it OK to use the default methods here? > >> > >> > >> If you are staying away from JDK8 features for the JFX78 backport, > >> > >> > >> don't worry. There are more issues with new JDK8 APIs than with the > new > >> language features. > >> > >> > >> For example there were default methods put into some collections > >> > >> > >> classes that we solved by pushing them down to the first implements. > But > >> the Date and Time picker depends on the new time package. The threeten > >> backport won't be updated until after 8 ships, so that has been removed > so > >> far. > >> > >> > >> I'de be interested to know what a wholesale lamdaization would > >> > >> > >> result in speed wise and code size wise (both source and compiled). > From > >> what I can tell the IDEs can lambda and de-lambda fairly easily, so it > jsut > >> makes the backport more of a busy work proposition. If there were > >> performance gains it would also make a great front page story in the > next > >> java magazine or a case study.. > >> > >> > >> After having used Lambda's for JavaOne, I'd love to make the > >> > >> > >> conversion, even if in the end the performance was the same, because > the > >> savings in noise in the Java files is so big. At one time I just took > the > >> concurrent classes and lambda-ized them to measure the impact on those > >> classes. You could maybe pick a package and just lambda-ize that one > >> package and see what happens in terms of size reduction. We might see: > >> > >> > >> + A reduction in the overall class size (not pack-200'd) > >> - An increase in startup time (have to spin up synthetic classes > >> > >> > >> created at usage time) > >> > >> > >> +/- And increase or decrease in performance > >> + A decrease in source code > >> > >> It would be interesting to get some data for these points and see > >> > >> > >> what effect lambda's have. Especially if an IDE can just do it in > bulk? > >> > >> > >> Richard > >> > >> > >> -- > >> Sven Reimers > >> > >> * Senior Expert Software Architect > >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >> * Community Leader NetBeans: http://community.java.net/netbeans > >> Desktop Java: > http://community.java.net/javadesktop > >> * Duke's Choice Award Winner 2009 > >> * Blog: http://nbguru.blogspot.com > >> > >> * XING: https://www.xing.com/profile/Sven_Reimers8 > >> * LinkedIn: http://www.linkedin.com/in/svenreimers > >> > >> Join the NetBeans Groups: > >> * XING: http://www.xing.com/group-20148.82db20 > >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >> http://www.linkedin.com/groups?gid=107402 > >> http://www.linkedin.com/groups?gid=1684717 > >> * Oracle: https://mix.oracle.com/groups/18497 > >> > >> > >> -- > >> Sven Reimers > >> > >> * Senior Expert Software Architect > >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >> * Community Leader NetBeans: http://community.java.net/netbeans > >> Desktop Java: > http://community.java.net/javadesktop > >> * Duke's Choice Award Winner 2009 > >> * Blog: http://nbguru.blogspot.com > >> > >> * XING: https://www.xing.com/profile/Sven_Reimers8 > >> * LinkedIn: http://www.linkedin.com/in/svenreimers > >> > >> Join the NetBeans Groups: > >> * XING: http://www.xing.com/group-20148.82db20 > >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >> http://www.linkedin.com/groups?gid=107402 > >> http://www.linkedin.com/groups?gid=1684717 > >> * Oracle: https://mix.oracle.com/groups/18497 > >> > >> > >> > >> > > > > > > From hang.vo at oracle.com Mon Oct 7 08:32:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 15:32:42 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131007153319.DE26D62E02@hg.openjdk.java.net> Changeset: 4b5b42fd1c9d Author: mickf Date: 2013-10-07 16:15 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4b5b42fd1c9d RT-33371 - Regression : Tab travsersal issue with Accordion ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: 68546f1ae3cd Author: David Grieve Date: 2013-10-04 12:53 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/68546f1ae3cd RT-33145: In SkinBase, add comments as to why variables are initialized to max and min values, and fix minX and maxX initialization in computePerfWidth. Reviewed by: rbair, jgiles ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java From richard.bair at oracle.com Mon Oct 7 09:24:16 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 7 Oct 2013 09:24:16 -0700 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: My thoughts exactly, which is why I'm grateful for Sven for trying it out :-). I expect that Lambda would make a big reduction in static class count (i.e.: class files), but not a major reduction in class count at runtime (since dynamic classes are created for Lambdas). So a normal Jar should be significantly smaller, while a Pack200 jar probably has little to no difference. Execution speed should be the same. Startup might be faster or slower, I'm not sure (but I would expect it to be negligible). If the jar is significantly reduced in size, it might be useful for embedded which doesn't use Pack200. But we need the data, because making the change at this point, otherwise in a couple months when we get a 9 / 8u workspace opened we can start putting the work in there (since in my mind there is no question but that for 9 we need to complete lamdafication). Richard On Oct 7, 2013, at 8:19 AM, Danno Ferrin wrote: > IntelliJ at least has a decent de-lamba assistant, not sure about NetBeans > since it isn't my daily driver. So I am not concerned about the > backporting impact if (and this is the big if) there is demonstrable > improvement in either jar size, execution speed, or runtime memory impact. > Ideally all three. Worth the hassle in that case. But if all we get from > this is busy work, then i would then question it's value. > > > On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl wrote: > >> ... I can't see any real improvement for using lambdas beside that you >> killed off warnings which could be fixed otherwise as well. >> >> So I really don't get what it would help us beside making e.g. RoboVM >> our sole chance to get FX on iOS harder to maintain. >> >> Tom >> >> On 07.10.13 16:16, Sven Reimers wrote: >>> Ok. So I will file a P4 saying Lambdafication for Controls >>> and send the diff to Richard/Kevin/Jonathan to be attached.. >>> >>> should I base the change on b110 (master)? >>> >>> I could create a public bitbucket branch based on master and add my >> changes >>> there - better idea? >>> >>> What approach is most simple for review? >>> >>> Should I split test and library code changes? >>> >>> -Sven >>> >>> P.S. Shall I try to get this done as well for other modules? Which would >> be >>> preferred? (Just in case I have some more time to spend) >>> >>> >>> >>> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth >>> wrote: >>> >>>> ** >>>> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >>>> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >> warnings >>>> >>>> >>>> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and >>>> getting rid of warnings would be a P4 bug. I guess it depends on how >>>> intrusive the changes are and whether someone has time to review it in >> the >>>> next two weeks. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> >>>> Sven Reimers wrote: >>>> >>>> Ok. So here are the results of trying to add lambda and diamond to the >>>> controls module: >>>> >>>> 1. A lot of generics and typing to be fixed (esp. in tests). Seems you >> can >>>> get some anonymous inner classes type checked by the compiler, but not >> the >>>> lambda equivalent.. very interesting. >>>> >>>> 2. 279 Files modified (including tests) >>>> >>>> 3. A lot of the automatic replacements could probably be nicer e.g. >>>> >>>> ft.setOnFinished(new EventHandler() { >>>> @Override public void handle(ActionEvent >>>> actionEvent) { >>>> getChildren().remove(tm.textNode); >>>> } >>>> }); >>>> >>>> was replaced to: >>>> >>>> ft.setOnFinished((ActionEvent actionEvent) -> { >>>> getChildren().remove(tm.textNode); >>>> }); >>>> >>>> most unobtrusive code probably: >>>> >>>> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); >>>> >>>> 4. A lot of illegal forward reference errors - these were result of >> missing >>>> this in the automatic transformation from anonymous inner to lambdas >> (seems >>>> the rules are not identical - you have to add "this." as prefix if using >>>> lambdas - not sure this is the expected way it should work) >>>> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >>>> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >> warnings >>>> >>>> 7. Probably more things I just can't think of at the moment... >>>> >>>> How to take this forward? If there is interest in the change I could >> make >>>> available... >>>> >>>> Comments? Ideas? >>>> >>>> -Sven >>>> >>>> >>>> >>>> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers < >> sven.reimers at gmail.com> wrote: >>>> >>>> >>>> >>>> Oh and btw - would you go for lambda with or without additional type >> info >>>> before parameter name? >>>> >>>> -Sven >>>> >>>> >>>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers < >> sven.reimers at gmail.com>wrote: >>>> >>>> >>>> >>>> Ok. Here you go... >>>> >>>> I just did an inspection run for the controls module and my IDE came up >>>> with (drum roll) 888 possible lambda conversions.. >>>> >>>> Looking through them I discovered that usage of <> (aka diamond syntax) >>>> is not used (or at least not used a lot) in at least the controls >>>> modules. My IDE showed me 1171 occurrences. >>>> >>>> Is there a good reason not to use diamonds? >>>> >>>> Will now try to apply all those changes and figure out if this still >>>> builds... up next: go through the other modules... >>>> >>>> -Sven >>>> >>>> >>>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair >> wrote: >>>> >>>> >>>> >>>> Brian was telling me at J1 that whether parallel gets you performance >> or >>>> not depends on the size of the collection and the complexity of the >> work to >>>> perform. There is definitely a point at which parallel helps -- and a >> point >>>> at which it hurts. >>>> >>>> Richard >>>> >>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod < >> herve.girod at gmail.com> wrote: >>>> >>>> >>>> >>>> Here is a nice example, taking advantage of the ease of going >>>> >>>> >>>> parallel. Apparently the performance without parallel will also further >>>> improve. >> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >>>> >>>> Herv? >>>> >>>> Sent from my iPad >>>> >>>> >>>> >>>> On 4 oct. 2013, at 00:20, David Grieve < >> david.grieve at oracle.com> >>>> >>>> wrote: >>>> >>>> >>>> And what about Stream? I like the declarative code that comes from >>>> >>>> >>>> using Stream and I can see places in the code where Stream could be >> used, >>>> but I wonder about its performance relative to iterators and/or enhanced >>>> for loops. >>>> >>>> >>>> On Oct 3, 2013, at 4:45 PM, Richard Bair < >> richard.bair at oracle.com> >>>> >>>> wrote: >>>> >>>> >>>> Hello, OpenJFX Community. >>>> >>>> There's a question about using Java 8 features in FX. >>>> >>>> I've been working on the support for InputMethods in JFXPanel which >>>> >>>> >>>> is an important feature for many users who speak hieroglyphic >> languages. >>>> >>>> >>>> The issue is tracked under: >>>> >>>> >>>> https://javafx-jira.kenai.com/browse/RT-13248 >>>> >>>> In order to have a high-quality support we need to change >>>> >>>> >>>> javafx.scene.input.InputMethodRequests interface and introduce 3 new >>>> methods. This is not needed for pure FX applications right now, but >>>> absolutely required for InputMethods in the JFXPanel. However, the >>>> interface is public and it was present since FX2.0, so changing it would >>>> become a breaking change. So the only way to avoid the problem is using >> the >>>> default methods. Those would return some stub values, the JDK is OK with >>>> that, as it would not crash or throw exceptions, but text composition >> would >>>> not work correctly. >>>> >>>> >>>> I know that we want to avoid using the Java 8 features in the >>>> >>>> >>>> JFX-8, so I wanted to ask - is it OK to use the default methods here? >>>> >>>> >>>> If you are staying away from JDK8 features for the JFX78 backport, >>>> >>>> >>>> don't worry. There are more issues with new JDK8 APIs than with the >> new >>>> language features. >>>> >>>> >>>> For example there were default methods put into some collections >>>> >>>> >>>> classes that we solved by pushing them down to the first implements. >> But >>>> the Date and Time picker depends on the new time package. The threeten >>>> backport won't be updated until after 8 ships, so that has been removed >> so >>>> far. >>>> >>>> >>>> I'de be interested to know what a wholesale lamdaization would >>>> >>>> >>>> result in speed wise and code size wise (both source and compiled). >> From >>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it >> jsut >>>> makes the backport more of a busy work proposition. If there were >>>> performance gains it would also make a great front page story in the >> next >>>> java magazine or a case study.. >>>> >>>> >>>> After having used Lambda's for JavaOne, I'd love to make the >>>> >>>> >>>> conversion, even if in the end the performance was the same, because >> the >>>> savings in noise in the Java files is so big. At one time I just took >> the >>>> concurrent classes and lambda-ized them to measure the impact on those >>>> classes. You could maybe pick a package and just lambda-ize that one >>>> package and see what happens in terms of size reduction. We might see: >>>> >>>> >>>> + A reduction in the overall class size (not pack-200'd) >>>> - An increase in startup time (have to spin up synthetic classes >>>> >>>> >>>> created at usage time) >>>> >>>> >>>> +/- And increase or decrease in performance >>>> + A decrease in source code >>>> >>>> It would be interesting to get some data for these points and see >>>> >>>> >>>> what effect lambda's have. Especially if an IDE can just do it in >> bulk? >>>> >>>> >>>> Richard >>>> >>>> >>>> -- >>>> Sven Reimers >>>> >>>> * Senior Expert Software Architect >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>> Desktop Java: >> http://community.java.net/javadesktop >>>> * Duke's Choice Award Winner 2009 >>>> * Blog: http://nbguru.blogspot.com >>>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>> >>>> Join the NetBeans Groups: >>>> * XING: http://www.xing.com/group-20148.82db20 >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>> http://www.linkedin.com/groups?gid=107402 >>>> http://www.linkedin.com/groups?gid=1684717 >>>> * Oracle: https://mix.oracle.com/groups/18497 >>>> >>>> >>>> -- >>>> Sven Reimers >>>> >>>> * Senior Expert Software Architect >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>>> Desktop Java: >> http://community.java.net/javadesktop >>>> * Duke's Choice Award Winner 2009 >>>> * Blog: http://nbguru.blogspot.com >>>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>>> >>>> Join the NetBeans Groups: >>>> * XING: http://www.xing.com/group-20148.82db20 >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>>> http://www.linkedin.com/groups?gid=107402 >>>> http://www.linkedin.com/groups?gid=1684717 >>>> * Oracle: https://mix.oracle.com/groups/18497 >>>> >>>> >>>> >>>> >>> >>> >> >> From artem.ananiev at oracle.com Mon Oct 7 10:00:24 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 07 Oct 2013 21:00:24 +0400 Subject: Keyboard events In-Reply-To: References: <52529340.4080205@oracle.com> Message-ID: <5252E8A8.7020508@oracle.com> On 10/7/2013 6:57 PM, Pedro Duque Vieira wrote: > Hi Artem, Richard, > > Thanks for your feedback! There's one more thing which further > complicates things and that I've forgot to mention. The chart is > embedded in a swing app, so doing as Artem suggests will not work: the > scene will have to be focused in order for it to receive keyboard > events, right? For standalone FX apps (no Swing), it's required and enough to have FX scene focused. With Swing involved, things get more complicated. FX scene is considered to have focus, if the corresponding JFXPanel is focused (as a Swing component). Only in that case you'll be able to track key events using the event filters/handlers, otherwise you'll have to use Toolkit.addAWTEventListener() or something like this. Thanks, Artem > Thanks, best regards, > > > On Mon, Oct 7, 2013 at 3:53 PM, Richard Bair > wrote: > > That being said, this seems like a very common use case, and I > wonder if there is something more we could do (in the longer term, > short term do as Artem suggests) > > > On Oct 7, 2013, at 3:56 AM, Artem Ananiev > > wrote: > > > > > >> On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: > >> Hi, > >> > >> I have the following use case: > >> When the user presses shift and the mouse is hover the chart > component the > >> cursor must change to an open hand cursor signaling to the user > that the > >> chart is ready for a panning action. > >> The problem is that for this to be possible I want the chart to > be able to > >> listen to keyboard events even when it doesn't have focus. > >> > >> I think this is not possible and I wonder why. Swing was the > same, you > >> could only listen to keyboard events if the control had focus. > Is this a > >> technical limitation? If there is no technical limitation I > think it would > >> be better to remove this restriction, I think it is limiting and > the above > >> scenario is a good use case to show that. > > > > This is not a technical limitation, it's just the way how it's > supposed to work. All the key events are dispatched to the component > in focus, this is what input focus is. > > > > Scenario you described should be easier to implement in FX than > in Swing. In AWT/Swing, input events are dispatched to a single > component, while FX is much more flexible. All the events are > delivered to a Scene first, then dispatched to the focused component > (or component under mouse, for mouse events), then bubbled up back > to the Scene. What you need is to register a custom event filter for > the scene and listen to all the key events. > > > > See Scene.addEventFilter() and Scene.addEventHandler() for details. > > > > Thanks, > > > > Artem > > > >> Thanks, best regards, > >> > > > > > -- > Pedro Duque Vieira From artem.ananiev at oracle.com Mon Oct 7 10:03:34 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 07 Oct 2013 21:03:34 +0400 Subject: Keyboard events In-Reply-To: References: <52529340.4080205@oracle.com> Message-ID: <5252E966.3020707@oracle.com> On 10/7/2013 6:53 PM, Richard Bair wrote: > That being said, this seems like a very common use case, and I wonder if there is something more we could do (in the longer term, short term do as Artem suggests) One of the options is to provide API to query for keyboard state at any arbitrary moment, whether particular key is pressed or not. Even if we only support locking keys (Caps, Num, Scroll, Kana) and control keys (Shift, Control, Command, Alt), it will be of great value. Game developers will be happy to have such API for all the keys, including navigation and letter ones. Thanks, Artem >> On Oct 7, 2013, at 3:56 AM, Artem Ananiev wrote: >> >> >>> On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: >>> Hi, >>> >>> I have the following use case: >>> When the user presses shift and the mouse is hover the chart component the >>> cursor must change to an open hand cursor signaling to the user that the >>> chart is ready for a panning action. >>> The problem is that for this to be possible I want the chart to be able to >>> listen to keyboard events even when it doesn't have focus. >>> >>> I think this is not possible and I wonder why. Swing was the same, you >>> could only listen to keyboard events if the control had focus. Is this a >>> technical limitation? If there is no technical limitation I think it would >>> be better to remove this restriction, I think it is limiting and the above >>> scenario is a good use case to show that. >> >> This is not a technical limitation, it's just the way how it's supposed to work. All the key events are dispatched to the component in focus, this is what input focus is. >> >> Scenario you described should be easier to implement in FX than in Swing. In AWT/Swing, input events are dispatched to a single component, while FX is much more flexible. All the events are delivered to a Scene first, then dispatched to the focused component (or component under mouse, for mouse events), then bubbled up back to the Scene. What you need is to register a custom event filter for the scene and listen to all the key events. >> >> See Scene.addEventFilter() and Scene.addEventHandler() for details. >> >> Thanks, >> >> Artem >> >>> Thanks, best regards, >>> From sven.reimers at gmail.com Mon Oct 7 10:23:50 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 7 Oct 2013 19:23:50 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: Ok. So Lamdafication after 8. Fixes for warnings still in for 8? Will try to get some more data out of my trial... and if this needs time a full OPenJFX-Lambda branch might be handy on bitbucket... Next nightshift... -Sven On Mon, Oct 7, 2013 at 6:24 PM, Richard Bair wrote: > My thoughts exactly, which is why I'm grateful for Sven for trying it out > :-). I expect that Lambda would make a big reduction in static class count > (i.e.: class files), but not a major reduction in class count at runtime > (since dynamic classes are created for Lambdas). So a normal Jar should be > significantly smaller, while a Pack200 jar probably has little to no > difference. Execution speed should be the same. Startup might be faster or > slower, I'm not sure (but I would expect it to be negligible). If the jar > is significantly reduced in size, it might be useful for embedded which > doesn't use Pack200. > > But we need the data, because making the change at this point, otherwise > in a couple months when we get a 9 / 8u workspace opened we can start > putting the work in there (since in my mind there is no question but that > for 9 we need to complete lamdafication). > > Richard > > On Oct 7, 2013, at 8:19 AM, Danno Ferrin wrote: > > > IntelliJ at least has a decent de-lamba assistant, not sure about > NetBeans > > since it isn't my daily driver. So I am not concerned about the > > backporting impact if (and this is the big if) there is demonstrable > > improvement in either jar size, execution speed, or runtime memory > impact. > > Ideally all three. Worth the hassle in that case. But if all we get > from > > this is busy work, then i would then question it's value. > > > > > > On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl >wrote: > > > >> ... I can't see any real improvement for using lambdas beside that you > >> killed off warnings which could be fixed otherwise as well. > >> > >> So I really don't get what it would help us beside making e.g. RoboVM > >> our sole chance to get FX on iOS harder to maintain. > >> > >> Tom > >> > >> On 07.10.13 16:16, Sven Reimers wrote: > >>> Ok. So I will file a P4 saying Lambdafication for Controls > >>> and send the diff to Richard/Kevin/Jonathan to be attached.. > >>> > >>> should I base the change on b110 (master)? > >>> > >>> I could create a public bitbucket branch based on master and add my > >> changes > >>> there - better idea? > >>> > >>> What approach is most simple for review? > >>> > >>> Should I split test and library code changes? > >>> > >>> -Sven > >>> > >>> P.S. Shall I try to get this done as well for other modules? Which > would > >> be > >>> preferred? (Just in case I have some more time to spend) > >>> > >>> > >>> > >>> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth > >>> wrote: > >>> > >>>> ** > >>>> > >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? > >>>> > >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of > >> warnings > >>>> > >>>> > >>>> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and > >>>> getting rid of warnings would be a P4 bug. I guess it depends on how > >>>> intrusive the changes are and whether someone has time to review it in > >> the > >>>> next two weeks. > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> > >>>> > >>>> Sven Reimers wrote: > >>>> > >>>> Ok. So here are the results of trying to add lambda and diamond to the > >>>> controls module: > >>>> > >>>> 1. A lot of generics and typing to be fixed (esp. in tests). Seems you > >> can > >>>> get some anonymous inner classes type checked by the compiler, but > not > >> the > >>>> lambda equivalent.. very interesting. > >>>> > >>>> 2. 279 Files modified (including tests) > >>>> > >>>> 3. A lot of the automatic replacements could probably be nicer e.g. > >>>> > >>>> ft.setOnFinished(new EventHandler() { > >>>> @Override public void handle(ActionEvent > >>>> actionEvent) { > >>>> getChildren().remove(tm.textNode); > >>>> } > >>>> }); > >>>> > >>>> was replaced to: > >>>> > >>>> ft.setOnFinished((ActionEvent actionEvent) -> { > >>>> getChildren().remove(tm.textNode); > >>>> }); > >>>> > >>>> most unobtrusive code probably: > >>>> > >>>> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); > >>>> > >>>> 4. A lot of illegal forward reference errors - these were result of > >> missing > >>>> this in the automatic transformation from anonymous inner to lambdas > >> (seems > >>>> the rules are not identical - you have to add "this." as prefix if > using > >>>> lambdas - not sure this is the expected way it should work) > >>>> > >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? > >>>> > >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of > >> warnings > >>>> > >>>> 7. Probably more things I just can't think of at the moment... > >>>> > >>>> How to take this forward? If there is interest in the change I could > >> make > >>>> available... > >>>> > >>>> Comments? Ideas? > >>>> > >>>> -Sven > >>>> > >>>> > >>>> > >>>> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers > < > >> sven.reimers at gmail.com> wrote: > >>>> > >>>> > >>>> > >>>> Oh and btw - would you go for lambda with or without additional type > >> info > >>>> before parameter name? > >>>> > >>>> -Sven > >>>> > >>>> > >>>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers > < > >> sven.reimers at gmail.com>wrote: > >>>> > >>>> > >>>> > >>>> Ok. Here you go... > >>>> > >>>> I just did an inspection run for the controls module and my IDE came > up > >>>> with (drum roll) 888 possible lambda conversions.. > >>>> > >>>> Looking through them I discovered that usage of <> (aka diamond > syntax) > >>>> is not used (or at least not used a lot) in at least the controls > >>>> modules. My IDE showed me 1171 occurrences. > >>>> > >>>> Is there a good reason not to use diamonds? > >>>> > >>>> Will now try to apply all those changes and figure out if this still > >>>> builds... up next: go through the other modules... > >>>> > >>>> -Sven > >>>> > >>>> > >>>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair > > >> wrote: > >>>> > >>>> > >>>> > >>>> Brian was telling me at J1 that whether parallel gets you performance > >> or > >>>> not depends on the size of the collection and the complexity of the > >> work to > >>>> perform. There is definitely a point at which parallel helps -- and a > >> point > >>>> at which it hurts. > >>>> > >>>> Richard > >>>> > >>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod < > >> herve.girod at gmail.com> wrote: > >>>> > >>>> > >>>> > >>>> Here is a nice example, taking advantage of the ease of going > >>>> > >>>> > >>>> parallel. Apparently the performance without parallel will also > further > >>>> improve. > >> > http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ > >>>> > >>>> Herv? > >>>> > >>>> Sent from my iPad > >>>> > >>>> > >>>> > >>>> On 4 oct. 2013, at 00:20, David Grieve < > >> david.grieve at oracle.com> > >>>> > >>>> wrote: > >>>> > >>>> > >>>> And what about Stream? I like the declarative code that comes from > >>>> > >>>> > >>>> using Stream and I can see places in the code where Stream could be > >> used, > >>>> but I wonder about its performance relative to iterators and/or > enhanced > >>>> for loops. > >>>> > >>>> > >>>> On Oct 3, 2013, at 4:45 PM, Richard Bair < > >> richard.bair at oracle.com> > >>>> > >>>> wrote: > >>>> > >>>> > >>>> Hello, OpenJFX Community. > >>>> > >>>> There's a question about using Java 8 features in FX. > >>>> > >>>> I've been working on the support for InputMethods in JFXPanel which > >>>> > >>>> > >>>> is an important feature for many users who speak hieroglyphic > >> languages. > >>>> > >>>> > >>>> The issue is tracked under: > >>>> > >>>> > >>>> https://javafx-jira.kenai.com/browse/RT-13248 > >>>> > >>>> In order to have a high-quality support we need to change > >>>> > >>>> > >>>> javafx.scene.input.InputMethodRequests interface and introduce 3 new > >>>> methods. This is not needed for pure FX applications right now, but > >>>> absolutely required for InputMethods in the JFXPanel. However, the > >>>> interface is public and it was present since FX2.0, so changing it > would > >>>> become a breaking change. So the only way to avoid the problem is > using > >> the > >>>> default methods. Those would return some stub values, the JDK is OK > with > >>>> that, as it would not crash or throw exceptions, but text composition > >> would > >>>> not work correctly. > >>>> > >>>> > >>>> I know that we want to avoid using the Java 8 features in the > >>>> > >>>> > >>>> JFX-8, so I wanted to ask - is it OK to use the default methods here? > >>>> > >>>> > >>>> If you are staying away from JDK8 features for the JFX78 backport, > >>>> > >>>> > >>>> don't worry. There are more issues with new JDK8 APIs than with the > >> new > >>>> language features. > >>>> > >>>> > >>>> For example there were default methods put into some collections > >>>> > >>>> > >>>> classes that we solved by pushing them down to the first implements. > >> But > >>>> the Date and Time picker depends on the new time package. The > threeten > >>>> backport won't be updated until after 8 ships, so that has been > removed > >> so > >>>> far. > >>>> > >>>> > >>>> I'de be interested to know what a wholesale lamdaization would > >>>> > >>>> > >>>> result in speed wise and code size wise (both source and compiled). > >> From > >>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it > >> jsut > >>>> makes the backport more of a busy work proposition. If there were > >>>> performance gains it would also make a great front page story in the > >> next > >>>> java magazine or a case study.. > >>>> > >>>> > >>>> After having used Lambda's for JavaOne, I'd love to make the > >>>> > >>>> > >>>> conversion, even if in the end the performance was the same, because > >> the > >>>> savings in noise in the Java files is so big. At one time I just took > >> the > >>>> concurrent classes and lambda-ized them to measure the impact on those > >>>> classes. You could maybe pick a package and just lambda-ize that one > >>>> package and see what happens in terms of size reduction. We might see: > >>>> > >>>> > >>>> + A reduction in the overall class size (not pack-200'd) > >>>> - An increase in startup time (have to spin up synthetic classes > >>>> > >>>> > >>>> created at usage time) > >>>> > >>>> > >>>> +/- And increase or decrease in performance > >>>> + A decrease in source code > >>>> > >>>> It would be interesting to get some data for these points and see > >>>> > >>>> > >>>> what effect lambda's have. Especially if an IDE can just do it in > >> bulk? > >>>> > >>>> > >>>> Richard > >>>> > >>>> > >>>> -- > >>>> Sven Reimers > >>>> > >>>> * Senior Expert Software Architect > >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >>>> * Community Leader NetBeans: http://community.java.net/netbeans > >>>> Desktop Java: > >> http://community.java.net/javadesktop > >>>> * Duke's Choice Award Winner 2009 > >>>> * Blog: http://nbguru.blogspot.com > >>>> > >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 > >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers > >>>> > >>>> Join the NetBeans Groups: > >>>> * XING: http://www.xing.com/group-20148.82db20 > >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >>>> http://www.linkedin.com/groups?gid=107402 > >>>> http://www.linkedin.com/groups?gid=1684717 > >>>> * Oracle: https://mix.oracle.com/groups/18497 > >>>> > >>>> > >>>> -- > >>>> Sven Reimers > >>>> > >>>> * Senior Expert Software Architect > >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >>>> * Community Leader NetBeans: http://community.java.net/netbeans > >>>> Desktop Java: > >> http://community.java.net/javadesktop > >>>> * Duke's Choice Award Winner 2009 > >>>> * Blog: http://nbguru.blogspot.com > >>>> > >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 > >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers > >>>> > >>>> Join the NetBeans Groups: > >>>> * XING: http://www.xing.com/group-20148.82db20 > >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >>>> http://www.linkedin.com/groups?gid=107402 > >>>> http://www.linkedin.com/groups?gid=1684717 > >>>> * Oracle: https://mix.oracle.com/groups/18497 > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From hang.vo at oracle.com Mon Oct 7 11:48:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 18:48:08 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33258: Event locking when SWT-Shell opened via JavaFX Message-ID: <20131007185020.8ECED62E0E@hg.openjdk.java.net> Changeset: 9d2e2252eb11 Author: snorthov Date: 2013-10-07 14:30 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9d2e2252eb11 RT-33258: Event locking when SWT-Shell opened via JavaFX Summary: The InvokeLaterDispatcher was disabled when running embedded with SWT Reviewed-by: ixmal, anthony ! modules/graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinApplication.java From hang.vo at oracle.com Mon Oct 7 12:18:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 19:18:03 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131007191841.5368562E0F@hg.openjdk.java.net> Changeset: 18781eb28d4e Author: kcr Date: 2013-10-07 12:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/18781eb28d4e RT-31064: Ability to get GridPane row count, column count, and cell bounds at runtime Reviewed-by: rbair, msladecek ! modules/graphics/src/main/java/javafx/scene/layout/GridPane.java Changeset: ab3b347eb645 Author: kcr Date: 2013-10-07 12:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab3b347eb645 RT-31500: Gradle: build in debug mode by default Reviewed-by: Felipe ! build.gradle ! buildSrc/android.gradle ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/ios.gradle ! buildSrc/linux.gradle ! buildSrc/mac.gradle ! buildSrc/src/main/groovy/com/sun/javafx/gradle/LinkTask.groovy ! buildSrc/win.gradle ! buildSrc/x86egl.gradle ! gradle.properties.template From sven.reimers at gmail.com Mon Oct 7 13:15:34 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 7 Oct 2013 22:15:34 +0200 Subject: Building on Mac with latest Xcode Message-ID: Hi, since I had to once more reinstall my Mac short before Java One I lost a couple of updates, so I finally got the latest XCode installed, which does not include MacOSX 10.7 SDK. Fixing building is easy - just change minimum version in buildSrc/mac.gradle to 10.8 does the trick. So what is the "official" "correct" way to circumvent the problem? Seems the latest XCode version that shipped 10.7 SDK is 4.4 (if I get this correct from https://developer.apple.com/downloads/index.action?q=xcode Should deinstall the actual version and get back to 4.4? Any comments appreciated. Thanks -Sven -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From danno.ferrin at shemnon.com Mon Oct 7 13:31:06 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Mon, 7 Oct 2013 14:31:06 -0600 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: You can fork from here: https://bitbucket.org/openjfxmirrors/openjfx-8-graphics-rt It updates every 4 hours based on a cloudbees job. On Mon, Oct 7, 2013 at 11:23 AM, Sven Reimers wrote: > Ok. > > So Lamdafication after 8. > > Fixes for warnings still in for 8? > > Will try to get some more data out of my trial... and if this needs time a > full OPenJFX-Lambda branch might be handy on bitbucket... > > Next nightshift... > > -Sven > > > On Mon, Oct 7, 2013 at 6:24 PM, Richard Bair wrote: > >> My thoughts exactly, which is why I'm grateful for Sven for trying it out >> :-). I expect that Lambda would make a big reduction in static class count >> (i.e.: class files), but not a major reduction in class count at runtime >> (since dynamic classes are created for Lambdas). So a normal Jar should be >> significantly smaller, while a Pack200 jar probably has little to no >> difference. Execution speed should be the same. Startup might be faster or >> slower, I'm not sure (but I would expect it to be negligible). If the jar >> is significantly reduced in size, it might be useful for embedded which >> doesn't use Pack200. >> >> But we need the data, because making the change at this point, otherwise >> in a couple months when we get a 9 / 8u workspace opened we can start >> putting the work in there (since in my mind there is no question but that >> for 9 we need to complete lamdafication). >> >> Richard >> >> On Oct 7, 2013, at 8:19 AM, Danno Ferrin >> wrote: >> >> > IntelliJ at least has a decent de-lamba assistant, not sure about >> NetBeans >> > since it isn't my daily driver. So I am not concerned about the >> > backporting impact if (and this is the big if) there is demonstrable >> > improvement in either jar size, execution speed, or runtime memory >> impact. >> > Ideally all three. Worth the hassle in that case. But if all we get >> from >> > this is busy work, then i would then question it's value. >> > >> > >> > On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl < >> tom.schindl at bestsolution.at>wrote: >> > >> >> ... I can't see any real improvement for using lambdas beside that you >> >> killed off warnings which could be fixed otherwise as well. >> >> >> >> So I really don't get what it would help us beside making e.g. RoboVM >> >> our sole chance to get FX on iOS harder to maintain. >> >> >> >> Tom >> >> >> >> On 07.10.13 16:16, Sven Reimers wrote: >> >>> Ok. So I will file a P4 saying Lambdafication for Controls >> >>> and send the diff to Richard/Kevin/Jonathan to be attached.. >> >>> >> >>> should I base the change on b110 (master)? >> >>> >> >>> I could create a public bitbucket branch based on master and add my >> >> changes >> >>> there - better idea? >> >>> >> >>> What approach is most simple for review? >> >>> >> >>> Should I split test and library code changes? >> >>> >> >>> -Sven >> >>> >> >>> P.S. Shall I try to get this done as well for other modules? Which >> would >> >> be >> >>> preferred? (Just in case I have some more time to spend) >> >>> >> >>> >> >>> >> >>> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth >> >>> wrote: >> >>> >> >>>> ** >> >>>> >> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >> >>>> >> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >> >> warnings >> >>>> >> >>>> >> >>>> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and >> >>>> getting rid of warnings would be a P4 bug. I guess it depends on how >> >>>> intrusive the changes are and whether someone has time to review it >> in >> >> the >> >>>> next two weeks. >> >>>> >> >>>> -- Kevin >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Sven Reimers wrote: >> >>>> >> >>>> Ok. So here are the results of trying to add lambda and diamond to >> the >> >>>> controls module: >> >>>> >> >>>> 1. A lot of generics and typing to be fixed (esp. in tests). Seems >> you >> >> can >> >>>> get some anonymous inner classes type checked by the compiler, but >> not >> >> the >> >>>> lambda equivalent.. very interesting. >> >>>> >> >>>> 2. 279 Files modified (including tests) >> >>>> >> >>>> 3. A lot of the automatic replacements could probably be nicer e.g. >> >>>> >> >>>> ft.setOnFinished(new EventHandler() { >> >>>> @Override public void handle(ActionEvent >> >>>> actionEvent) { >> >>>> getChildren().remove(tm.textNode); >> >>>> } >> >>>> }); >> >>>> >> >>>> was replaced to: >> >>>> >> >>>> ft.setOnFinished((ActionEvent actionEvent) -> { >> >>>> getChildren().remove(tm.textNode); >> >>>> }); >> >>>> >> >>>> most unobtrusive code probably: >> >>>> >> >>>> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); >> >>>> >> >>>> 4. A lot of illegal forward reference errors - these were result of >> >> missing >> >>>> this in the automatic transformation from anonymous inner to lambdas >> >> (seems >> >>>> the rules are not identical - you have to add "this." as prefix if >> using >> >>>> lambdas - not sure this is the expected way it should work) >> >>>> >> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >> >>>> >> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >> >> warnings >> >>>> >> >>>> 7. Probably more things I just can't think of at the moment... >> >>>> >> >>>> How to take this forward? If there is interest in the change I could >> >> make >> >>>> available... >> >>>> >> >>>> Comments? Ideas? >> >>>> >> >>>> -Sven >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers >> < >> >> sven.reimers at gmail.com> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Oh and btw - would you go for lambda with or without additional type >> >> info >> >>>> before parameter name? >> >>>> >> >>>> -Sven >> >>>> >> >>>> >> >>>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers >> < >> >> sven.reimers at gmail.com>wrote: >> >>>> >> >>>> >> >>>> >> >>>> Ok. Here you go... >> >>>> >> >>>> I just did an inspection run for the controls module and my IDE came >> up >> >>>> with (drum roll) 888 possible lambda conversions.. >> >>>> >> >>>> Looking through them I discovered that usage of <> (aka diamond >> syntax) >> >>>> is not used (or at least not used a lot) in at least the controls >> >>>> modules. My IDE showed me 1171 occurrences. >> >>>> >> >>>> Is there a good reason not to use diamonds? >> >>>> >> >>>> Will now try to apply all those changes and figure out if this still >> >>>> builds... up next: go through the other modules... >> >>>> >> >>>> -Sven >> >>>> >> >>>> >> >>>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair < >> richard.bair at oracle.com> >> >> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Brian was telling me at J1 that whether parallel gets you performance >> >> or >> >>>> not depends on the size of the collection and the complexity of the >> >> work to >> >>>> perform. There is definitely a point at which parallel helps -- and a >> >> point >> >>>> at which it hurts. >> >>>> >> >>>> Richard >> >>>> >> >>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod < >> >> herve.girod at gmail.com> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Here is a nice example, taking advantage of the ease of going >> >>>> >> >>>> >> >>>> parallel. Apparently the performance without parallel will also >> further >> >>>> improve. >> >> >> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >> >>>> >> >>>> Herv? >> >>>> >> >>>> Sent from my iPad >> >>>> >> >>>> >> >>>> >> >>>> On 4 oct. 2013, at 00:20, David Grieve < >> >> david.grieve at oracle.com> >> >>>> >> >>>> wrote: >> >>>> >> >>>> >> >>>> And what about Stream? I like the declarative code that comes from >> >>>> >> >>>> >> >>>> using Stream and I can see places in the code where Stream could be >> >> used, >> >>>> but I wonder about its performance relative to iterators and/or >> enhanced >> >>>> for loops. >> >>>> >> >>>> >> >>>> On Oct 3, 2013, at 4:45 PM, Richard Bair < >> >> richard.bair at oracle.com> >> >>>> >> >>>> wrote: >> >>>> >> >>>> >> >>>> Hello, OpenJFX Community. >> >>>> >> >>>> There's a question about using Java 8 features in FX. >> >>>> >> >>>> I've been working on the support for InputMethods in JFXPanel which >> >>>> >> >>>> >> >>>> is an important feature for many users who speak hieroglyphic >> >> languages. >> >>>> >> >>>> >> >>>> The issue is tracked under: >> >>>> >> >>>> >> >>>> https://javafx-jira.kenai.com/browse/RT-13248 >> >>>> >> >>>> In order to have a high-quality support we need to change >> >>>> >> >>>> >> >>>> javafx.scene.input.InputMethodRequests interface and introduce 3 new >> >>>> methods. This is not needed for pure FX applications right now, but >> >>>> absolutely required for InputMethods in the JFXPanel. However, the >> >>>> interface is public and it was present since FX2.0, so changing it >> would >> >>>> become a breaking change. So the only way to avoid the problem is >> using >> >> the >> >>>> default methods. Those would return some stub values, the JDK is OK >> with >> >>>> that, as it would not crash or throw exceptions, but text composition >> >> would >> >>>> not work correctly. >> >>>> >> >>>> >> >>>> I know that we want to avoid using the Java 8 features in the >> >>>> >> >>>> >> >>>> JFX-8, so I wanted to ask - is it OK to use the default methods >> here? >> >>>> >> >>>> >> >>>> If you are staying away from JDK8 features for the JFX78 backport, >> >>>> >> >>>> >> >>>> don't worry. There are more issues with new JDK8 APIs than with the >> >> new >> >>>> language features. >> >>>> >> >>>> >> >>>> For example there were default methods put into some collections >> >>>> >> >>>> >> >>>> classes that we solved by pushing them down to the first implements. >> >> But >> >>>> the Date and Time picker depends on the new time package. The >> threeten >> >>>> backport won't be updated until after 8 ships, so that has been >> removed >> >> so >> >>>> far. >> >>>> >> >>>> >> >>>> I'de be interested to know what a wholesale lamdaization would >> >>>> >> >>>> >> >>>> result in speed wise and code size wise (both source and compiled). >> >> From >> >>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so >> it >> >> jsut >> >>>> makes the backport more of a busy work proposition. If there were >> >>>> performance gains it would also make a great front page story in the >> >> next >> >>>> java magazine or a case study.. >> >>>> >> >>>> >> >>>> After having used Lambda's for JavaOne, I'd love to make the >> >>>> >> >>>> >> >>>> conversion, even if in the end the performance was the same, because >> >> the >> >>>> savings in noise in the Java files is so big. At one time I just took >> >> the >> >>>> concurrent classes and lambda-ized them to measure the impact on >> those >> >>>> classes. You could maybe pick a package and just lambda-ize that one >> >>>> package and see what happens in terms of size reduction. We might >> see: >> >>>> >> >>>> >> >>>> + A reduction in the overall class size (not pack-200'd) >> >>>> - An increase in startup time (have to spin up synthetic classes >> >>>> >> >>>> >> >>>> created at usage time) >> >>>> >> >>>> >> >>>> +/- And increase or decrease in performance >> >>>> + A decrease in source code >> >>>> >> >>>> It would be interesting to get some data for these points and see >> >>>> >> >>>> >> >>>> what effect lambda's have. Especially if an IDE can just do it in >> >> bulk? >> >>>> >> >>>> >> >>>> Richard >> >>>> >> >>>> >> >>>> -- >> >>>> Sven Reimers >> >>>> >> >>>> * Senior Expert Software Architect >> >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> >>>> * Community Leader NetBeans: http://community.java.net/netbeans >> >>>> Desktop Java: >> >> http://community.java.net/javadesktop >> >>>> * Duke's Choice Award Winner 2009 >> >>>> * Blog: http://nbguru.blogspot.com >> >>>> >> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >> >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >>>> >> >>>> Join the NetBeans Groups: >> >>>> * XING: http://www.xing.com/group-20148.82db20 >> >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> >>>> http://www.linkedin.com/groups?gid=107402 >> >>>> http://www.linkedin.com/groups?gid=1684717 >> >>>> * Oracle: https://mix.oracle.com/groups/18497 >> >>>> >> >>>> >> >>>> -- >> >>>> Sven Reimers >> >>>> >> >>>> * Senior Expert Software Architect >> >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> >>>> * Community Leader NetBeans: http://community.java.net/netbeans >> >>>> Desktop Java: >> >> http://community.java.net/javadesktop >> >>>> * Duke's Choice Award Winner 2009 >> >>>> * Blog: http://nbguru.blogspot.com >> >>>> >> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >> >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >>>> >> >>>> Join the NetBeans Groups: >> >>>> * XING: http://www.xing.com/group-20148.82db20 >> >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> >>>> http://www.linkedin.com/groups?gid=107402 >> >>>> http://www.linkedin.com/groups?gid=1684717 >> >>>> * Oracle: https://mix.oracle.com/groups/18497 >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >> >> > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > From sven.reimers at gmail.com Mon Oct 7 13:32:13 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 7 Oct 2013 22:32:13 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: First batch of statistics (controls submodule so far) 1630 vs 996 class in controls (my actual state on disk, YMMV) More statistics to follow... -Sven On Mon, Oct 7, 2013 at 6:24 PM, Richard Bair wrote: > My thoughts exactly, which is why I'm grateful for Sven for trying it out > :-). I expect that Lambda would make a big reduction in static class count > (i.e.: class files), but not a major reduction in class count at runtime > (since dynamic classes are created for Lambdas). So a normal Jar should be > significantly smaller, while a Pack200 jar probably has little to no > difference. Execution speed should be the same. Startup might be faster or > slower, I'm not sure (but I would expect it to be negligible). If the jar > is significantly reduced in size, it might be useful for embedded which > doesn't use Pack200. > > But we need the data, because making the change at this point, otherwise > in a couple months when we get a 9 / 8u workspace opened we can start > putting the work in there (since in my mind there is no question but that > for 9 we need to complete lamdafication). > > Richard > > On Oct 7, 2013, at 8:19 AM, Danno Ferrin wrote: > > > IntelliJ at least has a decent de-lamba assistant, not sure about > NetBeans > > since it isn't my daily driver. So I am not concerned about the > > backporting impact if (and this is the big if) there is demonstrable > > improvement in either jar size, execution speed, or runtime memory > impact. > > Ideally all three. Worth the hassle in that case. But if all we get > from > > this is busy work, then i would then question it's value. > > > > > > On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl >wrote: > > > >> ... I can't see any real improvement for using lambdas beside that you > >> killed off warnings which could be fixed otherwise as well. > >> > >> So I really don't get what it would help us beside making e.g. RoboVM > >> our sole chance to get FX on iOS harder to maintain. > >> > >> Tom > >> > >> On 07.10.13 16:16, Sven Reimers wrote: > >>> Ok. So I will file a P4 saying Lambdafication for Controls > >>> and send the diff to Richard/Kevin/Jonathan to be attached.. > >>> > >>> should I base the change on b110 (master)? > >>> > >>> I could create a public bitbucket branch based on master and add my > >> changes > >>> there - better idea? > >>> > >>> What approach is most simple for review? > >>> > >>> Should I split test and library code changes? > >>> > >>> -Sven > >>> > >>> P.S. Shall I try to get this done as well for other modules? Which > would > >> be > >>> preferred? (Just in case I have some more time to spend) > >>> > >>> > >>> > >>> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth > >>> wrote: > >>> > >>>> ** > >>>> > >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? > >>>> > >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of > >> warnings > >>>> > >>>> > >>>> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and > >>>> getting rid of warnings would be a P4 bug. I guess it depends on how > >>>> intrusive the changes are and whether someone has time to review it in > >> the > >>>> next two weeks. > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> > >>>> > >>>> Sven Reimers wrote: > >>>> > >>>> Ok. So here are the results of trying to add lambda and diamond to the > >>>> controls module: > >>>> > >>>> 1. A lot of generics and typing to be fixed (esp. in tests). Seems you > >> can > >>>> get some anonymous inner classes type checked by the compiler, but > not > >> the > >>>> lambda equivalent.. very interesting. > >>>> > >>>> 2. 279 Files modified (including tests) > >>>> > >>>> 3. A lot of the automatic replacements could probably be nicer e.g. > >>>> > >>>> ft.setOnFinished(new EventHandler() { > >>>> @Override public void handle(ActionEvent > >>>> actionEvent) { > >>>> getChildren().remove(tm.textNode); > >>>> } > >>>> }); > >>>> > >>>> was replaced to: > >>>> > >>>> ft.setOnFinished((ActionEvent actionEvent) -> { > >>>> getChildren().remove(tm.textNode); > >>>> }); > >>>> > >>>> most unobtrusive code probably: > >>>> > >>>> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); > >>>> > >>>> 4. A lot of illegal forward reference errors - these were result of > >> missing > >>>> this in the automatic transformation from anonymous inner to lambdas > >> (seems > >>>> the rules are not identical - you have to add "this." as prefix if > using > >>>> lambdas - not sure this is the expected way it should work) > >>>> > >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? > >>>> > >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of > >> warnings > >>>> > >>>> 7. Probably more things I just can't think of at the moment... > >>>> > >>>> How to take this forward? If there is interest in the change I could > >> make > >>>> available... > >>>> > >>>> Comments? Ideas? > >>>> > >>>> -Sven > >>>> > >>>> > >>>> > >>>> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers > < > >> sven.reimers at gmail.com> wrote: > >>>> > >>>> > >>>> > >>>> Oh and btw - would you go for lambda with or without additional type > >> info > >>>> before parameter name? > >>>> > >>>> -Sven > >>>> > >>>> > >>>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers > < > >> sven.reimers at gmail.com>wrote: > >>>> > >>>> > >>>> > >>>> Ok. Here you go... > >>>> > >>>> I just did an inspection run for the controls module and my IDE came > up > >>>> with (drum roll) 888 possible lambda conversions.. > >>>> > >>>> Looking through them I discovered that usage of <> (aka diamond > syntax) > >>>> is not used (or at least not used a lot) in at least the controls > >>>> modules. My IDE showed me 1171 occurrences. > >>>> > >>>> Is there a good reason not to use diamonds? > >>>> > >>>> Will now try to apply all those changes and figure out if this still > >>>> builds... up next: go through the other modules... > >>>> > >>>> -Sven > >>>> > >>>> > >>>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair > > >> wrote: > >>>> > >>>> > >>>> > >>>> Brian was telling me at J1 that whether parallel gets you performance > >> or > >>>> not depends on the size of the collection and the complexity of the > >> work to > >>>> perform. There is definitely a point at which parallel helps -- and a > >> point > >>>> at which it hurts. > >>>> > >>>> Richard > >>>> > >>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod < > >> herve.girod at gmail.com> wrote: > >>>> > >>>> > >>>> > >>>> Here is a nice example, taking advantage of the ease of going > >>>> > >>>> > >>>> parallel. Apparently the performance without parallel will also > further > >>>> improve. > >> > http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ > >>>> > >>>> Herv? > >>>> > >>>> Sent from my iPad > >>>> > >>>> > >>>> > >>>> On 4 oct. 2013, at 00:20, David Grieve < > >> david.grieve at oracle.com> > >>>> > >>>> wrote: > >>>> > >>>> > >>>> And what about Stream? I like the declarative code that comes from > >>>> > >>>> > >>>> using Stream and I can see places in the code where Stream could be > >> used, > >>>> but I wonder about its performance relative to iterators and/or > enhanced > >>>> for loops. > >>>> > >>>> > >>>> On Oct 3, 2013, at 4:45 PM, Richard Bair < > >> richard.bair at oracle.com> > >>>> > >>>> wrote: > >>>> > >>>> > >>>> Hello, OpenJFX Community. > >>>> > >>>> There's a question about using Java 8 features in FX. > >>>> > >>>> I've been working on the support for InputMethods in JFXPanel which > >>>> > >>>> > >>>> is an important feature for many users who speak hieroglyphic > >> languages. > >>>> > >>>> > >>>> The issue is tracked under: > >>>> > >>>> > >>>> https://javafx-jira.kenai.com/browse/RT-13248 > >>>> > >>>> In order to have a high-quality support we need to change > >>>> > >>>> > >>>> javafx.scene.input.InputMethodRequests interface and introduce 3 new > >>>> methods. This is not needed for pure FX applications right now, but > >>>> absolutely required for InputMethods in the JFXPanel. However, the > >>>> interface is public and it was present since FX2.0, so changing it > would > >>>> become a breaking change. So the only way to avoid the problem is > using > >> the > >>>> default methods. Those would return some stub values, the JDK is OK > with > >>>> that, as it would not crash or throw exceptions, but text composition > >> would > >>>> not work correctly. > >>>> > >>>> > >>>> I know that we want to avoid using the Java 8 features in the > >>>> > >>>> > >>>> JFX-8, so I wanted to ask - is it OK to use the default methods here? > >>>> > >>>> > >>>> If you are staying away from JDK8 features for the JFX78 backport, > >>>> > >>>> > >>>> don't worry. There are more issues with new JDK8 APIs than with the > >> new > >>>> language features. > >>>> > >>>> > >>>> For example there were default methods put into some collections > >>>> > >>>> > >>>> classes that we solved by pushing them down to the first implements. > >> But > >>>> the Date and Time picker depends on the new time package. The > threeten > >>>> backport won't be updated until after 8 ships, so that has been > removed > >> so > >>>> far. > >>>> > >>>> > >>>> I'de be interested to know what a wholesale lamdaization would > >>>> > >>>> > >>>> result in speed wise and code size wise (both source and compiled). > >> From > >>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it > >> jsut > >>>> makes the backport more of a busy work proposition. If there were > >>>> performance gains it would also make a great front page story in the > >> next > >>>> java magazine or a case study.. > >>>> > >>>> > >>>> After having used Lambda's for JavaOne, I'd love to make the > >>>> > >>>> > >>>> conversion, even if in the end the performance was the same, because > >> the > >>>> savings in noise in the Java files is so big. At one time I just took > >> the > >>>> concurrent classes and lambda-ized them to measure the impact on those > >>>> classes. You could maybe pick a package and just lambda-ize that one > >>>> package and see what happens in terms of size reduction. We might see: > >>>> > >>>> > >>>> + A reduction in the overall class size (not pack-200'd) > >>>> - An increase in startup time (have to spin up synthetic classes > >>>> > >>>> > >>>> created at usage time) > >>>> > >>>> > >>>> +/- And increase or decrease in performance > >>>> + A decrease in source code > >>>> > >>>> It would be interesting to get some data for these points and see > >>>> > >>>> > >>>> what effect lambda's have. Especially if an IDE can just do it in > >> bulk? > >>>> > >>>> > >>>> Richard > >>>> > >>>> > >>>> -- > >>>> Sven Reimers > >>>> > >>>> * Senior Expert Software Architect > >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >>>> * Community Leader NetBeans: http://community.java.net/netbeans > >>>> Desktop Java: > >> http://community.java.net/javadesktop > >>>> * Duke's Choice Award Winner 2009 > >>>> * Blog: http://nbguru.blogspot.com > >>>> > >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 > >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers > >>>> > >>>> Join the NetBeans Groups: > >>>> * XING: http://www.xing.com/group-20148.82db20 > >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >>>> http://www.linkedin.com/groups?gid=107402 > >>>> http://www.linkedin.com/groups?gid=1684717 > >>>> * Oracle: https://mix.oracle.com/groups/18497 > >>>> > >>>> > >>>> -- > >>>> Sven Reimers > >>>> > >>>> * Senior Expert Software Architect > >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org > >>>> * Community Leader NetBeans: http://community.java.net/netbeans > >>>> Desktop Java: > >> http://community.java.net/javadesktop > >>>> * Duke's Choice Award Winner 2009 > >>>> * Blog: http://nbguru.blogspot.com > >>>> > >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 > >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers > >>>> > >>>> Join the NetBeans Groups: > >>>> * XING: http://www.xing.com/group-20148.82db20 > >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > >>>> http://www.linkedin.com/groups?gid=107402 > >>>> http://www.linkedin.com/groups?gid=1684717 > >>>> * Oracle: https://mix.oracle.com/groups/18497 > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From sven.reimers at gmail.com Mon Oct 7 13:34:12 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 7 Oct 2013 22:34:12 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: Cool will try to get this done... -Sven On Mon, Oct 7, 2013 at 10:31 PM, Danno Ferrin wrote: > You can fork from here: > > https://bitbucket.org/openjfxmirrors/openjfx-8-graphics-rt > > It updates every 4 hours based on a cloudbees job. > > > On Mon, Oct 7, 2013 at 11:23 AM, Sven Reimers wrote: > >> Ok. >> >> So Lamdafication after 8. >> >> Fixes for warnings still in for 8? >> >> Will try to get some more data out of my trial... and if this needs time >> a full OPenJFX-Lambda branch might be handy on bitbucket... >> >> Next nightshift... >> >> -Sven >> >> >> On Mon, Oct 7, 2013 at 6:24 PM, Richard Bair wrote: >> >>> My thoughts exactly, which is why I'm grateful for Sven for trying it >>> out :-). I expect that Lambda would make a big reduction in static class >>> count (i.e.: class files), but not a major reduction in class count at >>> runtime (since dynamic classes are created for Lambdas). So a normal Jar >>> should be significantly smaller, while a Pack200 jar probably has little to >>> no difference. Execution speed should be the same. Startup might be faster >>> or slower, I'm not sure (but I would expect it to be negligible). If the >>> jar is significantly reduced in size, it might be useful for embedded which >>> doesn't use Pack200. >>> >>> But we need the data, because making the change at this point, otherwise >>> in a couple months when we get a 9 / 8u workspace opened we can start >>> putting the work in there (since in my mind there is no question but that >>> for 9 we need to complete lamdafication). >>> >>> Richard >>> >>> On Oct 7, 2013, at 8:19 AM, Danno Ferrin >>> wrote: >>> >>> > IntelliJ at least has a decent de-lamba assistant, not sure about >>> NetBeans >>> > since it isn't my daily driver. So I am not concerned about the >>> > backporting impact if (and this is the big if) there is demonstrable >>> > improvement in either jar size, execution speed, or runtime memory >>> impact. >>> > Ideally all three. Worth the hassle in that case. But if all we get >>> from >>> > this is busy work, then i would then question it's value. >>> > >>> > >>> > On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl < >>> tom.schindl at bestsolution.at>wrote: >>> > >>> >> ... I can't see any real improvement for using lambdas beside that you >>> >> killed off warnings which could be fixed otherwise as well. >>> >> >>> >> So I really don't get what it would help us beside making e.g. RoboVM >>> >> our sole chance to get FX on iOS harder to maintain. >>> >> >>> >> Tom >>> >> >>> >> On 07.10.13 16:16, Sven Reimers wrote: >>> >>> Ok. So I will file a P4 saying Lambdafication for Controls >>> >>> and send the diff to Richard/Kevin/Jonathan to be attached.. >>> >>> >>> >>> should I base the change on b110 (master)? >>> >>> >>> >>> I could create a public bitbucket branch based on master and add my >>> >> changes >>> >>> there - better idea? >>> >>> >>> >>> What approach is most simple for review? >>> >>> >>> >>> Should I split test and library code changes? >>> >>> >>> >>> -Sven >>> >>> >>> >>> P.S. Shall I try to get this done as well for other modules? Which >>> would >>> >> be >>> >>> preferred? (Just in case I have some more time to spend) >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth >>> >>> wrote: >>> >>> >>> >>>> ** >>> >>>> >>> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >>> >>>> >>> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >>> >> warnings >>> >>>> >>> >>>> >>> >>>> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and >>> >>>> getting rid of warnings would be a P4 bug. I guess it depends on how >>> >>>> intrusive the changes are and whether someone has time to review it >>> in >>> >> the >>> >>>> next two weeks. >>> >>>> >>> >>>> -- Kevin >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> Sven Reimers wrote: >>> >>>> >>> >>>> Ok. So here are the results of trying to add lambda and diamond to >>> the >>> >>>> controls module: >>> >>>> >>> >>>> 1. A lot of generics and typing to be fixed (esp. in tests). Seems >>> you >>> >> can >>> >>>> get some anonymous inner classes type checked by the compiler, but >>> not >>> >> the >>> >>>> lambda equivalent.. very interesting. >>> >>>> >>> >>>> 2. 279 Files modified (including tests) >>> >>>> >>> >>>> 3. A lot of the automatic replacements could probably be nicer e.g. >>> >>>> >>> >>>> ft.setOnFinished(new EventHandler() { >>> >>>> @Override public void handle(ActionEvent >>> >>>> actionEvent) { >>> >>>> getChildren().remove(tm.textNode); >>> >>>> } >>> >>>> }); >>> >>>> >>> >>>> was replaced to: >>> >>>> >>> >>>> ft.setOnFinished((ActionEvent actionEvent) -> { >>> >>>> getChildren().remove(tm.textNode); >>> >>>> }); >>> >>>> >>> >>>> most unobtrusive code probably: >>> >>>> >>> >>>> ft.setOnFinished((actionEvent) -> >>> getChildren().remove(tm.textNode)); >>> >>>> >>> >>>> 4. A lot of illegal forward reference errors - these were result of >>> >> missing >>> >>>> this in the automatic transformation from anonymous inner to lambdas >>> >> (seems >>> >>>> the rules are not identical - you have to add "this." as prefix if >>> using >>> >>>> lambdas - not sure this is the expected way it should work) >>> >>>> >>> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >>> >>>> >>> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >>> >> warnings >>> >>>> >>> >>>> 7. Probably more things I just can't think of at the moment... >>> >>>> >>> >>>> How to take this forward? If there is interest in the change I could >>> >> make >>> >>>> available... >>> >>>> >>> >>>> Comments? Ideas? >>> >>>> >>> >>>> -Sven >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers < >>> sven.reimers at gmail.com> < >>> >> sven.reimers at gmail.com> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Oh and btw - would you go for lambda with or without additional type >>> >> info >>> >>>> before parameter name? >>> >>>> >>> >>>> -Sven >>> >>>> >>> >>>> >>> >>>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers < >>> sven.reimers at gmail.com> < >>> >> sven.reimers at gmail.com>wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Ok. Here you go... >>> >>>> >>> >>>> I just did an inspection run for the controls module and my IDE >>> came up >>> >>>> with (drum roll) 888 possible lambda conversions.. >>> >>>> >>> >>>> Looking through them I discovered that usage of <> (aka diamond >>> syntax) >>> >>>> is not used (or at least not used a lot) in at least the controls >>> >>>> modules. My IDE showed me 1171 occurrences. >>> >>>> >>> >>>> Is there a good reason not to use diamonds? >>> >>>> >>> >>>> Will now try to apply all those changes and figure out if this still >>> >>>> builds... up next: go through the other modules... >>> >>>> >>> >>>> -Sven >>> >>>> >>> >>>> >>> >>>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair < >>> richard.bair at oracle.com> >>> >> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Brian was telling me at J1 that whether parallel gets you >>> performance >>> >> or >>> >>>> not depends on the size of the collection and the complexity of the >>> >> work to >>> >>>> perform. There is definitely a point at which parallel helps -- and >>> a >>> >> point >>> >>>> at which it hurts. >>> >>>> >>> >>>> Richard >>> >>>> >>> >>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod < >>> >> herve.girod at gmail.com> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Here is a nice example, taking advantage of the ease of going >>> >>>> >>> >>>> >>> >>>> parallel. Apparently the performance without parallel will also >>> further >>> >>>> improve. >>> >> >>> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >>> >>>> >>> >>>> Herv? >>> >>>> >>> >>>> Sent from my iPad >>> >>>> >>> >>>> >>> >>>> >>> >>>> On 4 oct. 2013, at 00:20, David Grieve < >>> >> david.grieve at oracle.com> >>> >>>> >>> >>>> wrote: >>> >>>> >>> >>>> >>> >>>> And what about Stream? I like the declarative code that comes from >>> >>>> >>> >>>> >>> >>>> using Stream and I can see places in the code where Stream could be >>> >> used, >>> >>>> but I wonder about its performance relative to iterators and/or >>> enhanced >>> >>>> for loops. >>> >>>> >>> >>>> >>> >>>> On Oct 3, 2013, at 4:45 PM, Richard Bair >>> < >>> >> richard.bair at oracle.com> >>> >>>> >>> >>>> wrote: >>> >>>> >>> >>>> >>> >>>> Hello, OpenJFX Community. >>> >>>> >>> >>>> There's a question about using Java 8 features in FX. >>> >>>> >>> >>>> I've been working on the support for InputMethods in JFXPanel which >>> >>>> >>> >>>> >>> >>>> is an important feature for many users who speak hieroglyphic >>> >> languages. >>> >>>> >>> >>>> >>> >>>> The issue is tracked under: >>> >>>> >>> >>>> >>> >>>> https://javafx-jira.kenai.com/browse/RT-13248 >>> >>>> >>> >>>> In order to have a high-quality support we need to change >>> >>>> >>> >>>> >>> >>>> javafx.scene.input.InputMethodRequests interface and introduce 3 >>> new >>> >>>> methods. This is not needed for pure FX applications right now, but >>> >>>> absolutely required for InputMethods in the JFXPanel. However, the >>> >>>> interface is public and it was present since FX2.0, so changing it >>> would >>> >>>> become a breaking change. So the only way to avoid the problem is >>> using >>> >> the >>> >>>> default methods. Those would return some stub values, the JDK is OK >>> with >>> >>>> that, as it would not crash or throw exceptions, but text >>> composition >>> >> would >>> >>>> not work correctly. >>> >>>> >>> >>>> >>> >>>> I know that we want to avoid using the Java 8 features in the >>> >>>> >>> >>>> >>> >>>> JFX-8, so I wanted to ask - is it OK to use the default methods >>> here? >>> >>>> >>> >>>> >>> >>>> If you are staying away from JDK8 features for the JFX78 backport, >>> >>>> >>> >>>> >>> >>>> don't worry. There are more issues with new JDK8 APIs than with >>> the >>> >> new >>> >>>> language features. >>> >>>> >>> >>>> >>> >>>> For example there were default methods put into some collections >>> >>>> >>> >>>> >>> >>>> classes that we solved by pushing them down to the first >>> implements. >>> >> But >>> >>>> the Date and Time picker depends on the new time package. The >>> threeten >>> >>>> backport won't be updated until after 8 ships, so that has been >>> removed >>> >> so >>> >>>> far. >>> >>>> >>> >>>> >>> >>>> I'de be interested to know what a wholesale lamdaization would >>> >>>> >>> >>>> >>> >>>> result in speed wise and code size wise (both source and compiled). >>> >> From >>> >>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so >>> it >>> >> jsut >>> >>>> makes the backport more of a busy work proposition. If there were >>> >>>> performance gains it would also make a great front page story in the >>> >> next >>> >>>> java magazine or a case study.. >>> >>>> >>> >>>> >>> >>>> After having used Lambda's for JavaOne, I'd love to make the >>> >>>> >>> >>>> >>> >>>> conversion, even if in the end the performance was the same, >>> because >>> >> the >>> >>>> savings in noise in the Java files is so big. At one time I just >>> took >>> >> the >>> >>>> concurrent classes and lambda-ized them to measure the impact on >>> those >>> >>>> classes. You could maybe pick a package and just lambda-ize that one >>> >>>> package and see what happens in terms of size reduction. We might >>> see: >>> >>>> >>> >>>> >>> >>>> + A reduction in the overall class size (not pack-200'd) >>> >>>> - An increase in startup time (have to spin up synthetic classes >>> >>>> >>> >>>> >>> >>>> created at usage time) >>> >>>> >>> >>>> >>> >>>> +/- And increase or decrease in performance >>> >>>> + A decrease in source code >>> >>>> >>> >>>> It would be interesting to get some data for these points and see >>> >>>> >>> >>>> >>> >>>> what effect lambda's have. Especially if an IDE can just do it in >>> >> bulk? >>> >>>> >>> >>>> >>> >>>> Richard >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Sven Reimers >>> >>>> >>> >>>> * Senior Expert Software Architect >>> >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>> >>>> Desktop Java: >>> >> http://community.java.net/javadesktop >>> >>>> * Duke's Choice Award Winner 2009 >>> >>>> * Blog: http://nbguru.blogspot.com >>> >>>> >>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >>>> >>> >>>> Join the NetBeans Groups: >>> >>>> * XING: http://www.xing.com/group-20148.82db20 >>> >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>> >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>> >>>> http://www.linkedin.com/groups?gid=107402 >>> >>>> http://www.linkedin.com/groups?gid=1684717 >>> >>>> * Oracle: https://mix.oracle.com/groups/18497 >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Sven Reimers >>> >>>> >>> >>>> * Senior Expert Software Architect >>> >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>> >>>> Desktop Java: >>> >> http://community.java.net/javadesktop >>> >>>> * Duke's Choice Award Winner 2009 >>> >>>> * Blog: http://nbguru.blogspot.com >>> >>>> >>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >>>> >>> >>>> Join the NetBeans Groups: >>> >>>> * XING: http://www.xing.com/group-20148.82db20 >>> >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>> >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>> >>>> http://www.linkedin.com/groups?gid=107402 >>> >>>> http://www.linkedin.com/groups?gid=1684717 >>> >>>> * Oracle: https://mix.oracle.com/groups/18497 >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >>> >>> >> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java: >> http://community.java.net/javadesktop >> * Duke's Choice Award Winner 2009 >> * Blog: http://nbguru.blogspot.com >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> Join the NetBeans Groups: >> * XING: http://www.xing.com/group-20148.82db20 >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> http://www.linkedin.com/groups?gid=107402 >> http://www.linkedin.com/groups?gid=1684717 >> * Oracle: https://mix.oracle.com/groups/18497 >> > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From sven.reimers at gmail.com Mon Oct 7 13:42:34 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 7 Oct 2013 22:42:34 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: Ok jfxrt.jar sizes build from openjfx: 8165779 -> 7736259 bytes Will try to get this into a fork on github so you all can play with the actual state... -Sven On Mon, Oct 7, 2013 at 10:32 PM, Sven Reimers wrote: > First batch of statistics (controls submodule so far) > > 1630 vs 996 class in controls (my actual state on disk, YMMV) > > More statistics to follow... > > -Sven > > > On Mon, Oct 7, 2013 at 6:24 PM, Richard Bair wrote: > >> My thoughts exactly, which is why I'm grateful for Sven for trying it out >> :-). I expect that Lambda would make a big reduction in static class count >> (i.e.: class files), but not a major reduction in class count at runtime >> (since dynamic classes are created for Lambdas). So a normal Jar should be >> significantly smaller, while a Pack200 jar probably has little to no >> difference. Execution speed should be the same. Startup might be faster or >> slower, I'm not sure (but I would expect it to be negligible). If the jar >> is significantly reduced in size, it might be useful for embedded which >> doesn't use Pack200. >> >> But we need the data, because making the change at this point, otherwise >> in a couple months when we get a 9 / 8u workspace opened we can start >> putting the work in there (since in my mind there is no question but that >> for 9 we need to complete lamdafication). >> >> Richard >> >> On Oct 7, 2013, at 8:19 AM, Danno Ferrin >> wrote: >> >> > IntelliJ at least has a decent de-lamba assistant, not sure about >> NetBeans >> > since it isn't my daily driver. So I am not concerned about the >> > backporting impact if (and this is the big if) there is demonstrable >> > improvement in either jar size, execution speed, or runtime memory >> impact. >> > Ideally all three. Worth the hassle in that case. But if all we get >> from >> > this is busy work, then i would then question it's value. >> > >> > >> > On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl < >> tom.schindl at bestsolution.at>wrote: >> > >> >> ... I can't see any real improvement for using lambdas beside that you >> >> killed off warnings which could be fixed otherwise as well. >> >> >> >> So I really don't get what it would help us beside making e.g. RoboVM >> >> our sole chance to get FX on iOS harder to maintain. >> >> >> >> Tom >> >> >> >> On 07.10.13 16:16, Sven Reimers wrote: >> >>> Ok. So I will file a P4 saying Lambdafication for Controls >> >>> and send the diff to Richard/Kevin/Jonathan to be attached.. >> >>> >> >>> should I base the change on b110 (master)? >> >>> >> >>> I could create a public bitbucket branch based on master and add my >> >> changes >> >>> there - better idea? >> >>> >> >>> What approach is most simple for review? >> >>> >> >>> Should I split test and library code changes? >> >>> >> >>> -Sven >> >>> >> >>> P.S. Shall I try to get this done as well for other modules? Which >> would >> >> be >> >>> preferred? (Just in case I have some more time to spend) >> >>> >> >>> >> >>> >> >>> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth >> >>> wrote: >> >>> >> >>>> ** >> >>>> >> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >> >>>> >> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >> >> warnings >> >>>> >> >>>> >> >>>> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and >> >>>> getting rid of warnings would be a P4 bug. I guess it depends on how >> >>>> intrusive the changes are and whether someone has time to review it >> in >> >> the >> >>>> next two weeks. >> >>>> >> >>>> -- Kevin >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Sven Reimers wrote: >> >>>> >> >>>> Ok. So here are the results of trying to add lambda and diamond to >> the >> >>>> controls module: >> >>>> >> >>>> 1. A lot of generics and typing to be fixed (esp. in tests). Seems >> you >> >> can >> >>>> get some anonymous inner classes type checked by the compiler, but >> not >> >> the >> >>>> lambda equivalent.. very interesting. >> >>>> >> >>>> 2. 279 Files modified (including tests) >> >>>> >> >>>> 3. A lot of the automatic replacements could probably be nicer e.g. >> >>>> >> >>>> ft.setOnFinished(new EventHandler() { >> >>>> @Override public void handle(ActionEvent >> >>>> actionEvent) { >> >>>> getChildren().remove(tm.textNode); >> >>>> } >> >>>> }); >> >>>> >> >>>> was replaced to: >> >>>> >> >>>> ft.setOnFinished((ActionEvent actionEvent) -> { >> >>>> getChildren().remove(tm.textNode); >> >>>> }); >> >>>> >> >>>> most unobtrusive code probably: >> >>>> >> >>>> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode)); >> >>>> >> >>>> 4. A lot of illegal forward reference errors - these were result of >> >> missing >> >>>> this in the automatic transformation from anonymous inner to lambdas >> >> (seems >> >>>> the rules are not identical - you have to add "this." as prefix if >> using >> >>>> lambdas - not sure this is the expected way it should work) >> >>>> >> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >> >>>> >> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >> >> warnings >> >>>> >> >>>> 7. Probably more things I just can't think of at the moment... >> >>>> >> >>>> How to take this forward? If there is interest in the change I could >> >> make >> >>>> available... >> >>>> >> >>>> Comments? Ideas? >> >>>> >> >>>> -Sven >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers >> < >> >> sven.reimers at gmail.com> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Oh and btw - would you go for lambda with or without additional type >> >> info >> >>>> before parameter name? >> >>>> >> >>>> -Sven >> >>>> >> >>>> >> >>>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers >> < >> >> sven.reimers at gmail.com>wrote: >> >>>> >> >>>> >> >>>> >> >>>> Ok. Here you go... >> >>>> >> >>>> I just did an inspection run for the controls module and my IDE came >> up >> >>>> with (drum roll) 888 possible lambda conversions.. >> >>>> >> >>>> Looking through them I discovered that usage of <> (aka diamond >> syntax) >> >>>> is not used (or at least not used a lot) in at least the controls >> >>>> modules. My IDE showed me 1171 occurrences. >> >>>> >> >>>> Is there a good reason not to use diamonds? >> >>>> >> >>>> Will now try to apply all those changes and figure out if this still >> >>>> builds... up next: go through the other modules... >> >>>> >> >>>> -Sven >> >>>> >> >>>> >> >>>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair < >> richard.bair at oracle.com> >> >> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Brian was telling me at J1 that whether parallel gets you performance >> >> or >> >>>> not depends on the size of the collection and the complexity of the >> >> work to >> >>>> perform. There is definitely a point at which parallel helps -- and a >> >> point >> >>>> at which it hurts. >> >>>> >> >>>> Richard >> >>>> >> >>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod < >> >> herve.girod at gmail.com> wrote: >> >>>> >> >>>> >> >>>> >> >>>> Here is a nice example, taking advantage of the ease of going >> >>>> >> >>>> >> >>>> parallel. Apparently the performance without parallel will also >> further >> >>>> improve. >> >> >> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >> >>>> >> >>>> Herv? >> >>>> >> >>>> Sent from my iPad >> >>>> >> >>>> >> >>>> >> >>>> On 4 oct. 2013, at 00:20, David Grieve < >> >> david.grieve at oracle.com> >> >>>> >> >>>> wrote: >> >>>> >> >>>> >> >>>> And what about Stream? I like the declarative code that comes from >> >>>> >> >>>> >> >>>> using Stream and I can see places in the code where Stream could be >> >> used, >> >>>> but I wonder about its performance relative to iterators and/or >> enhanced >> >>>> for loops. >> >>>> >> >>>> >> >>>> On Oct 3, 2013, at 4:45 PM, Richard Bair < >> >> richard.bair at oracle.com> >> >>>> >> >>>> wrote: >> >>>> >> >>>> >> >>>> Hello, OpenJFX Community. >> >>>> >> >>>> There's a question about using Java 8 features in FX. >> >>>> >> >>>> I've been working on the support for InputMethods in JFXPanel which >> >>>> >> >>>> >> >>>> is an important feature for many users who speak hieroglyphic >> >> languages. >> >>>> >> >>>> >> >>>> The issue is tracked under: >> >>>> >> >>>> >> >>>> https://javafx-jira.kenai.com/browse/RT-13248 >> >>>> >> >>>> In order to have a high-quality support we need to change >> >>>> >> >>>> >> >>>> javafx.scene.input.InputMethodRequests interface and introduce 3 new >> >>>> methods. This is not needed for pure FX applications right now, but >> >>>> absolutely required for InputMethods in the JFXPanel. However, the >> >>>> interface is public and it was present since FX2.0, so changing it >> would >> >>>> become a breaking change. So the only way to avoid the problem is >> using >> >> the >> >>>> default methods. Those would return some stub values, the JDK is OK >> with >> >>>> that, as it would not crash or throw exceptions, but text composition >> >> would >> >>>> not work correctly. >> >>>> >> >>>> >> >>>> I know that we want to avoid using the Java 8 features in the >> >>>> >> >>>> >> >>>> JFX-8, so I wanted to ask - is it OK to use the default methods >> here? >> >>>> >> >>>> >> >>>> If you are staying away from JDK8 features for the JFX78 backport, >> >>>> >> >>>> >> >>>> don't worry. There are more issues with new JDK8 APIs than with the >> >> new >> >>>> language features. >> >>>> >> >>>> >> >>>> For example there were default methods put into some collections >> >>>> >> >>>> >> >>>> classes that we solved by pushing them down to the first implements. >> >> But >> >>>> the Date and Time picker depends on the new time package. The >> threeten >> >>>> backport won't be updated until after 8 ships, so that has been >> removed >> >> so >> >>>> far. >> >>>> >> >>>> >> >>>> I'de be interested to know what a wholesale lamdaization would >> >>>> >> >>>> >> >>>> result in speed wise and code size wise (both source and compiled). >> >> From >> >>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so >> it >> >> jsut >> >>>> makes the backport more of a busy work proposition. If there were >> >>>> performance gains it would also make a great front page story in the >> >> next >> >>>> java magazine or a case study.. >> >>>> >> >>>> >> >>>> After having used Lambda's for JavaOne, I'd love to make the >> >>>> >> >>>> >> >>>> conversion, even if in the end the performance was the same, because >> >> the >> >>>> savings in noise in the Java files is so big. At one time I just took >> >> the >> >>>> concurrent classes and lambda-ized them to measure the impact on >> those >> >>>> classes. You could maybe pick a package and just lambda-ize that one >> >>>> package and see what happens in terms of size reduction. We might >> see: >> >>>> >> >>>> >> >>>> + A reduction in the overall class size (not pack-200'd) >> >>>> - An increase in startup time (have to spin up synthetic classes >> >>>> >> >>>> >> >>>> created at usage time) >> >>>> >> >>>> >> >>>> +/- And increase or decrease in performance >> >>>> + A decrease in source code >> >>>> >> >>>> It would be interesting to get some data for these points and see >> >>>> >> >>>> >> >>>> what effect lambda's have. Especially if an IDE can just do it in >> >> bulk? >> >>>> >> >>>> >> >>>> Richard >> >>>> >> >>>> >> >>>> -- >> >>>> Sven Reimers >> >>>> >> >>>> * Senior Expert Software Architect >> >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> >>>> * Community Leader NetBeans: http://community.java.net/netbeans >> >>>> Desktop Java: >> >> http://community.java.net/javadesktop >> >>>> * Duke's Choice Award Winner 2009 >> >>>> * Blog: http://nbguru.blogspot.com >> >>>> >> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >> >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >>>> >> >>>> Join the NetBeans Groups: >> >>>> * XING: http://www.xing.com/group-20148.82db20 >> >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> >>>> http://www.linkedin.com/groups?gid=107402 >> >>>> http://www.linkedin.com/groups?gid=1684717 >> >>>> * Oracle: https://mix.oracle.com/groups/18497 >> >>>> >> >>>> >> >>>> -- >> >>>> Sven Reimers >> >>>> >> >>>> * Senior Expert Software Architect >> >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> >>>> * Community Leader NetBeans: http://community.java.net/netbeans >> >>>> Desktop Java: >> >> http://community.java.net/javadesktop >> >>>> * Duke's Choice Award Winner 2009 >> >>>> * Blog: http://nbguru.blogspot.com >> >>>> >> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >> >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >>>> >> >>>> Join the NetBeans Groups: >> >>>> * XING: http://www.xing.com/group-20148.82db20 >> >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> >>>> http://www.linkedin.com/groups?gid=107402 >> >>>> http://www.linkedin.com/groups?gid=1684717 >> >>>> * Oracle: https://mix.oracle.com/groups/18497 >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >> >> > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From sven.reimers at gmail.com Mon Oct 7 14:42:54 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 7 Oct 2013 23:42:54 +0200 Subject: Lambdafication (was Re: Default methods in JFX-8) In-Reply-To: References: <38406825-A463-441B-9D76-CA57DDBC97E1@oracle.com> <6E736EE2-3D64-44F0-AC49-D03C8A49A5A1@gmail.com> <10D2F934-6F1D-42A8-87EF-10286588A64A@oracle.com> <52529A74.9080500@oracle.com> <5252C37F.5030506@bestsolution.at> Message-ID: Done... https://bitbucket.org/sreimers/openjfx-8-lambdafication Have fun -Sven On Mon, Oct 7, 2013 at 10:42 PM, Sven Reimers wrote: > Ok jfxrt.jar sizes build from openjfx: > > 8165779 -> 7736259 bytes > > Will try to get this into a fork on github so you all can play with the > actual state... > > -Sven > > > On Mon, Oct 7, 2013 at 10:32 PM, Sven Reimers wrote: > >> First batch of statistics (controls submodule so far) >> >> 1630 vs 996 class in controls (my actual state on disk, YMMV) >> >> More statistics to follow... >> >> -Sven >> >> >> On Mon, Oct 7, 2013 at 6:24 PM, Richard Bair wrote: >> >>> My thoughts exactly, which is why I'm grateful for Sven for trying it >>> out :-). I expect that Lambda would make a big reduction in static class >>> count (i.e.: class files), but not a major reduction in class count at >>> runtime (since dynamic classes are created for Lambdas). So a normal Jar >>> should be significantly smaller, while a Pack200 jar probably has little to >>> no difference. Execution speed should be the same. Startup might be faster >>> or slower, I'm not sure (but I would expect it to be negligible). If the >>> jar is significantly reduced in size, it might be useful for embedded which >>> doesn't use Pack200. >>> >>> But we need the data, because making the change at this point, otherwise >>> in a couple months when we get a 9 / 8u workspace opened we can start >>> putting the work in there (since in my mind there is no question but that >>> for 9 we need to complete lamdafication). >>> >>> Richard >>> >>> On Oct 7, 2013, at 8:19 AM, Danno Ferrin >>> wrote: >>> >>> > IntelliJ at least has a decent de-lamba assistant, not sure about >>> NetBeans >>> > since it isn't my daily driver. So I am not concerned about the >>> > backporting impact if (and this is the big if) there is demonstrable >>> > improvement in either jar size, execution speed, or runtime memory >>> impact. >>> > Ideally all three. Worth the hassle in that case. But if all we get >>> from >>> > this is busy work, then i would then question it's value. >>> > >>> > >>> > On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl < >>> tom.schindl at bestsolution.at>wrote: >>> > >>> >> ... I can't see any real improvement for using lambdas beside that you >>> >> killed off warnings which could be fixed otherwise as well. >>> >> >>> >> So I really don't get what it would help us beside making e.g. RoboVM >>> >> our sole chance to get FX on iOS harder to maintain. >>> >> >>> >> Tom >>> >> >>> >> On 07.10.13 16:16, Sven Reimers wrote: >>> >>> Ok. So I will file a P4 saying Lambdafication for Controls >>> >>> and send the diff to Richard/Kevin/Jonathan to be attached.. >>> >>> >>> >>> should I base the change on b110 (master)? >>> >>> >>> >>> I could create a public bitbucket branch based on master and add my >>> >> changes >>> >>> there - better idea? >>> >>> >>> >>> What approach is most simple for review? >>> >>> >>> >>> Should I split test and library code changes? >>> >>> >>> >>> -Sven >>> >>> >>> >>> P.S. Shall I try to get this done as well for other modules? Which >>> would >>> >> be >>> >>> preferred? (Just in case I have some more time to spend) >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth >>> >>> wrote: >>> >>> >>> >>>> ** >>> >>>> >>> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >>> >>>> >>> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >>> >> warnings >>> >>>> >>> >>>> >>> >>>> We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and >>> >>>> getting rid of warnings would be a P4 bug. I guess it depends on how >>> >>>> intrusive the changes are and whether someone has time to review it >>> in >>> >> the >>> >>>> next two weeks. >>> >>>> >>> >>>> -- Kevin >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> Sven Reimers wrote: >>> >>>> >>> >>>> Ok. So here are the results of trying to add lambda and diamond to >>> the >>> >>>> controls module: >>> >>>> >>> >>>> 1. A lot of generics and typing to be fixed (esp. in tests). Seems >>> you >>> >> can >>> >>>> get some anonymous inner classes type checked by the compiler, but >>> not >>> >> the >>> >>>> lambda equivalent.. very interesting. >>> >>>> >>> >>>> 2. 279 Files modified (including tests) >>> >>>> >>> >>>> 3. A lot of the automatic replacements could probably be nicer e.g. >>> >>>> >>> >>>> ft.setOnFinished(new EventHandler() { >>> >>>> @Override public void handle(ActionEvent >>> >>>> actionEvent) { >>> >>>> getChildren().remove(tm.textNode); >>> >>>> } >>> >>>> }); >>> >>>> >>> >>>> was replaced to: >>> >>>> >>> >>>> ft.setOnFinished((ActionEvent actionEvent) -> { >>> >>>> getChildren().remove(tm.textNode); >>> >>>> }); >>> >>>> >>> >>>> most unobtrusive code probably: >>> >>>> >>> >>>> ft.setOnFinished((actionEvent) -> >>> getChildren().remove(tm.textNode)); >>> >>>> >>> >>>> 4. A lot of illegal forward reference errors - these were result of >>> >> missing >>> >>>> this in the automatic transformation from anonymous inner to lambdas >>> >> (seems >>> >>>> the rules are not identical - you have to add "this." as prefix if >>> using >>> >>>> lambdas - not sure this is the expected way it should work) >>> >>>> >>> >>>> 5. Should we enable more -Xlint warnings in OpenJFX build? >>> >>>> >>> >>>> 6. Any chances anything of this can still go in 8 (e.g. get rid of >>> >> warnings >>> >>>> >>> >>>> 7. Probably more things I just can't think of at the moment... >>> >>>> >>> >>>> How to take this forward? If there is interest in the change I could >>> >> make >>> >>>> available... >>> >>>> >>> >>>> Comments? Ideas? >>> >>>> >>> >>>> -Sven >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers < >>> sven.reimers at gmail.com> < >>> >> sven.reimers at gmail.com> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Oh and btw - would you go for lambda with or without additional type >>> >> info >>> >>>> before parameter name? >>> >>>> >>> >>>> -Sven >>> >>>> >>> >>>> >>> >>>> On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers < >>> sven.reimers at gmail.com> < >>> >> sven.reimers at gmail.com>wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Ok. Here you go... >>> >>>> >>> >>>> I just did an inspection run for the controls module and my IDE >>> came up >>> >>>> with (drum roll) 888 possible lambda conversions.. >>> >>>> >>> >>>> Looking through them I discovered that usage of <> (aka diamond >>> syntax) >>> >>>> is not used (or at least not used a lot) in at least the controls >>> >>>> modules. My IDE showed me 1171 occurrences. >>> >>>> >>> >>>> Is there a good reason not to use diamonds? >>> >>>> >>> >>>> Will now try to apply all those changes and figure out if this still >>> >>>> builds... up next: go through the other modules... >>> >>>> >>> >>>> -Sven >>> >>>> >>> >>>> >>> >>>> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair < >>> richard.bair at oracle.com> >>> >> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Brian was telling me at J1 that whether parallel gets you >>> performance >>> >> or >>> >>>> not depends on the size of the collection and the complexity of the >>> >> work to >>> >>>> perform. There is definitely a point at which parallel helps -- and >>> a >>> >> point >>> >>>> at which it hurts. >>> >>>> >>> >>>> Richard >>> >>>> >>> >>>> On Oct 3, 2013, at 3:33 PM, Herv? Girod < >>> >> herve.girod at gmail.com> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> Here is a nice example, taking advantage of the ease of going >>> >>>> >>> >>>> >>> >>>> parallel. Apparently the performance without parallel will also >>> further >>> >>>> improve. >>> >> >>> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/ >>> >>>> >>> >>>> Herv? >>> >>>> >>> >>>> Sent from my iPad >>> >>>> >>> >>>> >>> >>>> >>> >>>> On 4 oct. 2013, at 00:20, David Grieve < >>> >> david.grieve at oracle.com> >>> >>>> >>> >>>> wrote: >>> >>>> >>> >>>> >>> >>>> And what about Stream? I like the declarative code that comes from >>> >>>> >>> >>>> >>> >>>> using Stream and I can see places in the code where Stream could be >>> >> used, >>> >>>> but I wonder about its performance relative to iterators and/or >>> enhanced >>> >>>> for loops. >>> >>>> >>> >>>> >>> >>>> On Oct 3, 2013, at 4:45 PM, Richard Bair >>> < >>> >> richard.bair at oracle.com> >>> >>>> >>> >>>> wrote: >>> >>>> >>> >>>> >>> >>>> Hello, OpenJFX Community. >>> >>>> >>> >>>> There's a question about using Java 8 features in FX. >>> >>>> >>> >>>> I've been working on the support for InputMethods in JFXPanel which >>> >>>> >>> >>>> >>> >>>> is an important feature for many users who speak hieroglyphic >>> >> languages. >>> >>>> >>> >>>> >>> >>>> The issue is tracked under: >>> >>>> >>> >>>> >>> >>>> https://javafx-jira.kenai.com/browse/RT-13248 >>> >>>> >>> >>>> In order to have a high-quality support we need to change >>> >>>> >>> >>>> >>> >>>> javafx.scene.input.InputMethodRequests interface and introduce 3 >>> new >>> >>>> methods. This is not needed for pure FX applications right now, but >>> >>>> absolutely required for InputMethods in the JFXPanel. However, the >>> >>>> interface is public and it was present since FX2.0, so changing it >>> would >>> >>>> become a breaking change. So the only way to avoid the problem is >>> using >>> >> the >>> >>>> default methods. Those would return some stub values, the JDK is OK >>> with >>> >>>> that, as it would not crash or throw exceptions, but text >>> composition >>> >> would >>> >>>> not work correctly. >>> >>>> >>> >>>> >>> >>>> I know that we want to avoid using the Java 8 features in the >>> >>>> >>> >>>> >>> >>>> JFX-8, so I wanted to ask - is it OK to use the default methods >>> here? >>> >>>> >>> >>>> >>> >>>> If you are staying away from JDK8 features for the JFX78 backport, >>> >>>> >>> >>>> >>> >>>> don't worry. There are more issues with new JDK8 APIs than with >>> the >>> >> new >>> >>>> language features. >>> >>>> >>> >>>> >>> >>>> For example there were default methods put into some collections >>> >>>> >>> >>>> >>> >>>> classes that we solved by pushing them down to the first >>> implements. >>> >> But >>> >>>> the Date and Time picker depends on the new time package. The >>> threeten >>> >>>> backport won't be updated until after 8 ships, so that has been >>> removed >>> >> so >>> >>>> far. >>> >>>> >>> >>>> >>> >>>> I'de be interested to know what a wholesale lamdaization would >>> >>>> >>> >>>> >>> >>>> result in speed wise and code size wise (both source and compiled). >>> >> From >>> >>>> what I can tell the IDEs can lambda and de-lambda fairly easily, so >>> it >>> >> jsut >>> >>>> makes the backport more of a busy work proposition. If there were >>> >>>> performance gains it would also make a great front page story in the >>> >> next >>> >>>> java magazine or a case study.. >>> >>>> >>> >>>> >>> >>>> After having used Lambda's for JavaOne, I'd love to make the >>> >>>> >>> >>>> >>> >>>> conversion, even if in the end the performance was the same, >>> because >>> >> the >>> >>>> savings in noise in the Java files is so big. At one time I just >>> took >>> >> the >>> >>>> concurrent classes and lambda-ized them to measure the impact on >>> those >>> >>>> classes. You could maybe pick a package and just lambda-ize that one >>> >>>> package and see what happens in terms of size reduction. We might >>> see: >>> >>>> >>> >>>> >>> >>>> + A reduction in the overall class size (not pack-200'd) >>> >>>> - An increase in startup time (have to spin up synthetic classes >>> >>>> >>> >>>> >>> >>>> created at usage time) >>> >>>> >>> >>>> >>> >>>> +/- And increase or decrease in performance >>> >>>> + A decrease in source code >>> >>>> >>> >>>> It would be interesting to get some data for these points and see >>> >>>> >>> >>>> >>> >>>> what effect lambda's have. Especially if an IDE can just do it in >>> >> bulk? >>> >>>> >>> >>>> >>> >>>> Richard >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Sven Reimers >>> >>>> >>> >>>> * Senior Expert Software Architect >>> >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>> >>>> Desktop Java: >>> >> http://community.java.net/javadesktop >>> >>>> * Duke's Choice Award Winner 2009 >>> >>>> * Blog: http://nbguru.blogspot.com >>> >>>> >>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >>>> >>> >>>> Join the NetBeans Groups: >>> >>>> * XING: http://www.xing.com/group-20148.82db20 >>> >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>> >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>> >>>> http://www.linkedin.com/groups?gid=107402 >>> >>>> http://www.linkedin.com/groups?gid=1684717 >>> >>>> * Oracle: https://mix.oracle.com/groups/18497 >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Sven Reimers >>> >>>> >>> >>>> * Senior Expert Software Architect >>> >>>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> >>>> * Community Leader NetBeans: http://community.java.net/netbeans >>> >>>> Desktop Java: >>> >> http://community.java.net/javadesktop >>> >>>> * Duke's Choice Award Winner 2009 >>> >>>> * Blog: http://nbguru.blogspot.com >>> >>>> >>> >>>> * XING: https://www.xing.com/profile/Sven_Reimers8 >>> >>>> * LinkedIn: http://www.linkedin.com/in/svenreimers >>> >>>> >>> >>>> Join the NetBeans Groups: >>> >>>> * XING: http://www.xing.com/group-20148.82db20 >>> >>>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >>> >>>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >>> >>>> http://www.linkedin.com/groups?gid=107402 >>> >>>> http://www.linkedin.com/groups?gid=1684717 >>> >>>> * Oracle: https://mix.oracle.com/groups/18497 >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >>> >>> >> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * Community Leader NetBeans: http://community.java.net/netbeans >> Desktop Java: >> http://community.java.net/javadesktop >> * Duke's Choice Award Winner 2009 >> * Blog: http://nbguru.blogspot.com >> >> * XING: https://www.xing.com/profile/Sven_Reimers8 >> * LinkedIn: http://www.linkedin.com/in/svenreimers >> >> Join the NetBeans Groups: >> * XING: http://www.xing.com/group-20148.82db20 >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468 >> http://www.linkedin.com/groups?gid=107402 >> http://www.linkedin.com/groups?gid=1684717 >> * Oracle: https://mix.oracle.com/groups/18497 >> > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From richard.bair at oracle.com Mon Oct 7 15:27:50 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 7 Oct 2013 15:27:50 -0700 Subject: Building on Mac with latest Xcode In-Reply-To: References: Message-ID: <8488AC26-2988-4A87-BB9A-245A59E219A9@oracle.com> I just ran into this as well. Instead of editing mac.gradle, you should copy gradle.properties.template to gradle.properties, and add MACOSX_MIN_VERSION=10.8 There should be a more robust way for mac.gradle to find the right version if the old one isn't available. Richard On Oct 7, 2013, at 1:15 PM, Sven Reimers wrote: > Hi, > > since I had to once more reinstall my Mac short before Java One I lost a > couple of updates, so I finally got the latest XCode installed, which does > not include MacOSX 10.7 SDK. > > Fixing building is easy - just change minimum version in > buildSrc/mac.gradle to 10.8 does the trick. > > So what is the "official" "correct" way to circumvent the problem? > > Seems the latest XCode version that shipped 10.7 SDK is 4.4 (if I get this > correct from https://developer.apple.com/downloads/index.action?q=xcode > > Should deinstall the actual version and get back to 4.4? > > Any comments appreciated. > > Thanks > > -Sven > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From kevin.rushforth at oracle.com Mon Oct 7 15:30:00 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 07 Oct 2013 15:30:00 -0700 Subject: Building on Mac with latest Xcode In-Reply-To: References: Message-ID: <525335E8.50606@oracle.com> I know that David DeHaven looked into this. Maybe he will have something to add? For production, we need to use gcc (not clang) and the 10.7 SDK, but having a solution that makes it easy for developers to build with latest would be a good thing. -- Kevin Sven Reimers wrote: > Hi, > > since I had to once more reinstall my Mac short before Java One I lost a > couple of updates, so I finally got the latest XCode installed, which does > not include MacOSX 10.7 SDK. > > Fixing building is easy - just change minimum version in > buildSrc/mac.gradle to 10.8 does the trick. > > So what is the "official" "correct" way to circumvent the problem? > > Seems the latest XCode version that shipped 10.7 SDK is 4.4 (if I get this > correct from https://developer.apple.com/downloads/index.action?q=xcode > > Should deinstall the actual version and get back to 4.4? > > Any comments appreciated. > > Thanks > > -Sven > > From hang.vo at oracle.com Mon Oct 7 16:32:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 07 Oct 2013 23:32:34 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131007233321.4125562E18@hg.openjdk.java.net> Changeset: 78d4d74d1100 Author: rbair Date: 2013-10-07 16:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/78d4d74d1100 RT-33383: background-position: 50% does not center the image Reviewed-by: dgrieve ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java Changeset: 94d55039bc0d Author: rbair Date: 2013-10-07 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/94d55039bc0d [TEST-ONLY]: Moved many manual Region tests over to automated visual tests. Not all tests enabled. Finding bugs along the way in NGRegion. - .idea/RegionTests.iml ! .idea/SystemTests.iml ! .idea/modules.xml ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java - tests/manual/RegionTests/src/main/java/region/RegionBackgroundFillUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBackgroundImageUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBorderImageUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBorderStrokeUITest.java - tests/manual/RegionTests/src/main/java/region/RegionShapeUITest.java - tests/manual/RegionTests/src/main/java/region/RegionUITestBase.java - tests/manual/RegionTests/src/main/resources/region/BlackButton.png - tests/manual/RegionTests/src/main/resources/region/WindowsButton.png - tests/manual/RegionTests/src/main/resources/region/border.png - tests/manual/RegionTests/src/main/resources/region/border at 2x.png - tests/manual/RegionTests/src/main/resources/region/checker.png - tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty.png - tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty at 2x.png - tests/manual/RegionTests/src/main/resources/region/test20x20.png - tests/manual/RegionTests/src/main/resources/region/test20x20 at 2x.png - tests/manual/RegionTests/src/main/resources/region/test48x48.png - tests/manual/RegionTests/src/main/resources/region/test48x48 at 2x.png + tests/system/src/test/java/javafx/scene/layout/RegionBackgroundFillUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionBackgroundImageUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionBorderImageUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionBorderStrokeUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionShapeUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionUITestBase.java ! tests/system/src/test/java/testharness/VisualTestBase.java + tests/system/src/test/resources/javafx/scene/layout/RegionBackgroundImageUITest.html + tests/system/src/test/resources/javafx/scene/layout/border-stretch.png + tests/system/src/test/resources/javafx/scene/layout/border-uneven.png + tests/system/src/test/resources/javafx/scene/layout/border.png + tests/system/src/test/resources/javafx/scene/layout/test20x20.png + tests/system/src/test/resources/javafx/scene/layout/test20x20 at 2x.png + tests/system/src/test/resources/javafx/scene/layout/test48x48.png + tests/system/src/test/resources/javafx/scene/layout/test48x48 at 2x.png From hang.vo at oracle.com Tue Oct 8 03:48:23 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 08 Oct 2013 10:48:23 +0000 Subject: hg: openjfx/8/graphics/rt: RT-24133 Gtk: URL is recognised both as FILE and as URL, linux only, DnD and Clipboard Message-ID: <20131008105024.CEA8162E2A@hg.openjdk.java.net> Changeset: eff4787e6884 Author: Alexander Zvegintsev Date: 2013-10-08 14:31 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eff4787e6884 RT-24133 Gtk: URL is recognised both as FILE and as URL, linux only, DnD and Clipboard ! modules/graphics/src/main/native-glass/gtk/GlassSystemClipboard.cpp ! modules/graphics/src/main/native-glass/gtk/glass_dnd.cpp ! modules/graphics/src/main/native-glass/gtk/glass_general.cpp ! modules/graphics/src/main/native-glass/gtk/glass_general.h From tomas.mikula at gmail.com Tue Oct 8 04:48:11 2013 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Tue, 8 Oct 2013 13:48:11 +0200 Subject: [announce] CodeAreaFX: text area with styled ranges of text In-Reply-To: References: Message-ID: On Mon, Oct 7, 2013 at 5:16 PM, Danno Ferrin wrote: > That. Is. Awesome. > > I don't mean to dissuade you from your code donation, but I feel there may > be more value in keeping this as a separate third party control. The > biggest reason is that once it is in the core it will be released in the > same schedule as the JDK, with no options to do it on it's own schedule. A > secondary a rich third party control ecosystem is viewed as a sign of > maturity, and this control in the third party realm would go a long way to > growing that perception. > > Perhaps ControlsFX or JFXtras would be interested if you don't want to > manage the release and promotion cycles yourself. Thanks, Danno, for your input. There might be a licensing problem. Both ControlsFX and JFXtras use the New BSD license, while in my code there are pieces based on the OpenJFX code, so I guess I'm stuck with GPLv2 with Classpath Exception. Best, Tomas > > > On Mon, Oct 7, 2013 at 7:48 AM, Tomas Mikula wrote: >> >> Hi all, >> >> I implemented a text control that supports assigning style classes to >> portions of text. It is meant to be used for syntax highlighting. >> >> https://github.com/TomasMikula/CodeAreaFX >> >> The code is based on the original TextArea code. This implies the >> license to be GPLv2 with the Classpath Exception. I would be happy to >> contribute it back to the OpenJFX project. >> The idea of using a ListView of TextFlows is borrowed from Tom >> Schindl's StyledTextArea >> (http://fxexperience.com/2013/02/interview-with-tom-schindl-2/). >> >> Check out the demos and the APIs. Feedback really appreciated. Any >> help with the issues >> (https://github.com/TomasMikula/CodeAreaFX/wiki/Known-Issues) would be >> awesome. >> >> Best, >> Tomas > > From hang.vo at oracle.com Tue Oct 8 05:17:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 08 Oct 2013 12:17:43 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33384: avoid using Double.MAX_VALUE and Double.MIN_VALUE Message-ID: <20131008121856.DE9EC62E35@hg.openjdk.java.net> Changeset: f2d3f04c1632 Author: David Grieve Date: 2013-10-08 08:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f2d3f04c1632 RT-33384: avoid using Double.MAX_VALUE and Double.MIN_VALUE ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java From hang.vo at oracle.com Tue Oct 8 07:18:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 08 Oct 2013 14:18:02 +0000 Subject: hg: openjfx/8/graphics/rt: ECLIPSE ONLY: fix .classpath Message-ID: <20131008141852.A9D4762E3E@hg.openjdk.java.net> Changeset: 1b6d4c9bd1a7 Author: snorthov Date: 2013-10-08 07:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1b6d4c9bd1a7 ECLIPSE ONLY: fix .classpath ! .classpath From hang.vo at oracle.com Tue Oct 8 09:32:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 08 Oct 2013 16:32:46 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20131008163347.3D41962E48@hg.openjdk.java.net> Changeset: 61727bf6e832 Author: kcr Date: 2013-10-08 09:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/61727bf6e832 [TEST-ONLY] RT-32950: Enable excluded tests in gradle build Reviewed-by: Chien ! build.gradle ! modules/base/src/test/java/javafx/binding/expression/AbstractNumberExpressionTest.java Changeset: 093ea25436c7 Author: kcr Date: 2013-10-08 09:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/093ea25436c7 RT-21415: Need to add javafx-src.zip to JDK 8 distribution Reviewed-by: David Hill, Felipe ! build.gradle ! gradle.properties.template Changeset: ab9489903f7b Author: Yao Wang Date: 2013-10-08 09:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab9489903f7b RT-26587: 3D Data validation AND RT-30451: FX 8 3D: Need to validate Mesh's data size Summary: Validate input data during FX->NG sync stage. AND Need to validate the size and range of these arrays. Reviewed-by: kcr and cyang ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGTriangleMesh.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseMesh.java ! modules/graphics/src/main/java/javafx/scene/shape/Box.java ! modules/graphics/src/main/java/javafx/scene/shape/Cylinder.java ! modules/graphics/src/main/java/javafx/scene/shape/Sphere.java ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java From tom.schindl at bestsolution.at Tue Oct 8 09:38:08 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 8 Oct 2013 18:38:08 +0200 Subject: hg: openjfx/8/graphics/rt: 3 new changesets In-Reply-To: <20131008163347.3D41962E48@hg.openjdk.java.net> References: <20131008163347.3D41962E48@hg.openjdk.java.net> Message-ID: So where the src.zip end up, so that k can adjust the tooling? Tom Von meinem iPhone gesendet > Am 08.10.2013 um 18:32 schrieb hang.vo at oracle.com: > > Changeset: 61727bf6e832 > Author: kcr > Date: 2013-10-08 09:26 -0700 > URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/61727bf6e832 > > [TEST-ONLY] RT-32950: Enable excluded tests in gradle build > Reviewed-by: Chien > > ! build.gradle > ! modules/base/src/test/java/javafx/binding/expression/AbstractNumberExpressionTest.java > > Changeset: 093ea25436c7 > Author: kcr > Date: 2013-10-08 09:26 -0700 > URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/093ea25436c7 > > RT-21415: Need to add javafx-src.zip to JDK 8 distribution > Reviewed-by: David Hill, Felipe > > ! build.gradle > ! gradle.properties.template > > Changeset: ab9489903f7b > Author: Yao Wang > Date: 2013-10-08 09:30 -0700 > URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab9489903f7b > > RT-26587: 3D Data validation AND RT-30451: FX 8 3D: Need to validate Mesh's data size > Summary: Validate input data during FX->NG sync stage. AND Need to validate the size and range of these arrays. > Reviewed-by: kcr and cyang > > ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java > ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGTriangleMesh.java > ! modules/graphics/src/main/java/com/sun/prism/impl/BaseMesh.java > ! modules/graphics/src/main/java/javafx/scene/shape/Box.java > ! modules/graphics/src/main/java/javafx/scene/shape/Cylinder.java > ! modules/graphics/src/main/java/javafx/scene/shape/Sphere.java > ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java > From hang.vo at oracle.com Tue Oct 8 09:47:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 08 Oct 2013 16:47:50 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20131008164840.709DC62E4A@hg.openjdk.java.net> Changeset: 085053c47663 Author: hudson Date: 2013-10-03 08:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/085053c47663 Added tag 8.0-b110 for changeset 0eb503d2b567 ! .hgtags Changeset: b3fa96512e75 Author: mv157916 Date: 2013-10-03 16:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b3fa96512e75 RT-33356: Update the JDK 8 build number to b110 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: e6331b4daf15 Author: jgodinez Date: 2013-10-08 09:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e6331b4daf15 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - .idea/RegionTests.iml - modules/fxml/src/test/java/javafx/fxml/RT_23413Test.java - modules/fxml/src/test/resources/javafx/fxml/rt_23413.fxml - modules/graphics/src/main/java/com/sun/prism/tkal/Window.java - tests/manual/RegionTests/src/main/java/region/RegionBackgroundFillUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBackgroundImageUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBorderImageUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBorderStrokeUITest.java - tests/manual/RegionTests/src/main/java/region/RegionShapeUITest.java - tests/manual/RegionTests/src/main/java/region/RegionUITestBase.java - tests/manual/RegionTests/src/main/resources/region/BlackButton.png - tests/manual/RegionTests/src/main/resources/region/WindowsButton.png - tests/manual/RegionTests/src/main/resources/region/border.png - tests/manual/RegionTests/src/main/resources/region/border at 2x.png - tests/manual/RegionTests/src/main/resources/region/checker.png - tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty.png - tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty at 2x.png - tests/manual/RegionTests/src/main/resources/region/test20x20.png - tests/manual/RegionTests/src/main/resources/region/test20x20 at 2x.png - tests/manual/RegionTests/src/main/resources/region/test48x48.png - tests/manual/RegionTests/src/main/resources/region/test48x48 at 2x.png From kevin.rushforth at oracle.com Tue Oct 8 09:50:35 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 08 Oct 2013 09:50:35 -0700 Subject: hg: openjfx/8/graphics/rt: 3 new changesets In-Reply-To: References: <20131008163347.3D41962E48@hg.openjdk.java.net> Message-ID: <525437DB.8060504@oracle.com> In the top-level JDK directory, next to src.zip, there will be a javafx-src.zip. -- Kevin Tom Schindl wrote: > So where the src.zip end up, so that k can adjust the tooling? > > Tom > > Von meinem iPhone gesendet > > >> Am 08.10.2013 um 18:32 schrieb hang.vo at oracle.com: >> >> Changeset: 61727bf6e832 >> Author: kcr >> Date: 2013-10-08 09:26 -0700 >> URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/61727bf6e832 >> >> [TEST-ONLY] RT-32950: Enable excluded tests in gradle build >> Reviewed-by: Chien >> >> ! build.gradle >> ! modules/base/src/test/java/javafx/binding/expression/AbstractNumberExpressionTest.java >> >> Changeset: 093ea25436c7 >> Author: kcr >> Date: 2013-10-08 09:26 -0700 >> URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/093ea25436c7 >> >> RT-21415: Need to add javafx-src.zip to JDK 8 distribution >> Reviewed-by: David Hill, Felipe >> >> ! build.gradle >> ! gradle.properties.template >> >> Changeset: ab9489903f7b >> Author: Yao Wang >> Date: 2013-10-08 09:30 -0700 >> URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab9489903f7b >> >> RT-26587: 3D Data validation AND RT-30451: FX 8 3D: Need to validate Mesh's data size >> Summary: Validate input data during FX->NG sync stage. AND Need to validate the size and range of these arrays. >> Reviewed-by: kcr and cyang >> >> ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java >> ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGTriangleMesh.java >> ! modules/graphics/src/main/java/com/sun/prism/impl/BaseMesh.java >> ! modules/graphics/src/main/java/javafx/scene/shape/Box.java >> ! modules/graphics/src/main/java/javafx/scene/shape/Cylinder.java >> ! modules/graphics/src/main/java/javafx/scene/shape/Sphere.java >> ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java >> >> From jonathan.giles at oracle.com Tue Oct 8 12:08:14 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 09 Oct 2013 08:08:14 +1300 Subject: [announce] CodeAreaFX: text area with styled ranges of text In-Reply-To: References: Message-ID: <5254581E.6060706@oracle.com> Tomas, Very nice work! :-) The first step in the process to contribute features / bug fixes back into OpenJFX is to create a Jira issue (or find one that covers the topic). In the case of styled text ranges I don't believe a Jira issue exists, so feel free to open a new issue. This will be the way we can see what is popular and still outstanding in JavaFX, and of course discuss details. I'm not clear on how closely your approach is related to Tom's, but perhaps there is sufficient overlap there that you can collaborate. This may help to improve your API and implementation prior to it being considered for integration into OpenJFX, and will of course help to prevent duplication of effort. Keep up the great work and be sure to keep me in the loop of your progress :-) -- Jonathan On 8/10/2013 2:48 a.m., Tomas Mikula wrote: > Hi all, > > I implemented a text control that supports assigning style classes to > portions of text. It is meant to be used for syntax highlighting. > > https://github.com/TomasMikula/CodeAreaFX > > The code is based on the original TextArea code. This implies the > license to be GPLv2 with the Classpath Exception. I would be happy to > contribute it back to the OpenJFX project. > The idea of using a ListView of TextFlows is borrowed from Tom > Schindl's StyledTextArea > (http://fxexperience.com/2013/02/interview-with-tom-schindl-2/). > > Check out the demos and the APIs. Feedback really appreciated. Any > help with the issues > (https://github.com/TomasMikula/CodeAreaFX/wiki/Known-Issues) would be > awesome. > > Best, > Tomas From swpalmer at gmail.com Tue Oct 8 12:37:59 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 8 Oct 2013 15:37:59 -0400 Subject: Reacting to mouse events on a TreeCell. Is it supposed to be this awkward? Message-ID: I'm investigating a memory leak and it seems that the culprit is event listeners attached to TreeCells The GC roots of my leaks are deep in the JavaFX window/event system In a class extending TreeCell, am calling methods on such as: setOnContextMenuRequested(contextMenuRequestHandler); setOnMouseClicked(mouseEventHandler); setOnDragDetected(dragDetectedHandler); All of the event handlers in this case will have a reference to the TreeCell, either via the implicit reference of the anonymous inner class, or an explicit member I do this in updateItem when the cell is not empty and has a non-null item. If updateItem is called and the cell is empty or has a null item then I clear the event handlers with: setOnContextMenuRequested(null); setOnMouseClicked(null); setOnDragDetected(null); The problem is that TreeView doesn't seem to reuse TreeCells very much. It mostly creates new ones. This means that many TreeCells are disconnected from the scene graph and "lost" while there is still an event handler connected to it. Am I doing something wrong? This seemed like the correct way to deal with dragging and double clicking on tree nodes. The tutorial here: http://docs.oracle.com/javafx/2/ui_controls/tree-view.htm#BABDEADA only goes so far as to add a context menu. (My context menu needs to be constructed dynamically.) So I'm not sure if I'm "allowed" to connect event handlers to TreeCells in this way, but I don't know what the alternative is. I suppose I would have to listen to something to ensure the TreeCell is still part of the scene graph and disconnect the listeners when that changes. It seems a bit awkward. Scott (I'm using 7u40) From jonathan.giles at oracle.com Tue Oct 8 12:48:34 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 09 Oct 2013 08:48:34 +1300 Subject: Reacting to mouse events on a TreeCell. Is it supposed to be this awkward? In-Reply-To: References: Message-ID: <52546192.9090504@oracle.com> I note right at the end you say you're using 7u40. In the JavaFX 2.x series of releases it is true that TreeView misbehaved a bit around cell reuse. This should no longer be the case in JavaFX 8.0. In any case, the best option is to file a bug report and discuss it further in there, especially so if you can reproduce the issue in JavaFX 8.0. One thing that sticks out: you don't say if you're using WeakEventHandler or EventHandler instances. If you're using EventHandler you could consider using WeakEventHandler. This may help to alleviate some of the memory leak. -- Jonathan On 9/10/2013 8:37 a.m., Scott Palmer wrote: > I'm investigating a memory leak and it seems that the culprit is event > listeners attached to TreeCells > > The GC roots of my leaks are deep in the JavaFX window/event system > > In a class extending TreeCell, am calling methods on such as: > > setOnContextMenuRequested(contextMenuRequestHandler); > setOnMouseClicked(mouseEventHandler); > setOnDragDetected(dragDetectedHandler); > > All of the event handlers in this case will have a reference to the > TreeCell, either via the implicit reference of the anonymous inner class, > or an explicit member > > I do this in updateItem when the cell is not empty and has a non-null item. > If updateItem is called and the cell is empty or has a null item then I > clear the event handlers with: > > setOnContextMenuRequested(null); > setOnMouseClicked(null); > setOnDragDetected(null); > > The problem is that TreeView doesn't seem to reuse TreeCells very much. It > mostly creates new ones. This means that many TreeCells are disconnected > from the scene graph and "lost" while there is still an event handler > connected to it. > > Am I doing something wrong? > This seemed like the correct way to deal with dragging and double clicking > on tree nodes. > > The tutorial here: > http://docs.oracle.com/javafx/2/ui_controls/tree-view.htm#BABDEADA > > only goes so far as to add a context menu. (My context menu needs to be > constructed dynamically.) So I'm not sure if I'm "allowed" to connect > event handlers to TreeCells in this way, but I don't know what the > alternative is. > > I suppose I would have to listen to something to ensure the TreeCell is > still part of the scene graph and disconnect the listeners when that > changes. It seems a bit awkward. > > > Scott > (I'm using 7u40) From swpalmer at gmail.com Tue Oct 8 13:00:55 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 8 Oct 2013 16:00:55 -0400 Subject: Reacting to mouse events on a TreeCell. Is it supposed to be this awkward? In-Reply-To: <52546192.9090504@oracle.com> References: <52546192.9090504@oracle.com> Message-ID: Will do. I also just noticed (after using Bindings.select(this.sceneProperty(), "window", "showing") to try to trigger my "diconnecting") that in 7u40 TreeCells seem to remain connected to the scene until I force the tree to repaint. In my app every time I open a document I rebuild a tree. even when listening to the above mentioned binding, nothing was triggering as I loaded new documents until I resized my UI. Then suddenly all those unused TreeCells were "let go". Scott On Tue, Oct 8, 2013 at 3:48 PM, Jonathan Giles wrote: > I note right at the end you say you're using 7u40. In the JavaFX 2.x > series of releases it is true that TreeView misbehaved a bit around cell > reuse. This should no longer be the case in JavaFX 8.0. In any case, the > best option is to file a bug report and discuss it further in there, > especially so if you can reproduce the issue in JavaFX 8.0. > > One thing that sticks out: you don't say if you're using > WeakEventHandler or EventHandler instances. If you're using EventHandler > you could consider using WeakEventHandler. This may help to alleviate > some of the memory leak. > > -- Jonathan > > On 9/10/2013 8:37 a.m., Scott Palmer wrote: > > I'm investigating a memory leak and it seems that the culprit is event > > listeners attached to TreeCells > > > > The GC roots of my leaks are deep in the JavaFX window/event system > > > > In a class extending TreeCell, am calling methods on such as: > > > > setOnContextMenuRequested(contextMenuRequestHandler); > > setOnMouseClicked(mouseEventHandler); > > setOnDragDetected(dragDetectedHandler); > > > > All of the event handlers in this case will have a reference to the > > TreeCell, either via the implicit reference of the anonymous inner class, > > or an explicit member > > > > I do this in updateItem when the cell is not empty and has a non-null > item. > > If updateItem is called and the cell is empty or has a null item then I > > clear the event handlers with: > > > > setOnContextMenuRequested(null); > > setOnMouseClicked(null); > > setOnDragDetected(null); > > > > The problem is that TreeView doesn't seem to reuse TreeCells very much. > It > > mostly creates new ones. This means that many TreeCells are disconnected > > from the scene graph and "lost" while there is still an event handler > > connected to it. > > > > Am I doing something wrong? > > This seemed like the correct way to deal with dragging and double > clicking > > on tree nodes. > > > > The tutorial here: > > http://docs.oracle.com/javafx/2/ui_controls/tree-view.htm#BABDEADA > > > > only goes so far as to add a context menu. (My context menu needs to be > > constructed dynamically.) So I'm not sure if I'm "allowed" to connect > > event handlers to TreeCells in this way, but I don't know what the > > alternative is. > > > > I suppose I would have to listen to something to ensure the TreeCell is > > still part of the scene graph and disconnect the listeners when that > > changes. It seems a bit awkward. > > > > > > Scott > > (I'm using 7u40) > > From swpalmer at gmail.com Tue Oct 8 13:09:35 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 8 Oct 2013 16:09:35 -0400 Subject: Reacting to mouse events on a TreeCell. Is it supposed to be this awkward? In-Reply-To: References: <52546192.9090504@oracle.com> Message-ID: FYI.. my first test with Java 8 I get the following exception when I try to do: Bindings.select(this.sceneProperty(), "window", "showing").addListener(... (which may not be necessary on JavaFX 8, but I think I need it for 7u40) 10-08 16:07:22 INFO beans [JavaFX Application Thread]: Property 'window' in ReadOnlyObjectProperty [bean: BrowserTreeCell at 63eb8c04[styleClass=cell indexed-cell tree-cell]'null', name: scene, value: null] is null java.lang.NullPointerException at com.sun.javafx.binding.SelectBinding$SelectBindingHelper.getObservableValue(Unknown Source) at com.sun.javafx.binding.SelectBinding$AsObject.computeValue(Unknown Source) at javafx.beans.binding.ObjectBinding.get(Unknown Source) at javafx.beans.binding.ObjectExpression.getValue(Unknown Source) at com.sun.javafx.binding.ExpressionHelper$SingleChange.(Unknown Source) at com.sun.javafx.binding.ExpressionHelper$SingleChange.(Unknown Source) at com.sun.javafx.binding.ExpressionHelper.addListener(Unknown Source) at javafx.beans.binding.ObjectBinding.addListener(Unknown Source) On Tue, Oct 8, 2013 at 4:00 PM, Scott Palmer wrote: > Will do. > > I also just noticed (after using Bindings.select(this.sceneProperty(), > "window", "showing") to try to trigger my "diconnecting") that in 7u40 > TreeCells seem to remain connected to the scene until I force the tree to > repaint. > In my app every time I open a document I rebuild a tree. even when > listening to the above mentioned binding, nothing was triggering as I > loaded new documents until I resized my UI. Then suddenly all those unused > TreeCells were "let go". > > > Scott > > > On Tue, Oct 8, 2013 at 3:48 PM, Jonathan Giles wrote: > >> I note right at the end you say you're using 7u40. In the JavaFX 2.x >> series of releases it is true that TreeView misbehaved a bit around cell >> reuse. This should no longer be the case in JavaFX 8.0. In any case, the >> best option is to file a bug report and discuss it further in there, >> especially so if you can reproduce the issue in JavaFX 8.0. >> >> One thing that sticks out: you don't say if you're using >> WeakEventHandler or EventHandler instances. If you're using EventHandler >> you could consider using WeakEventHandler. This may help to alleviate >> some of the memory leak. >> >> -- Jonathan >> >> On 9/10/2013 8:37 a.m., Scott Palmer wrote: >> > I'm investigating a memory leak and it seems that the culprit is event >> > listeners attached to TreeCells >> > >> > The GC roots of my leaks are deep in the JavaFX window/event system >> > >> > In a class extending TreeCell, am calling methods on such as: >> > >> > setOnContextMenuRequested(contextMenuRequestHandler); >> > setOnMouseClicked(mouseEventHandler); >> > setOnDragDetected(dragDetectedHandler); >> > >> > All of the event handlers in this case will have a reference to the >> > TreeCell, either via the implicit reference of the anonymous inner >> class, >> > or an explicit member >> > >> > I do this in updateItem when the cell is not empty and has a non-null >> item. >> > If updateItem is called and the cell is empty or has a null item then I >> > clear the event handlers with: >> > >> > setOnContextMenuRequested(null); >> > setOnMouseClicked(null); >> > setOnDragDetected(null); >> > >> > The problem is that TreeView doesn't seem to reuse TreeCells very much. >> It >> > mostly creates new ones. This means that many TreeCells are >> disconnected >> > from the scene graph and "lost" while there is still an event handler >> > connected to it. >> > >> > Am I doing something wrong? >> > This seemed like the correct way to deal with dragging and double >> clicking >> > on tree nodes. >> > >> > The tutorial here: >> > http://docs.oracle.com/javafx/2/ui_controls/tree-view.htm#BABDEADA >> > >> > only goes so far as to add a context menu. (My context menu needs to be >> > constructed dynamically.) So I'm not sure if I'm "allowed" to connect >> > event handlers to TreeCells in this way, but I don't know what the >> > alternative is. >> > >> > I suppose I would have to listen to something to ensure the TreeCell is >> > still part of the scene graph and disconnect the listeners when that >> > changes. It seems a bit awkward. >> > >> > >> > Scott >> > (I'm using 7u40) >> >> > From thor.johannesson at oracle.com Tue Oct 8 13:43:43 2013 From: thor.johannesson at oracle.com (Thor Johannesson) Date: Tue, 8 Oct 2013 13:43:43 -0700 Subject: API Change Proposal - Re: MSAA and Scene anti aliasing In-Reply-To: <51F04917.5030800@oracle.com> References: <13A200AA-4A33-42DB-8667-527FD47F2177@oracle.com> <6BBDB458-57C4-4E58-9E8A-458D0BB064D2@muenster.de> <51E1A3DA.1080106@oracle.com> <0ED4F449-CA7E-423D-B394-737EB4AA3C33@oracle.com> <51E40FD6.6030504@oracle.com> <4C5E8A28-DE1F-423A-AB50-B03EB8AC972D@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D22167E317057@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <51EEE7A9.2010205@oracle.com> <51F04917.5030800@oracle.com> Message-ID: <3B19E27D-79E9-42FD-B386-91AB8B23F396@oracle.com> Hi All, Need to revive this thread, to remind everyone that anti-aliasing API change is going in. And should be available in build b112. See bug report for some further detail/discussion: https://javafx-jira.kenai.com/browse/RT-31878 Initially only available anti-aliasing modes are BALANCED and DISABLED, as per decision by Kevin and Richard. FASTEST and NICEST should come later. The new class SceneAntialiasing should resembled below: /** * The JavaFX {@code SceneAntialiasing} class specifies the level of * anti-aliasing desired. Scene anti-aliasing is primarily used when rendering * 3D primitives, which are otherwise rendered aliased. *

* Note: In order for {@code SceneAntialiasing} to have an affect, the underlying * system must support: * {@link javafx.application.ConditionalFeature#SCENE3D ConditionalFeature.SCENE3D} * and anti-aliasing. *

* @since JavaFX 8.0 */ public final class SceneAntialiasing { /** * Disables anti-aliasing */ public static final SceneAntialiasing DISABLED = new SceneAntialiasing("DISABLED"); /** * Enables anti-aliasing optimizing for a balance of quality and performance */ public static final SceneAntialiasing BALANCED = new SceneAntialiasing("BALANCED"); ... private SceneAntialiasing(String value) { val = value; } } Note this is a potential breaking change, and the following constructors will change! Constructors remove: public Scene(Parent root, double width, double height, boolean depthBuffer, boolean antiAliasing) public SubScene(Parent root, double width, double height, boolean depthBuffer, boolean antiAliasing) Constructor add: public Scene(Parent root, double width, double height, boolean depthBuffer, SceneAntiAliasing antiAliasing) public SubScene(Parent root, double width, double height, boolean depthBuffer, SceneAntiAliasing antiAliasing) -Thor On Jul 24, 2013, at 2:37 PM, Chien Yang wrote: > Thank you for the feedback! We decided to drop DEFAULT in favor of BALANCED. So here is the revised SceneAntiAliasing enum entries: > > public enum SceneAntiAliasing { > BALANCED, // enables anti-aliasing using optimal system setting available that balances speed and quality > DISABLED, // disables anti-aliasing > FASTEST, // enables anti-aliasing using minimum system setting available that results in better frame rate > NICEST // enables anti-aliasing using maximum system setting available that results in best visual quality > } > > Thanks, > - Chien > > On 7/23/2013 1:29 PM, Chien Yang wrote: >> Hi all, >> >> We appreciate all the feedback you have contributed to this topic. After listening to the feedback and an internal discussion, we would like to propose a minor change to the API for supporting scene anti-aliasing. We intentionally choose not to expose the number of samples and techniques used in this release, but this doesn't preclude future addition when the time is right for more options. This change will be tracked by RT-31878 (https://javafx-jira.kenai.com/browse/RT-31878): >> >> Anti-aliasing API Change Proposal: >> >> Constructors remove: >> public Scene(Parent root, double width, double height, boolean depthBuffer, boolean antiAliasing) >> public SubScene(Parent root, double width, double height, boolean depthBuffer, boolean antiAliasing) >> >> Constructor add: >> public Scene(Parent root, double width, double height, boolean depthBuffer, SceneAntiAliasing antiAliasing) >> public SubScene(Parent root, double width, double height, boolean depthBuffer, SceneAntiAliasing antiAliasing) >> >> Note:The antiAliasing argument will be used if the underlying graphics driver has anti-aliasing support. >> >> Where SceneAntiAliasing is an enum with the following entries at the moment: >> >> public enum SceneAntiAliasing { >> DISABLED, // disables anti-aliasing >> DEFAULT, // enables anti-aliasing using a default system setting available that balances speed and quality >> FASTEST, // enables anti-aliasing using minimum system setting available that results in better frame rate >> NICEST // enables anti-aliasing using maximum system setting available that results in best visual quality >> } >> >> Thanks, >> - Chien > From hang.vo at oracle.com Tue Oct 8 14:33:04 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 08 Oct 2013 21:33:04 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131008213356.F3F2D62E64@hg.openjdk.java.net> Changeset: 23a4702aac22 Author: rbair Date: 2013-10-08 12:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/23a4702aac22 RT-29794: NPE from NGRegion in Ensemble8 Reviewed-by: lnerad ! modules/graphics/src/main/java/com/sun/javafx/scene/DirtyBits.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/javafx/scene/image/Image.java ! modules/graphics/src/main/java/javafx/scene/layout/Region.java ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubImageLoader.java ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubToolkit.java + modules/graphics/src/test/java/com/sun/javafx/pgstub/StubWritablePlatformImage.java + modules/graphics/src/test/java/javafx/scene/image/ImageForTesting.java ! modules/graphics/src/test/java/javafx/scene/layout/RegionTest.java Changeset: c878df60c9d7 Author: rbair Date: 2013-10-08 14:16 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c878df60c9d7 RT-19809: Border image and border stroke rendering order Reviewed-by: jasper ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java From hang.vo at oracle.com Tue Oct 8 15:03:13 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 08 Oct 2013 22:03:13 +0000 Subject: hg: openjfx/8/graphics/rt: [TEST-ONLY]: Added test exposed by question in RT-13820 Message-ID: <20131008220347.C4B8162E65@hg.openjdk.java.net> Changeset: 9491417fb3e0 Author: rbair Date: 2013-10-08 14:46 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9491417fb3e0 [TEST-ONLY]: Added test exposed by question in RT-13820 ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGRegionTest.java From hang.vo at oracle.com Tue Oct 8 15:47:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 08 Oct 2013 22:47:43 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31878: API: Change anti-aliasing support from a bool to SceneAntialiasing object. Reviewed Kevin, Richard Message-ID: <20131008224836.B2D0562E69@hg.openjdk.java.net> Changeset: 08be4f8a1a1f Author: Thor Johannesson Date: 2013-10-08 15:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/08be4f8a1a1f RT-31878: API: Change anti-aliasing support from a bool to SceneAntialiasing object. Reviewed Kevin, Richard ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/height2normal/Height2NormalApp.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/ContentModel.java ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/SimpleViewerApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/xylophone/XylophoneApp.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/javafx/scene/Scene.java + modules/graphics/src/main/java/javafx/scene/SceneAntialiasing.java ! modules/graphics/src/main/java/javafx/scene/SubScene.java ! modules/graphics/src/test/java/javafx/scene/Mouse3DTest.java ! modules/graphics/src/test/java/javafx/scene/MouseTest.java From tomas.mikula at gmail.com Tue Oct 8 16:39:18 2013 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Wed, 9 Oct 2013 01:39:18 +0200 Subject: [announce] CodeAreaFX: text area with styled ranges of text In-Reply-To: <5254581E.6060706@oracle.com> References: <5254581E.6060706@oracle.com> Message-ID: Thanks, Jonathan. On Tue, Oct 8, 2013 at 9:08 PM, Jonathan Giles wrote: > Tomas, > > Very nice work! :-) > > The first step in the process to contribute features / bug fixes back > into OpenJFX is to create a Jira issue (or find one that covers the > topic). In the case of styled text ranges I don't believe a Jira issue > exists, so feel free to open a new issue. This will be the way we can > see what is popular and still outstanding in JavaFX, and of course > discuss details. > > I'm not clear on how closely your approach is related to Tom's, but > perhaps there is sufficient overlap there that you can collaborate. I think the main differences are: 1. Tom's StyledTextArea assigns styles, while my CodeArea assigns style classes. I think my approach is easier to work with, but less powerful (you can only use styles pre-defined in a stylesheet, thus you can't implement a rich text editor on top of CodeArea). 2. StyledTextArea's API assigns styles for the whole content at once, CodeArea assigns one range at a time. I think both approaches have their use and I plan to add support for batch assignment for performance reasons. 3. AFAIK, StyledTextArea does not support text selection. 4. Compared to TextArea, CodeArea supports detailed change events (which part of text was replaced) via TextChangeListener (http://tomasmikula.github.io/CodeAreaFX/codearea/control/TextChangeListener.html). Not sure about StyledTextArea. > This > may help to improve your API and implementation prior to it being > considered for integration into OpenJFX, and will of course help to > prevent duplication of effort. I don't consider the API to be final, quite opposite, I expect changes arising from the community and from my own needs. I'm open to feedback and suggestions. Regards, Tomas > > Keep up the great work and be sure to keep me in the loop of your > progress :-) > > -- Jonathan > > On 8/10/2013 2:48 a.m., Tomas Mikula wrote: >> Hi all, >> >> I implemented a text control that supports assigning style classes to >> portions of text. It is meant to be used for syntax highlighting. >> >> https://github.com/TomasMikula/CodeAreaFX >> >> The code is based on the original TextArea code. This implies the >> license to be GPLv2 with the Classpath Exception. I would be happy to >> contribute it back to the OpenJFX project. >> The idea of using a ListView of TextFlows is borrowed from Tom >> Schindl's StyledTextArea >> (http://fxexperience.com/2013/02/interview-with-tom-schindl-2/). >> >> Check out the demos and the APIs. Feedback really appreciated. Any >> help with the issues >> (https://github.com/TomasMikula/CodeAreaFX/wiki/Known-Issues) would be >> awesome. >> >> Best, >> Tomas > From pedro.duquevieira at gmail.com Tue Oct 8 17:19:10 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 9 Oct 2013 01:19:10 +0100 Subject: Keyboard events In-Reply-To: <5252E966.3020707@oracle.com> References: <52529340.4080205@oracle.com> <5252E966.3020707@oracle.com> Message-ID: Do you want me to file a Jira issue for this? Regards, On Mon, Oct 7, 2013 at 6:03 PM, Artem Ananiev wrote: > > On 10/7/2013 6:53 PM, Richard Bair wrote: > >> That being said, this seems like a very common use case, and I wonder if >> there is something more we could do (in the longer term, short term do as >> Artem suggests) >> > > One of the options is to provide API to query for keyboard state at any > arbitrary moment, whether particular key is pressed or not. Even if we only > support locking keys (Caps, Num, Scroll, Kana) and control keys (Shift, > Control, Command, Alt), it will be of great value. Game developers will be > happy to have such API for all the keys, including navigation and letter > ones. > > Thanks, > > Artem > > > On Oct 7, 2013, at 3:56 AM, Artem Ananiev >>> wrote: >>> >>> >>> On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: >>>> Hi, >>>> >>>> I have the following use case: >>>> When the user presses shift and the mouse is hover the chart component >>>> the >>>> cursor must change to an open hand cursor signaling to the user that the >>>> chart is ready for a panning action. >>>> The problem is that for this to be possible I want the chart to be able >>>> to >>>> listen to keyboard events even when it doesn't have focus. >>>> >>>> I think this is not possible and I wonder why. Swing was the same, you >>>> could only listen to keyboard events if the control had focus. Is this a >>>> technical limitation? If there is no technical limitation I think it >>>> would >>>> be better to remove this restriction, I think it is limiting and the >>>> above >>>> scenario is a good use case to show that. >>>> >>> >>> This is not a technical limitation, it's just the way how it's supposed >>> to work. All the key events are dispatched to the component in focus, this >>> is what input focus is. >>> >>> Scenario you described should be easier to implement in FX than in >>> Swing. In AWT/Swing, input events are dispatched to a single component, >>> while FX is much more flexible. All the events are delivered to a Scene >>> first, then dispatched to the focused component (or component under mouse, >>> for mouse events), then bubbled up back to the Scene. What you need is to >>> register a custom event filter for the scene and listen to all the key >>> events. >>> >>> See Scene.addEventFilter() and Scene.addEventHandler() for details. >>> >>> Thanks, >>> >>> Artem >>> >>> Thanks, best regards, >>>> >>>> -- Pedro Duque Vieira From hang.vo at oracle.com Tue Oct 8 18:17:38 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 01:17:38 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32285: Confidential code pushed to OpenJFX rt Message-ID: <20131009011809.5F59462E6C@hg.openjdk.java.net> Changeset: 384af3fa2b97 Author: rbair Date: 2013-10-08 18:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/384af3fa2b97 RT-32285: Confidential code pushed to OpenJFX rt ! modules/fxpackager/src/main/native/javafxpackager/win/javafxpackager.rc ! modules/fxpackager/src/main/native/launcher/linux/DeployPlatform.h ! modules/fxpackager/src/main/native/launcher/linux/xmlparser.c ! modules/fxpackager/src/main/native/launcher/linux/xmlparser.h ! modules/fxpackager/src/main/resources/resources/web-files/dtjava.js ! modules/graphics/src/main/java/netscape/javascript/JSException.java ! modules/graphics/src/main/java/netscape/javascript/JSObject.java From hang.vo at oracle.com Wed Oct 9 03:03:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 10:03:06 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: caching paint texture + support for Texture.contentWidth/Height (RT-33314) Message-ID: <20131009100407.39D9262E7A@hg.openjdk.java.net> Changeset: bf0821d697e2 Author: Martin Soch Date: 2013-10-09 11:49 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bf0821d697e2 SW pipeline: caching paint texture + support for Texture.contentWidth/Height (RT-33314) ! modules/graphics/src/main/java/com/sun/pisces/PiscesRenderer.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWArgbPreTexture.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWContext.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWMaskTexture.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWPaint.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWRTTexture.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWTexture.java ! modules/graphics/src/main/native-prism-sw/JPiscesRenderer.c From hang.vo at oracle.com Wed Oct 9 04:03:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 11:03:09 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131009110342.9FA6A62E80@hg.openjdk.java.net> Changeset: b15183983958 Author: Assaf Yavani Date: 2013-10-09 12:52 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b15183983958 [RT-32802] Lens: touch events are not handled corectly - step 1 Summary: Remove timer usage that was used to filter quick touch events sequence such as tap/release/tap and tap/move/release. Timer usage is not applicable for multi touch and causes timing issues Tested by: running helloworld.HelloSanity::controls and LinuxInputTests (which fails on 1 test, will be fixed in a different forest commit) on the Beagle Board Reviewed-by: David Hill (david.hill at oracle.com), Lisa Selle (lisa.selle at oracle.com), Rafi Tayar (rafi.tayar at oracle.com) and Daniel Blaukopf (Daniel.Blaukopf at Oracle.com) Contributed-by: ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensTouchInputSupport.java ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c Changeset: 92f833210f83 Author: Assaf Yavani Date: 2013-10-09 13:54 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/92f833210f83 Automated merge with file:///home/assaf/ws/udev-refactoring/rt From artem.ananiev at oracle.com Wed Oct 9 04:11:14 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 09 Oct 2013 15:11:14 +0400 Subject: Keyboard events In-Reply-To: References: <52529340.4080205@oracle.com> <5252E966.3020707@oracle.com> Message-ID: <525539D2.5040808@oracle.com> On 10/9/2013 4:19 AM, Pedro Duque Vieira wrote: > Do you want me to file a Jira issue for this? Yes, please. I haven't found such a feature request in JavaFX JIRA. The only issue which is slightly related is https://javafx-jira.kenai.com/browse/RT-32302 but it's not exactly about querying for keyboard state. Thanks, Artem > Regards, > > > On Mon, Oct 7, 2013 at 6:03 PM, Artem Ananiev > wrote: > > > On 10/7/2013 6:53 PM, Richard Bair wrote: > > That being said, this seems like a very common use case, and I > wonder if there is something more we could do (in the longer > term, short term do as Artem suggests) > > > One of the options is to provide API to query for keyboard state at > any arbitrary moment, whether particular key is pressed or not. Even > if we only support locking keys (Caps, Num, Scroll, Kana) and > control keys (Shift, Control, Command, Alt), it will be of great > value. Game developers will be happy to have such API for all the > keys, including navigation and letter ones. > > Thanks, > > Artem > > > On Oct 7, 2013, at 3:56 AM, Artem Ananiev > > > wrote: > > > On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: > Hi, > > I have the following use case: > When the user presses shift and the mouse is hover the > chart component the > cursor must change to an open hand cursor signaling to > the user that the > chart is ready for a panning action. > The problem is that for this to be possible I want the > chart to be able to > listen to keyboard events even when it doesn't have focus. > > I think this is not possible and I wonder why. Swing was > the same, you > could only listen to keyboard events if the control had > focus. Is this a > technical limitation? If there is no technical > limitation I think it would > be better to remove this restriction, I think it is > limiting and the above > scenario is a good use case to show that. > > > This is not a technical limitation, it's just the way how > it's supposed to work. All the key events are dispatched to > the component in focus, this is what input focus is. > > Scenario you described should be easier to implement in FX > than in Swing. In AWT/Swing, input events are dispatched to > a single component, while FX is much more flexible. All the > events are delivered to a Scene first, then dispatched to > the focused component (or component under mouse, for mouse > events), then bubbled up back to the Scene. What you need is > to register a custom event filter for the scene and listen > to all the key events. > > See Scene.addEventFilter() and Scene.addEventHandler() for > details. > > Thanks, > > Artem > > Thanks, best regards, > > > > > -- > Pedro Duque Vieira From hang.vo at oracle.com Wed Oct 9 06:17:40 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 13:17:40 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33089 : Add support for imx6 Message-ID: <20131009131823.ECDA062E8C@hg.openjdk.java.net> Changeset: 19ca9150cb33 Author: Rafi Tayar Date: 2013-10-09 15:08 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/19ca9150cb33 RT-33089 : Add support for imx6 Reviewed-by: ddhill dblaukop ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! modules/graphics/src/main/native-glass/lens/cursor/fbCursor/fbCursor.c ! modules/graphics/src/main/native-glass/lens/platform-util/fbRobot.c + modules/graphics/src/main/native-glass/lens/platform-util/imx6Cursor.c ! modules/graphics/src/main/native-glass/lens/platform-util/initPlatform.c ! modules/graphics/src/main/native-glass/lens/platform-util/platformUtil.h ! modules/graphics/src/main/native-glass/lens/platform-util/utilInternal.h ! modules/graphics/src/main/native-prism-es2/eglfb/wrapped_egl.c From hang.vo at oracle.com Wed Oct 9 06:33:18 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 13:33:18 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32876: if scene root is NODE_CSS dirty after layout, mark root NODE_CSS dirty again if dirty bits are cleared. Reviewed by: jgiles Message-ID: <20131009133342.33ADE62E8F@hg.openjdk.java.net> Changeset: 626769790d33 Author: David Grieve Date: 2013-10-09 09:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/626769790d33 RT-32876: if scene root is NODE_CSS dirty after layout, mark root NODE_CSS dirty again if dirty bits are cleared. Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! modules/graphics/src/main/java/javafx/scene/Scene.java From sven.reimers at gmail.com Wed Oct 9 07:17:30 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 9 Oct 2013 16:17:30 +0200 Subject: TabPane Performance RT24105 Message-ID: Hi, just figured out TabPane performance fixing has moved to Van Ness... So having a TabPane with lots of tabs and a lot of complex content (e.g. charts which do live update) will consume to much CPU until this gets fixed in VanNess.. This makes using TabPane for complex scenarios a really bad out of the box experience. You have to figure out your own workarounds... I can understand that the API changes for lazy loading are rescheduled for Van Ness, but the other part of the issue is raw performance... Any chance we can split this and get the performance fixed for Lambard? Thanks for your support -Sven -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From hang.vo at oracle.com Wed Oct 9 07:33:14 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 14:33:14 +0000 Subject: hg: openjfx/8/graphics/rt: [RT-32802] Lens: touch events are not handled corectly - step 1.1 Message-ID: <20131009143359.E423062E92@hg.openjdk.java.net> Changeset: fc10585918af Author: Assaf Yavani Date: 2013-10-09 17:27 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fc10585918af [RT-32802] Lens: touch events are not handled corectly - step 1.1 Summary: [minor] - removal of unused code Reviewed by: dblaukop, Rafi Tayar ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c From hang.vo at oracle.com Wed Oct 9 09:47:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 16:47:56 +0000 Subject: hg: openjfx/8/graphics/rt: RT-13820: NGRegion doesn't mark itself dirty when its shape geometry changes Message-ID: <20131009164825.A4DF662E9B@hg.openjdk.java.net> Changeset: 6529a035133f Author: rbair Date: 2013-10-09 09:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6529a035133f RT-13820: NGRegion doesn't mark itself dirty when its shape geometry changes Reviewed-by: felipe ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/test/java/javafx/scene/layout/RegionTest.java From hang.vo at oracle.com Wed Oct 9 10:03:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 17:03:08 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131009170345.7D66D62E9E@hg.openjdk.java.net> Changeset: 5e4e3c814d63 Author: rbair Date: 2013-10-09 09:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5e4e3c814d63 [TEST-ONLY] Disable some tests and comment out a couple asserts for RT-33446 until we have a better solution ! tests/system/src/test/java/javafx/scene/layout/RegionBackgroundFillUITest.java Changeset: ebf65cac9188 Author: "Joseph Andresen" Date: 2013-10-09 09:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ebf65cac9188 RT-25407 setTextAlign(null) NPE canvas from switch(enum). Reviewed by: Jim,Felipe,Kevin,Thor ! modules/graphics/src/main/java/javafx/scene/canvas/GraphicsContext.java From hang.vo at oracle.com Wed Oct 9 11:02:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 18:02:45 +0000 Subject: hg: openjfx/8/graphics/rt: RT-23700: remove GIFImageLoader and PNGImageLoader classes Message-ID: <20131009180329.5C1FF62EA4@hg.openjdk.java.net> Changeset: 77b37fa187c3 Author: rbair Date: 2013-10-09 10:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/77b37fa187c3 RT-23700: remove GIFImageLoader and PNGImageLoader classes Reviewed-by: kcr - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFImageLoader.java ! modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFImageLoaderFactory.java - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFImageMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFStreamMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGImageLoader.java ! modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGImageLoaderFactory.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGImageMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGRowFilter.java From hang.vo at oracle.com Wed Oct 9 11:17:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 18:17:33 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30864 Ensemble8: port BrickBreaker performance improvement to Ensemble8 Message-ID: <20131009181752.EBD4962EA5@hg.openjdk.java.net> Changeset: b29e81699ea1 Author: dmasada Date: 2013-10-09 11:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b29e81699ea1 RT-30864 Ensemble8: port BrickBreaker performance improvement to Ensemble8 ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/brickbreaker/Config.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/brickbreaker/Level.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/brickbreaker/Splash.java From hang.vo at oracle.com Wed Oct 9 12:17:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 19:17:36 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33324: TreeView.getSelectionModel().getSelectedItems() sends 2 events when changing selection Message-ID: <20131009191821.CEE1B62EAB@hg.openjdk.java.net> Changeset: 831e7cb4702a Author: jgiles Date: 2013-10-09 14:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/831e7cb4702a RT-33324: TreeView.getSelectionModel().getSelectedItems() sends 2 events when changing selection Reviewed-by: psomashe ! modules/controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/MultipleSelectionModelImplTest.java From pedro.duquevieira at gmail.com Wed Oct 9 16:11:30 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 10 Oct 2013 00:11:30 +0100 Subject: Keyboard events In-Reply-To: <525539D2.5040808@oracle.com> References: <52529340.4080205@oracle.com> <5252E966.3020707@oracle.com> <525539D2.5040808@oracle.com> Message-ID: Done. https://javafx-jira.kenai.com/browse/RT-33458 Thanks, best regards, On Wed, Oct 9, 2013 at 12:11 PM, Artem Ananiev wrote: > > On 10/9/2013 4:19 AM, Pedro Duque Vieira wrote: > >> Do you want me to file a Jira issue for this? >> > > Yes, please. > > I haven't found such a feature request in JavaFX JIRA. The only issue > which is slightly related is > > https://javafx-jira.kenai.com/**browse/RT-32302 > > but it's not exactly about querying for keyboard state. > > Thanks, > > Artem > > Regards, >> >> >> On Mon, Oct 7, 2013 at 6:03 PM, Artem Ananiev > >> wrote: >> >> >> On 10/7/2013 6:53 PM, Richard Bair wrote: >> >> That being said, this seems like a very common use case, and I >> wonder if there is something more we could do (in the longer >> term, short term do as Artem suggests) >> >> >> One of the options is to provide API to query for keyboard state at >> any arbitrary moment, whether particular key is pressed or not. Even >> if we only support locking keys (Caps, Num, Scroll, Kana) and >> control keys (Shift, Control, Command, Alt), it will be of great >> value. Game developers will be happy to have such API for all the >> keys, including navigation and letter ones. >> >> Thanks, >> >> Artem >> >> >> On Oct 7, 2013, at 3:56 AM, Artem Ananiev >> >> >> >> >> wrote: >> >> >> On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: >> Hi, >> >> I have the following use case: >> When the user presses shift and the mouse is hover the >> chart component the >> cursor must change to an open hand cursor signaling to >> the user that the >> chart is ready for a panning action. >> The problem is that for this to be possible I want the >> chart to be able to >> listen to keyboard events even when it doesn't have focus. >> >> I think this is not possible and I wonder why. Swing was >> the same, you >> could only listen to keyboard events if the control had >> focus. Is this a >> technical limitation? If there is no technical >> limitation I think it would >> be better to remove this restriction, I think it is >> limiting and the above >> scenario is a good use case to show that. >> >> >> This is not a technical limitation, it's just the way how >> it's supposed to work. All the key events are dispatched to >> the component in focus, this is what input focus is. >> >> Scenario you described should be easier to implement in FX >> than in Swing. In AWT/Swing, input events are dispatched to >> a single component, while FX is much more flexible. All the >> events are delivered to a Scene first, then dispatched to >> the focused component (or component under mouse, for mouse >> events), then bubbled up back to the Scene. What you need is >> to register a custom event filter for the scene and listen >> to all the key events. >> >> See Scene.addEventFilter() and Scene.addEventHandler() for >> details. >> >> Thanks, >> >> Artem >> >> Thanks, best regards, >> >> >> >> >> -- >> Pedro Duque Vieira >> > -- Pedro Duque Vieira From hang.vo at oracle.com Wed Oct 9 16:32:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 09 Oct 2013 23:32:47 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32708: Empty column header, when hiding a column. Message-ID: <20131009233305.6AF7462EB6@hg.openjdk.java.net> Changeset: 3f2d17da0430 Author: jgiles Date: 2013-10-10 10:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3f2d17da0430 RT-32708: Empty column header, when hiding a column. Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/test/Person.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java From hang.vo at oracle.com Wed Oct 9 21:03:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 04:03:17 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31320: TextField stretches to cursor position on embedded when touch is enabled Message-ID: <20131010040406.4A16D62EBD@hg.openjdk.java.net> Changeset: c9ccb2552c68 Author: jgiles Date: 2013-10-10 16:51 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c9ccb2552c68 RT-31320: TextField stretches to cursor position on embedded when touch is enabled Reviewed-by: leifs, jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java From hang.vo at oracle.com Thu Oct 10 00:47:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 07:47:49 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131010074855.D4F7F62ECB@hg.openjdk.java.net> Changeset: f918ab42cc65 Author: David Pulkrabek Date: 2013-10-10 09:32 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f918ab42cc65 RT-33443: iOS: IllegalStateException due to re-enabled glass thread checks. Reviewed-by snorthov, Artem Ananiev ! modules/graphics/src/main/java/com/sun/glass/ui/ios/IosApplication.java ! modules/graphics/src/main/native-glass/ios/GlassApplication.m Changeset: 6c48a06e5740 Author: David Pulkrabek Date: 2013-10-10 09:36 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6c48a06e5740 RT-31453: very poor scrolling performance of ListView on iOS. Reviewed by rbair ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java From artem.ananiev at oracle.com Thu Oct 10 01:44:06 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 10 Oct 2013 12:44:06 +0400 Subject: Keyboard events In-Reply-To: References: <52529340.4080205@oracle.com> <5252E966.3020707@oracle.com> <525539D2.5040808@oracle.com> Message-ID: <525668D6.3030404@oracle.com> On 10/10/2013 3:11 AM, Pedro Duque Vieira wrote: > Done. > > https://javafx-jira.kenai.com/browse/RT-33458 Thank you! Artem > Thanks, best regards, > > > On Wed, Oct 9, 2013 at 12:11 PM, Artem Ananiev > wrote: > > > On 10/9/2013 4:19 AM, Pedro Duque Vieira wrote: > > Do you want me to file a Jira issue for this? > > > Yes, please. > > I haven't found such a feature request in JavaFX JIRA. The only > issue which is slightly related is > > https://javafx-jira.kenai.com/__browse/RT-32302 > > > but it's not exactly about querying for keyboard state. > > Thanks, > > Artem > > Regards, > > > On Mon, Oct 7, 2013 at 6:03 PM, Artem Ananiev > > >> wrote: > > > On 10/7/2013 6:53 PM, Richard Bair wrote: > > That being said, this seems like a very common use > case, and I > wonder if there is something more we could do (in the > longer > term, short term do as Artem suggests) > > > One of the options is to provide API to query for keyboard > state at > any arbitrary moment, whether particular key is pressed or > not. Even > if we only support locking keys (Caps, Num, Scroll, Kana) and > control keys (Shift, Control, Command, Alt), it will be of > great > value. Game developers will be happy to have such API for > all the > keys, including navigation and letter ones. > > Thanks, > > Artem > > > On Oct 7, 2013, at 3:56 AM, Artem Ananiev > > >> > > wrote: > > > On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote: > Hi, > > I have the following use case: > When the user presses shift and the mouse is > hover the > chart component the > cursor must change to an open hand cursor > signaling to > the user that the > chart is ready for a panning action. > The problem is that for this to be possible I > want the > chart to be able to > listen to keyboard events even when it doesn't > have focus. > > I think this is not possible and I wonder why. > Swing was > the same, you > could only listen to keyboard events if the > control had > focus. Is this a > technical limitation? If there is no technical > limitation I think it would > be better to remove this restriction, I think it is > limiting and the above > scenario is a good use case to show that. > > > This is not a technical limitation, it's just the > way how > it's supposed to work. All the key events are > dispatched to > the component in focus, this is what input focus is. > > Scenario you described should be easier to > implement in FX > than in Swing. In AWT/Swing, input events are > dispatched to > a single component, while FX is much more flexible. > All the > events are delivered to a Scene first, then > dispatched to > the focused component (or component under mouse, > for mouse > events), then bubbled up back to the Scene. What > you need is > to register a custom event filter for the scene and > listen > to all the key events. > > See Scene.addEventFilter() and > Scene.addEventHandler() for > details. > > Thanks, > > Artem > > Thanks, best regards, > > > > > -- > Pedro Duque Vieira > > > > > -- > Pedro Duque Vieira From hang.vo at oracle.com Thu Oct 10 04:03:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 11:03:07 +0000 Subject: hg: openjfx/8/graphics/rt: [TEST-ONLY] fixed unit tests following fix for RT-25407 Message-ID: <20131010110357.C852B62EE8@hg.openjdk.java.net> Changeset: 27a33ce47044 Author: kcr Date: 2013-10-10 03:53 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/27a33ce47044 [TEST-ONLY] fixed unit tests following fix for RT-25407 Contributed-by: flar ! modules/graphics/src/test/java/javafx/scene/canvas/CanvasTest.java From hang.vo at oracle.com Thu Oct 10 05:32:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 12:32:49 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32574: JavaFXImageBuilder does not remember backgroundLoading Message-ID: <20131010123339.253FB62EF0@hg.openjdk.java.net> Changeset: a129ffbdcb02 Author: Eva Krejcirova Date: 2013-10-10 13:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a129ffbdcb02 RT-32574: JavaFXImageBuilder does not remember backgroundLoading Reviewed-by: lnerad ! modules/fxml/src/main/java/com/sun/javafx/fxml/builder/JavaFXImageBuilder.java From hang.vo at oracle.com Thu Oct 10 06:32:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 13:32:49 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33224: [SwingNode] Win: Cannot scroll in a popup inside the SwingNode Message-ID: <20131010133346.8DCEE62EF3@hg.openjdk.java.net> Changeset: 9e14ef767172 Author: Petr Pchelko Date: 2013-10-10 17:22 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9e14ef767172 RT-33224: [SwingNode] Win: Cannot scroll in a popup inside the SwingNode Reviewed-by: anthony, art ! modules/graphics/src/main/native-glass/win/ViewContainer.cpp From hang.vo at oracle.com Thu Oct 10 06:47:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 13:47:49 +0000 Subject: hg: openjfx/8/graphics/rt: RT-15962: Remove click logic Message-ID: <20131010134812.D1E1162EF5@hg.openjdk.java.net> Changeset: 98f62a443251 Author: art Date: 2013-10-10 17:32 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98f62a443251 RT-15962: Remove click logic Reviewed-by: kcr, psafrata ! modules/graphics/src/main/java/com/sun/glass/ui/View.java ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTView.java ! modules/graphics/src/main/java/com/sun/javafx/embed/EmbeddedSceneInterface.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKSceneListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/swing/src/main/java/javafx/embed/swing/JFXPanel.java ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java From hang.vo at oracle.com Thu Oct 10 07:03:18 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 14:03:18 +0000 Subject: hg: openjfx/8/graphics/rt: [TEST-ONLY] RT-33447: Many region tests fail or timeout on Windows Message-ID: <20131010140334.80A2E62EF6@hg.openjdk.java.net> Changeset: 0fdc28a43d91 Author: kcr Date: 2013-10-10 06:53 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0fdc28a43d91 [TEST-ONLY] RT-33447: Many region tests fail or timeout on Windows Summary: increased timeout from 5 seconds to 20 seconds ! tests/system/src/test/java/javafx/scene/layout/RegionBackgroundFillUITest.java ! tests/system/src/test/java/javafx/scene/layout/RegionBackgroundImageUITest.java ! tests/system/src/test/java/javafx/scene/layout/RegionBorderImageUITest.java From philippe.tiffeau at steria.com Thu Oct 10 07:55:08 2013 From: philippe.tiffeau at steria.com (Philippe TIFFEAU) Date: Thu, 10 Oct 2013 14:55:08 +0000 Subject: JAVAFX on ANDROID Message-ID: Hello, Someone can make a clear answer about JavaFX on ANDROID ? If it works how to use ? Otherwise the roadmap is .... Best Regard. This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. From hang.vo at oracle.com Thu Oct 10 08:47:40 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 15:47:40 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131010155002.3487062F03@hg.openjdk.java.net> Changeset: dcfde4bf3a41 Author: David Grieve Date: 2013-10-10 11:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dcfde4bf3a41 [TEST ONLY] Unit test for RT-33080 ! modules/controls/src/test/java/javafx/scene/control/MiscellaneousTests.java Changeset: d0e3d2c5388a Author: David Grieve Date: 2013-10-10 11:35 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d0e3d2c5388a RT-33080: when reusing a style helper, clear the fontSizeCache if some font has been set by setFont Reviewed by: paru, jonathan, mick ! modules/controls/src/main/java/javafx/scene/control/Control.java ! modules/controls/src/main/java/javafx/scene/control/PopupControl.java ! modules/graphics/src/main/java/javafx/css/Styleable.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/scene/SubScene.java From hang.vo at oracle.com Thu Oct 10 08:32:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 15:32:42 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131010153353.2762F62EFE@hg.openjdk.java.net> Changeset: 114826cf23a7 Author: David Grieve Date: 2013-10-10 11:22 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/114826cf23a7 [TEST ONLY] unit test for RT-32931 ! modules/graphics/src/test/java/javafx/scene/shape/ShapeTest.java Changeset: db8ea7bf0af4 Author: David Grieve Date: 2013-10-10 11:22 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/db8ea7bf0af4 RT-32931: Shape holds reference to Region shapeProperty through runnable that is run when shape changes. Have Shape hold WeakRefernce to this Runnable. Reviewed by: kcr ! modules/graphics/src/main/java/javafx/scene/shape/Shape.java From tobi at ultramixer.com Thu Oct 10 09:10:59 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Thu, 10 Oct 2013 18:10:59 +0200 Subject: JAVAFX on ANDROID In-Reply-To: References: Message-ID: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. Best regards, Tobi Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU : > Hello, > > Someone can make a clear answer about JavaFX on ANDROID ? > > If it works how to use ? Otherwise the roadmap is .... > > Best Regard. > > This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. From hang.vo at oracle.com Thu Oct 10 10:33:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 17:33:01 +0000 Subject: hg: openjfx/8/graphics/rt: RT-27546 MenuButton: PopupSide(Side.TOP, Side.LEFT) works incorrectly. reviewed by Jonathan. Message-ID: <20131010173359.3839F62F13@hg.openjdk.java.net> Changeset: a8596c9a724f Author: psomashe Date: 2013-10-10 10:20 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a8596c9a724f RT-27546 MenuButton: PopupSide(Side.TOP, Side.LEFT) works incorrectly. reviewed by Jonathan. ! modules/controls/src/main/java/javafx/scene/control/ContextMenu.java From hang.vo at oracle.com Thu Oct 10 10:47:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 17:47:46 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33456: Refactor TriangleMesh update peer method Message-ID: <20131010174843.457D462F1D@hg.openjdk.java.net> Changeset: 1f4c3ee0d483 Author: Yao Wang Date: 2013-10-10 10:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1f4c3ee0d483 RT-33456: Refactor TriangleMesh update peer method Reviewed-by: cyang ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java + tests/system/src/test/java/test3d/TriangleMeshValidationTest.java From hang.vo at oracle.com Thu Oct 10 10:46:04 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 17:46:04 +0000 Subject: hg: openjfx/8/master/rt: 83 new changesets Message-ID: <20131010182112.5E96B62F35@hg.openjdk.java.net> Changeset: b3fa96512e75 Author: mv157916 Date: 2013-10-03 16:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b3fa96512e75 RT-33356: Update the JDK 8 build number to b110 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 8207cae52078 Author: snorthov Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8207cae52078 RT-33293: Get rid of unused class/package com.sun.prism.tkal.Window Summary: The IDE's and Artem find no references to this class so we killed it. Reviewed-by: rbair - modules/graphics/src/main/java/com/sun/prism/tkal/Window.java Changeset: 4600cb2846c1 Author: Felipe Heidrich Date: 2013-10-01 14:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4600cb2846c1 RT-32829: loading of embedded font definitions doesn't work in PrismFontLoader ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontLoader.java Changeset: 932cecc14e49 Author: Felipe Heidrich Date: 2013-10-01 13:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/932cecc14e49 RT-32255 [win only] ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/ID2D1RenderTarget.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/IDWriteFactory.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/IDWriteFontFace.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/IDWriteLocalizedStrings.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/OS.java ! modules/graphics/src/main/native-font/directwrite.cpp Changeset: 19431d2dcdd5 Author: rbair Date: 2013-10-01 15:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/19431d2dcdd5 RT-33038: ScheduledService doesn't stop after calling cancel Reviewed by: snorthov ! modules/graphics/src/main/java/javafx/concurrent/ScheduledService.java ! modules/graphics/src/main/java/javafx/concurrent/Service.java ! modules/graphics/src/test/java/javafx/concurrent/ScheduledServiceTest.java ! modules/graphics/src/test/java/javafx/concurrent/ServiceLifecycleTest.java Changeset: 90e48442d0ff Author: Martin Soch Date: 2013-10-02 10:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/90e48442d0ff SW pipeline: improved fillRect with ImagePaint (RT-29811) ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java + modules/graphics/src/main/java/com/sun/prism/sw/SWPaint.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWUtils.java ! modules/graphics/src/main/native-prism-sw/JPiscesRenderer.c ! modules/graphics/src/main/native-prism-sw/PiscesPaint.c ! modules/graphics/src/main/native-prism-sw/PiscesRenderer.h Changeset: 6204306cde59 Author: dmasada Date: 2013-10-02 10:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6204306cde59 RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/BouncingBallsApp.java Changeset: 67b0664167d6 Author: David Grieve Date: 2013-10-02 14:53 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/67b0664167d6 RT-33103: Children may change, iterate over a copy. Reviewed by paru ! modules/graphics/src/main/java/javafx/scene/Parent.java Changeset: 31c7ced6e2e6 Author: psomashe Date: 2013-10-02 12:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/31c7ced6e2e6 RT-27768 : PieChart adding new data lead to incorrect style class updating. reviwed by Jonathan. ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java Changeset: bd2f3d13cbf7 Author: psomashe Date: 2013-10-02 12:18 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bd2f3d13cbf7 RT-33245 Font is not applied to charts axis with caspian theme reviwed by David. ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 04dfdd1ed7be Author: David Grieve Date: 2013-10-02 15:26 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/04dfdd1ed7be [TEST-ONLY] RT-33103 unit test ! modules/controls/src/test/java/javafx/scene/control/MiscellaneousTests.java Changeset: 48e93b84056d Author: rbair Date: 2013-10-02 13:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/48e93b84056d RT-32848: Add CENTER constant to BackgroundPosition Reviewed-by: snorthov ! modules/graphics/src/main/java/javafx/scene/layout/BackgroundPosition.java ! modules/graphics/src/test/java/javafx/scene/layout/BackgroundPositionTest.java Changeset: 043bd9ac4de2 Author: rbair Date: 2013-10-02 13:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/043bd9ac4de2 [DOC-ONLY] Update Bounds class doc to discuss empty bounds. It is also described in isEmpty method documentation and already covered by tests. ! modules/graphics/src/main/java/javafx/geometry/Bounds.java Changeset: e1f9a085f399 Author: rbair Date: 2013-10-02 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e1f9a085f399 RT-33262: Not able to use Task and Service from the init method of Application Reviewed-by: kcr + apps/toys/Hello/src/main/java/hello/HelloTask.java ! modules/graphics/src/main/java/javafx/concurrent/Service.java ! modules/graphics/src/main/java/javafx/concurrent/Task.java ! modules/graphics/src/main/java/javafx/geometry/Bounds.java ! modules/graphics/src/test/java/javafx/concurrent/AbstractTask.java ! modules/graphics/src/test/java/javafx/concurrent/ServiceLifecycleTest.java ! modules/graphics/src/test/java/javafx/concurrent/ServiceTest.java ! modules/graphics/src/test/java/javafx/concurrent/TestServiceFactory.java Changeset: d70c498de565 Author: rbair Date: 2013-10-02 13:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d70c498de565 RT-23446: Negative height or width should be forbidden Reviewed-by: msladecek ! modules/graphics/src/main/java/javafx/scene/Group.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/scene/layout/Region.java ! modules/graphics/src/test/java/javafx/scene/GroupTest.java + modules/graphics/src/test/java/javafx/scene/Node_layoutSizes_Test.java ! modules/graphics/src/test/java/javafx/scene/layout/RegionTest.java ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java ! modules/web/src/main/java/javafx/scene/web/WebView.java Changeset: 1bbb02497363 Author: jgiles Date: 2013-10-01 10:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1bbb02497363 [DOC ONLY] RT-32230: CheckBoxTableCell page doesn't display some CSS styles ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTableCell.java Changeset: 988cdf5dfc94 Author: jgiles Date: 2013-10-02 10:10 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/988cdf5dfc94 RT-33106: Ensemble8: Service NPE on refresh button click ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/test/java/javafx/scene/control/ListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableRowTest.java Changeset: 2f48570d437f Author: jgiles Date: 2013-10-02 12:29 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2f48570d437f RT-33301: ctrl+shift+down is looping in all virtualised controls RT-33307: Ctrl+shift+up/down should map to up/down in virtualised controls when in single selection mode ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/test/java/javafx/scene/control/ListViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java Changeset: dfe5f213aab4 Author: jgiles Date: 2013-10-02 15:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dfe5f213aab4 RT-31206: [TableView] custom skin replacements fails, when columns or data is added. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java Changeset: 5f4b2dc52be7 Author: psomashe Date: 2013-10-02 15:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5f4b2dc52be7 Fix RT-33036 Separator in ColorPicker ColorPalette is broken under Caspian. reviewed by Jonathan. ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 9b496ab6ad57 Author: dmasada Date: 2013-10-02 15:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9b496ab6ad57 RT-29922 Ensemble8: remove builders (partial) ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/animation/transitions/sequentialtransition/SequentialTransitionApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/area/stacked/StackedAreaChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bar/stacked/StackedBarChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/colorpicker/ColorPickerApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/pagination/PaginationApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/splitpane/hiddensplitpane/HiddenSplitPaneApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/tab/tabpane/TabPaneApp.java Changeset: bed4d07b03e8 Author: dmasada Date: 2013-10-02 17:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bed4d07b03e8 RT-29922 Ensemble8: remove builders (partial).Update generated sample info ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java Changeset: 51aa0b68a442 Author: Yao Wang Date: 2013-10-02 18:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/51aa0b68a442 RT-33231: [JAVADOC] PhongMaterial JavaDoc fixes and clarifications Summary: Fix format errors and Add spec that bumpMap property requires a normal map. Reviewed-by: kcr ! modules/graphics/src/main/java/javafx/scene/paint/PhongMaterial.java Changeset: 5677ce5e6af3 Author: Martin Sladecek Date: 2013-10-03 09:09 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5677ce5e6af3 [DOC] RT-32520 FXML reference is outdated ! modules/fxml/src/main/docs/javafx/fxml/doc-files/fxml.css ! modules/fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html Changeset: 98b9cd9ee0fc Author: Martin Sladecek Date: 2013-10-03 13:49 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/98b9cd9ee0fc [JAVADOC/DOC] RT-30851 FXMLLoader has many undocumented fields ! modules/fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java Changeset: b182b0b07282 Author: Martin Sladecek Date: 2013-10-03 14:01 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b182b0b07282 RT-33052 Generify FXMLLoader.load instance methods Reviewed-by: ekrejcir ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java Changeset: abbc53855b43 Author: flar Date: 2013-10-03 06:51 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/abbc53855b43 Fix RT-32472: NPE setting a broken image into a working ImageView with viewport Reviewed by: kcr, ckyang ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGImageView.java Changeset: 8baf1c812ced Author: Oldrich Maticka Date: 2013-10-03 16:00 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8baf1c812ced iOS: replacing StringBuffer occurrences in favour of StringBuilder ! modules/web/src/ios/java/javafx/scene/web/ExportedJavaObject.java ! modules/web/src/ios/java/javafx/scene/web/JS2JavaBridge.java ! modules/web/src/ios/java/javafx/scene/web/JSONEncoder.java Changeset: 5fd60ebdb9d5 Author: Lisa.Selle at oracle.com Date: 2013-10-03 11:19 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5fd60ebdb9d5 Fix for RT-32974 LensTouchInputSupport calls GestureSupport methods from the wrong thread. Move calls to correct thread. Reviewed by Rafi Tayar. Tested with HelloSanity on beagle/pi. ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java Changeset: 98ddce26ad7b Author: prrace Date: 2013-10-03 08:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/98ddce26ad7b RT-32840: javadoc on javafx.print.Paper is not up to date ! modules/graphics/src/main/java/javafx/print/Paper.java Changeset: b606518bf749 Author: kcr Date: 2013-10-03 08:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b606518bf749 RT-32975: Exception in PlatformImpl.checkIdle with glass thread checks enabled Reviewed-by: art, anthony ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java ! modules/graphics/src/main/java/javafx/application/Platform.java ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubToolkit.java ! modules/graphics/src/test/java/javafx/scene/SceneTest.java Changeset: 26fbef1eb521 Author: rbair Date: 2013-10-03 09:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/26fbef1eb521 [REFACTOR-ONLY]: Added some tests for NGRegion, and also did some very coarse refactoring by breaking the render method up into several sub methods. The only actual code change I made was to a copy/paste bug that existed where bottom was using "right" in its computation. All region tests continue passing. Some new region tests are ignored because of existing bugs. I'm pushing this refactor first, so I can then fix those bugs I found. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java + modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGRegionTest.java Changeset: e6ee45d834cb Author: rbair Date: 2013-10-03 09:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e6ee45d834cb [TEST-ONLY] Updated NGRegionTest to make sure that swapping backgrounds on a Region always causes the opaque region to be marked invalid ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/NGRegionTest.java Changeset: abc606e761fb Author: rbair Date: 2013-10-03 09:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/abc606e761fb [IDEA-ONLY] Added IntelliJ IDEA project support for "system" tests + .idea/SystemTests.iml ! .idea/modules.xml Changeset: da16b3edc363 Author: rbair Date: 2013-10-03 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/da16b3edc363 [IDEA-ONLY] Fixed bad path to test/java ! .idea/SystemTests.iml Changeset: f7b87969cd45 Author: David Hill Date: 2013-10-03 13:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f7b87969cd45 RT-32249 fixing Full Screen overly hint Summary: Changing full screen overlay hint when the default exit key has been changed Reviewed-by: kcr, bair ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/OverlayWarning.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java ! modules/graphics/src/main/java/javafx/stage/Stage.java ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_de.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_es.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_fr.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_it.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_ja.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_ko.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_pt_BR.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_sv.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_zh_CN.properties ! modules/graphics/src/main/resources/com/sun/javafx/tk/quantum/QuantumMessagesBundle_zh_TW.properties Changeset: 8b1a40fed5c8 Author: leifs Date: 2013-10-03 10:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8b1a40fed5c8 RT-20391: Mnemonic-parsing with special characters Reviewed-by: mickf ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/Utils.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/ButtonSkinTest.java Changeset: 4f55a53bfabd Author: Felipe Heidrich Date: 2013-10-03 09:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4f55a53bfabd RT-32255 [linux only] ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTGlyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/PangoFactory.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/PangoGlyphLayout.java ! modules/graphics/src/main/native-font/freetype.c Changeset: 50b282551554 Author: jgiles Date: 2013-10-03 11:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/50b282551554 [TEST ONLY] RT-30739: UNIT-TEST: test_rt29930 failures in Controls unit tests. Fixing and re-enabling tests related to RT-29930. ! modules/controls/src/test/java/javafx/scene/control/ListViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 006b0519158b Author: jgiles Date: 2013-10-03 12:50 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/006b0519158b RT-29320: ChoiceBoxTableCell ChoiceBox does not use TableCell's StringConverter ! modules/controls/src/main/java/javafx/scene/control/cell/CellUtils.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxListCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxListCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeTableCell.java ! modules/controls/src/test/java/javafx/scene/control/cell/ChoiceBoxListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ChoiceBoxTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ChoiceBoxTreeCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ChoiceBoxTreeTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ComboBoxListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ComboBoxTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ComboBoxTreeCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ComboBoxTreeTableCellTest.java Changeset: a217f67b7af6 Author: jgiles Date: 2013-10-03 13:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a217f67b7af6 RT-27177: [TreeTableView] ctrl+shift+up/down don't make scrolling. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java Changeset: 40bfec414944 Author: Felipe Heidrich Date: 2013-10-03 13:46 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/40bfec414944 RT-33300: AIOOBE in DWGlyphLayout Reviewed-by: Philip Race ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/JFXTextRenderer.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/OS.java ! modules/graphics/src/main/native-font/directwrite.cpp Changeset: 17d67b5a5a00 Author: Martin Sladecek Date: 2013-10-04 08:42 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/17d67b5a5a00 RT-33097 NPE when calling FXMLLoader.load() in a background thread Reviewed by: ekrejcir ! modules/fxml/src/main/java/com/sun/javafx/fxml/BeanAdapter.java Changeset: b05c5b6ee71c Author: Martin Sladecek Date: 2013-10-04 08:45 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b05c5b6ee71c RT-28121 FXMLLoader with setTemplate(true) doesn't allow Controller specification in fxml Reviewed by: rbair, ekrejcir ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java Changeset: b3c81e6a32d0 Author: Petr Pchelko Date: 2013-10-04 12:41 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b3c81e6a32d0 RT-26891: Re-enable glass thread checks by default once depenedent issues are fixed ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java Changeset: 7a8c5feb8c49 Author: Martin Sladecek Date: 2013-10-04 10:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7a8c5feb8c49 RT-28121 - remove related test files - modules/fxml/src/test/java/javafx/fxml/RT_23413Test.java - modules/fxml/src/test/resources/javafx/fxml/rt_23413.fxml Changeset: 60ad6d456028 Author: Anthony Petrov Date: 2013-10-04 15:53 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/60ad6d456028 RT-31943: Gtk: jni_GetStringUTFChars segfault while running in jruby/jrubyfx Reviewed-by: Alexander Zvegintsev ! modules/graphics/src/main/native-glass/gtk/glass_general.h ! modules/graphics/src/main/native-glass/gtk/glass_screen.cpp Changeset: 080c7905568c Author: mickf Date: 2013-10-04 13:53 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/080c7905568c RT-30898 - Regression : Tab travsersal issue with ScrollPane, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java Changeset: 0917b41c31ac Author: snorthov Date: 2013-10-04 09:29 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0917b41c31ac ECLIPSE: work around Eclipse jdk8 compiler problem ! modules/graphics/src/main/java/javafx/concurrent/Task.java Changeset: 78ee0e010484 Author: David Grieve Date: 2013-10-04 09:44 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/78ee0e010484 RT-33145: In SkinBase computeMinHeight and computeMinWidth, initialize minY/minX to max value and maxY/maxX to min value. Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java ! modules/graphics/src/main/java/javafx/scene/layout/Region.java Changeset: 6a633413eba4 Author: rbair Date: 2013-10-04 09:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6a633413eba4 RT-33357: CSS Parser dies on image-pattern and repeating-image-pattern with -ea flag Reviewed-by: dgrieve ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java Changeset: 53288988ddf1 Author: dmasada Date: 2013-10-04 10:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/53288988ddf1 Ensemble8: Add TreeTableView sample ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/Inventory.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/Part.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/TreeTableViewApp.java + apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/treetableview/preview.png + apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/treetableview/preview at 2x.png Changeset: c71c80693664 Author: prr Date: 2013-10-04 11:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c71c80693664 RT-32841: Paper.Units does not need to be public Reviewed by: kcr, jgodinez ! modules/graphics/src/main/java/com/sun/javafx/print/PrintHelper.java + modules/graphics/src/main/java/com/sun/javafx/print/Units.java ! modules/graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinter.java ! modules/graphics/src/main/java/javafx/print/Paper.java ! modules/graphics/src/main/java/javafx/print/Printer.java + modules/graphics/src/test/java/test/javafx/print/PaperUnitsTest.java Changeset: 137e59786fc1 Author: "Joseph Andresen" Date: 2013-10-04 12:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/137e59786fc1 RT-30750 Jitter on Resize Reviewed by: KevinR, SteveN, Artem, DaveH ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedState.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/SceneState.java Changeset: 66325e8963ef Author: "Joseph Andresen" Date: 2013-10-04 16:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/66325e8963ef RT-28335 ArrayIndexOutOfBounds in canvas polys ReviewedBy: Jim,Kevin ! modules/graphics/src/main/java/javafx/scene/canvas/GraphicsContext.java Changeset: b085eb56ae11 Author: jgiles Date: 2013-10-04 15:51 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b085eb56ae11 RT-33108: CheckBoxTableCell unexpected behavior when TableView is sorted (items indexes change) ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/main/java/javafx/scene/control/TreeCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java ! modules/controls/src/test/java/javafx/scene/control/ListCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableCellTest.java Changeset: 0e6e79ce4263 Author: Alexander Kouznetsov Date: 2013-10-07 10:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0e6e79ce4263 Ensemble8: Fix for RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/Description.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePage.java ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/bouncingballs/BouncingBallsApp.java Changeset: 84878f14f71b Author: Alexander Kouznetsov Date: 2013-10-07 10:37 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/84878f14f71b Ensemble8: Additional fix for RT-32264 Ensemble8: link to javafx.animation.Animation.Status is missing ! apps/samples/Ensemble8/src/compiletime/java/ensemble/compiletime/BuildSamplesList.java ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java Changeset: a554b76b5ee6 Author: Alexander Kouznetsov Date: 2013-10-07 10:49 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a554b76b5ee6 Ensemble8: Samples.java cleanup (Removed ".save" files, fixed "B?zier") ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java Changeset: 93c09655d6a8 Author: Alexander Kouznetsov Date: 2013-10-07 11:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/93c09655d6a8 Ensemble8: Explicitly specify UTF-8 encoding for streams in code generation phase. ! apps/samples/Ensemble8/src/compiletime/java/ensemble/compiletime/BuildSamplesList.java Changeset: b275a99ef7f5 Author: Alexander Kouznetsov Date: 2013-10-07 13:10 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b275a99ef7f5 Ensemble8: Removed builders from PlaygroundTabs.java ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/PlaygroundTabs.java Changeset: 70b8c27e00e0 Author: Alexander Kouznetsov Date: 2013-10-07 13:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/70b8c27e00e0 Ensemble8: Guarded XYDataVisualizer against NPEs. ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/XYDataVisualizer.java Changeset: 77c02e6ffbe6 Author: Alexander Kouznetsov Date: 2013-10-07 13:26 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/77c02e6ffbe6 Ensemble8: Removed builders from XYDataVisualizer.java. ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/XYDataVisualizer.java Changeset: b20673c09b07 Author: Daniel Blaukopf Date: 2013-10-07 13:25 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b20673c09b07 RT-28763 FB: Rename LensApplication.startNativeEventLoop() to nativeEventLoop() Summary: Cosmetic change so that a more appropriate function name shows up in logs Reviewed-by: Assaf Yavnai, Rafi Tayar ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java ! modules/graphics/src/main/native-glass/lens/LensApplication.c Changeset: 093616690092 Author: Alexander Kouznetsov Date: 2013-10-07 15:02 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/093616690092 Ensemble8: Fix for RT-30138 Ensemble8: Stacked Bar Chart: class cast exception ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/XYDataVisualizer.java Changeset: 8f1dc4526871 Author: Alexander Kouznetsov Date: 2013-10-07 15:20 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8f1dc4526871 Ensemble8: Additional fix for RT-31427 Cursor sample in Ensemble8 doesn't look well with latest Lombard bits ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/events/cursor/CursorApp.java Changeset: cee9deb1d5e9 Author: art Date: 2013-10-07 15:40 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cee9deb1d5e9 RT-28495: Implement Platform.isSupported(INPUT_METHOD) Reviewed-by: kcr, snorthov ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java ! modules/graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinApplication.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: 70451c5d10df Author: Martin Soch Date: 2013-10-07 14:44 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/70451c5d10df SW pipeline: PiscesRenderer refactoring (RT-32170) ! modules/graphics/src/main/java/com/sun/pisces/PiscesRenderer.java ! modules/graphics/src/main/native-prism-sw/JPiscesRenderer.c Changeset: 4b5b42fd1c9d Author: mickf Date: 2013-10-07 16:15 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4b5b42fd1c9d RT-33371 - Regression : Tab travsersal issue with Accordion ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: 68546f1ae3cd Author: David Grieve Date: 2013-10-04 12:53 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/68546f1ae3cd RT-33145: In SkinBase, add comments as to why variables are initialized to max and min values, and fix minX and maxX initialization in computePerfWidth. Reviewed by: rbair, jgiles ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java Changeset: 9d2e2252eb11 Author: snorthov Date: 2013-10-07 14:30 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9d2e2252eb11 RT-33258: Event locking when SWT-Shell opened via JavaFX Summary: The InvokeLaterDispatcher was disabled when running embedded with SWT Reviewed-by: ixmal, anthony ! modules/graphics/src/main/java/com/sun/glass/ui/gtk/GtkApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinApplication.java Changeset: 18781eb28d4e Author: kcr Date: 2013-10-07 12:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/18781eb28d4e RT-31064: Ability to get GridPane row count, column count, and cell bounds at runtime Reviewed-by: rbair, msladecek ! modules/graphics/src/main/java/javafx/scene/layout/GridPane.java Changeset: ab3b347eb645 Author: kcr Date: 2013-10-07 12:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ab3b347eb645 RT-31500: Gradle: build in debug mode by default Reviewed-by: Felipe ! build.gradle ! buildSrc/android.gradle ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/ios.gradle ! buildSrc/linux.gradle ! buildSrc/mac.gradle ! buildSrc/src/main/groovy/com/sun/javafx/gradle/LinkTask.groovy ! buildSrc/win.gradle ! buildSrc/x86egl.gradle ! gradle.properties.template Changeset: 78d4d74d1100 Author: rbair Date: 2013-10-07 16:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/78d4d74d1100 RT-33383: background-position: 50% does not center the image Reviewed-by: dgrieve ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java Changeset: 94d55039bc0d Author: rbair Date: 2013-10-07 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/94d55039bc0d [TEST-ONLY]: Moved many manual Region tests over to automated visual tests. Not all tests enabled. Finding bugs along the way in NGRegion. - .idea/RegionTests.iml ! .idea/SystemTests.iml ! .idea/modules.xml ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java - tests/manual/RegionTests/src/main/java/region/RegionBackgroundFillUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBackgroundImageUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBorderImageUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBorderStrokeUITest.java - tests/manual/RegionTests/src/main/java/region/RegionShapeUITest.java - tests/manual/RegionTests/src/main/java/region/RegionUITestBase.java - tests/manual/RegionTests/src/main/resources/region/BlackButton.png - tests/manual/RegionTests/src/main/resources/region/WindowsButton.png - tests/manual/RegionTests/src/main/resources/region/border.png - tests/manual/RegionTests/src/main/resources/region/border at 2x.png - tests/manual/RegionTests/src/main/resources/region/checker.png - tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty.png - tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty at 2x.png - tests/manual/RegionTests/src/main/resources/region/test20x20.png - tests/manual/RegionTests/src/main/resources/region/test20x20 at 2x.png - tests/manual/RegionTests/src/main/resources/region/test48x48.png - tests/manual/RegionTests/src/main/resources/region/test48x48 at 2x.png + tests/system/src/test/java/javafx/scene/layout/RegionBackgroundFillUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionBackgroundImageUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionBorderImageUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionBorderStrokeUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionShapeUITest.java + tests/system/src/test/java/javafx/scene/layout/RegionUITestBase.java ! tests/system/src/test/java/testharness/VisualTestBase.java + tests/system/src/test/resources/javafx/scene/layout/RegionBackgroundImageUITest.html + tests/system/src/test/resources/javafx/scene/layout/border-stretch.png + tests/system/src/test/resources/javafx/scene/layout/border-uneven.png + tests/system/src/test/resources/javafx/scene/layout/border.png + tests/system/src/test/resources/javafx/scene/layout/test20x20.png + tests/system/src/test/resources/javafx/scene/layout/test20x20 at 2x.png + tests/system/src/test/resources/javafx/scene/layout/test48x48.png + tests/system/src/test/resources/javafx/scene/layout/test48x48 at 2x.png Changeset: eff4787e6884 Author: Alexander Zvegintsev Date: 2013-10-08 14:31 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/eff4787e6884 RT-24133 Gtk: URL is recognised both as FILE and as URL, linux only, DnD and Clipboard ! modules/graphics/src/main/native-glass/gtk/GlassSystemClipboard.cpp ! modules/graphics/src/main/native-glass/gtk/glass_dnd.cpp ! modules/graphics/src/main/native-glass/gtk/glass_general.cpp ! modules/graphics/src/main/native-glass/gtk/glass_general.h Changeset: f2d3f04c1632 Author: David Grieve Date: 2013-10-08 08:02 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f2d3f04c1632 RT-33384: avoid using Double.MAX_VALUE and Double.MIN_VALUE ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java Changeset: 1b6d4c9bd1a7 Author: snorthov Date: 2013-10-08 07:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1b6d4c9bd1a7 ECLIPSE ONLY: fix .classpath ! .classpath Changeset: 61727bf6e832 Author: kcr Date: 2013-10-08 09:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/61727bf6e832 [TEST-ONLY] RT-32950: Enable excluded tests in gradle build Reviewed-by: Chien ! build.gradle ! modules/base/src/test/java/javafx/binding/expression/AbstractNumberExpressionTest.java Changeset: 093ea25436c7 Author: kcr Date: 2013-10-08 09:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/093ea25436c7 RT-21415: Need to add javafx-src.zip to JDK 8 distribution Reviewed-by: David Hill, Felipe ! build.gradle ! gradle.properties.template Changeset: ab9489903f7b Author: Yao Wang Date: 2013-10-08 09:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ab9489903f7b RT-26587: 3D Data validation AND RT-30451: FX 8 3D: Need to validate Mesh's data size Summary: Validate input data during FX->NG sync stage. AND Need to validate the size and range of these arrays. Reviewed-by: kcr and cyang ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGTriangleMesh.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseMesh.java ! modules/graphics/src/main/java/javafx/scene/shape/Box.java ! modules/graphics/src/main/java/javafx/scene/shape/Cylinder.java ! modules/graphics/src/main/java/javafx/scene/shape/Sphere.java ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java Changeset: e6331b4daf15 Author: jgodinez Date: 2013-10-08 09:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e6331b4daf15 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - .idea/RegionTests.iml - modules/fxml/src/test/java/javafx/fxml/RT_23413Test.java - modules/fxml/src/test/resources/javafx/fxml/rt_23413.fxml - modules/graphics/src/main/java/com/sun/prism/tkal/Window.java - tests/manual/RegionTests/src/main/java/region/RegionBackgroundFillUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBackgroundImageUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBorderImageUITest.java - tests/manual/RegionTests/src/main/java/region/RegionBorderStrokeUITest.java - tests/manual/RegionTests/src/main/java/region/RegionShapeUITest.java - tests/manual/RegionTests/src/main/java/region/RegionUITestBase.java - tests/manual/RegionTests/src/main/resources/region/BlackButton.png - tests/manual/RegionTests/src/main/resources/region/WindowsButton.png - tests/manual/RegionTests/src/main/resources/region/border.png - tests/manual/RegionTests/src/main/resources/region/border at 2x.png - tests/manual/RegionTests/src/main/resources/region/checker.png - tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty.png - tests/manual/RegionTests/src/main/resources/region/popover-no-arrow-empty at 2x.png - tests/manual/RegionTests/src/main/resources/region/test20x20.png - tests/manual/RegionTests/src/main/resources/region/test20x20 at 2x.png - tests/manual/RegionTests/src/main/resources/region/test48x48.png - tests/manual/RegionTests/src/main/resources/region/test48x48 at 2x.png Changeset: 88d3bef80ffc Author: hudson Date: 2013-10-10 10:25 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/88d3bef80ffc Added tag 8.0-b111 for changeset e6331b4daf15 ! .hgtags From tomas.brandalik at oracle.com Thu Oct 10 13:01:26 2013 From: tomas.brandalik at oracle.com (Tomas Brandalik) Date: Thu, 10 Oct 2013 22:01:26 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> Message-ID: <52570796.8050506@oracle.com> Hi Tobi and Philippe, Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. best regards -Tomas On 10/10/2013 06:10 PM, Tobias Bley wrote: > Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. > > Best regards, > Tobi > > > Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: > >> Hello, >> >> Someone can make a clear answer about JavaFX on ANDROID ? >> >> If it works how to use ? Otherwise the roadmap is .... >> >> Best Regard. >> >> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. From tom.schindl at bestsolution.at Thu Oct 10 13:41:33 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 10 Oct 2013 22:41:33 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <52570796.8050506@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> Message-ID: <525710FD.2060203@bestsolution.at> So when I compile my own FX what target to I compile to? I guess I compile on linux, right? Tom On 10.10.13 22:01, Tomas Brandalik wrote: > Hi Tobi and Philippe, > Android port is being developed in open source so all developers can see > every progress. There is nothing to hide. You can understand it as an > example of porting javafx runtime to a linux based platform not a > product with a roadmap. > As you've noticed there are 2 launchers DalvikLauncher and > JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it > launches an application. What you need to try it out is an java6 (dalvik > vm limitation) compatible javafx fork. > On the other hand JavaSELauncher uses standalone vm which is not part of > the port. It expects that the vm is packaged with an apk. The launcher > unpacks vm, installs it, setup classpath, main class debug port etc (all > specified in manifest) and launches it . These are the 2 options which > can be further extended by the community. > > best regards > -Tomas > > On 10/10/2013 06:10 PM, Tobias Bley wrote: >> Tomas from Oracle is working on the Android port of JavaFX. He has >> developed a DalvikLauncher and a JavaSELauncher. So he is able to tell >> you (and me :)) more about that important theme ?JavaFX on Android?. >> >> Best regards, >> Tobi >> >> >> Am 10.10.2013 um 16:55 schrieb Philippe >> TIFFEAU: >> >>> Hello, >>> >>> Someone can make a clear answer about JavaFX on ANDROID ? >>> >>> If it works how to use ? Otherwise the roadmap is .... >>> >>> Best Regard. >>> >>> This email and any attachments may contain confidential information >>> and intellectual property (including copyright material). It is only >>> for the use of the addressee(s) in accordance with any instructions >>> contained within it. If you are not the addressee, you are prohibited >>> from copying, forwarding, disclosing, saving or otherwise using it in >>> any way. If you receive this email in error, please immediately >>> advise the sender and delete it. Steria may monitor the content of >>> emails within its network to ensure compliance with its policies and >>> procedures. Emails are susceptible to alteration and their integrity >>> (including origin) cannot be assured. Steria shall not be liable for >>> any modification to a message, or for messages falsely sent. > From tobi at ultramixer.com Thu Oct 10 13:42:56 2013 From: tobi at ultramixer.com (Tobi) Date: Thu, 10 Oct 2013 22:42:56 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <52570796.8050506@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> Message-ID: Hi Tomas, How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? > Am 10.10.2013 um 22:01 schrieb Tomas Brandalik : > > Hi Tobi and Philippe, > Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. > As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. > On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. > > best regards > -Tomas > >> On 10/10/2013 06:10 PM, Tobias Bley wrote: >> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >> >> Best regards, >> Tobi >> >> >>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>> >>> Hello, >>> >>> Someone can make a clear answer about JavaFX on ANDROID ? >>> >>> If it works how to use ? Otherwise the roadmap is .... >>> >>> Best Regard. >>> >>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. > From tobi at ultramixer.com Thu Oct 10 13:49:59 2013 From: tobi at ultramixer.com (Tobi) Date: Thu, 10 Oct 2013 22:49:59 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525710FD.2060203@bestsolution.at> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <525710FD.2060203@bestsolution.at> Message-ID: <1CA7F01D-B791-4C49-BD8C-3C391C7F044B@ultramixer.com> No, targets=Android > Am 10.10.2013 um 22:41 schrieb Tom Schindl : > > So when I compile my own FX what target to I compile to? I guess I > compile on linux, right? > > Tom > >> On 10.10.13 22:01, Tomas Brandalik wrote: >> Hi Tobi and Philippe, >> Android port is being developed in open source so all developers can see >> every progress. There is nothing to hide. You can understand it as an >> example of porting javafx runtime to a linux based platform not a >> product with a roadmap. >> As you've noticed there are 2 launchers DalvikLauncher and >> JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it >> launches an application. What you need to try it out is an java6 (dalvik >> vm limitation) compatible javafx fork. >> On the other hand JavaSELauncher uses standalone vm which is not part of >> the port. It expects that the vm is packaged with an apk. The launcher >> unpacks vm, installs it, setup classpath, main class debug port etc (all >> specified in manifest) and launches it . These are the 2 options which >> can be further extended by the community. >> >> best regards >> -Tomas >> >>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>> Tomas from Oracle is working on the Android port of JavaFX. He has >>> developed a DalvikLauncher and a JavaSELauncher. So he is able to tell >>> you (and me :)) more about that important theme ?JavaFX on Android?. >>> >>> Best regards, >>> Tobi >>> >>> >>> Am 10.10.2013 um 16:55 schrieb Philippe >>> TIFFEAU: >>> >>>> Hello, >>>> >>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>> >>>> If it works how to use ? Otherwise the roadmap is .... >>>> >>>> Best Regard. >>>> >>>> This email and any attachments may contain confidential information >>>> and intellectual property (including copyright material). It is only >>>> for the use of the addressee(s) in accordance with any instructions >>>> contained within it. If you are not the addressee, you are prohibited >>>> from copying, forwarding, disclosing, saving or otherwise using it in >>>> any way. If you receive this email in error, please immediately >>>> advise the sender and delete it. Steria may monitor the content of >>>> emails within its network to ensure compliance with its policies and >>>> procedures. Emails are susceptible to alteration and their integrity >>>> (including origin) cannot be assured. Steria shall not be liable for >>>> any modification to a message, or for messages falsely sent. > From hang.vo at oracle.com Thu Oct 10 13:48:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 20:48:44 +0000 Subject: hg: openjfx/8/graphics/rt: RT26137: Node Orienation - Canvas RTL orientation has not been implemented Message-ID: <20131010205018.246FB62F3E@hg.openjdk.java.net> Changeset: 6eb8b652fca5 Author: Felipe Heidrich Date: 2013-10-10 13:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6eb8b652fca5 RT26137: Node Orienation - Canvas RTL orientation has not been implemented Reviewed-By: Jim, Thor ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGCanvas.java ! modules/graphics/src/main/java/javafx/scene/canvas/GraphicsContext.java From tom.schindl at bestsolution.at Thu Oct 10 14:22:07 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 10 Oct 2013 23:22:07 +0200 Subject: JAVAFX on ANDROID In-Reply-To: References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> Message-ID: <52571A7F.5010309@bestsolution.at> FX78 should be compatible with Java6 because RoboVM is built on dalvik classlib and JavaFX works there! Tom On 10.10.13 22:42, Tobi wrote: > Hi Tomas, > > How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? > > And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? > >> Am 10.10.2013 um 22:01 schrieb Tomas Brandalik : >> >> Hi Tobi and Philippe, >> Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. >> As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. >> On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. >> >> best regards >> -Tomas >> >>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >>> >>> Best regards, >>> Tobi >>> >>> >>>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>>> >>>> Hello, >>>> >>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>> >>>> If it works how to use ? Otherwise the roadmap is .... >>>> >>>> Best Regard. >>>> >>>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. >> From hang.vo at oracle.com Thu Oct 10 15:32:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 10 Oct 2013 22:32:35 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30147: Strikethrough on Text is rendered as gray instead of black Message-ID: <20131010223311.813B062F44@hg.openjdk.java.net> Changeset: f9cd25f454e3 Author: Felipe Heidrich Date: 2013-10-10 15:19 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f9cd25f454e3 RT-30147: Strikethrough on Text is rendered as gray instead of black Reviewed: Thor ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGText.java From tomas.brandalik at oracle.com Thu Oct 10 21:52:06 2013 From: tomas.brandalik at oracle.com (Tomas Brandalik) Date: Fri, 11 Oct 2013 06:52:06 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <52571A7F.5010309@bestsolution.at> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> Message-ID: <525783F6.4090309@oracle.com> COMPILE_TARGETS=android Good, then use FX78 and you can give it a try. I have my local fork of javafx for testing DalvikLauncher. Standalone Vm for Android is not available for download. -Tomas > FX78 should be compatible with Java6 because RoboVM is built on dalvik > classlib and JavaFX works there! > > Tom > > On 10.10.13 22:42, Tobi wrote: >> Hi Tomas, >> >> How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? >> >> And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? >> >>> Am 10.10.2013 um 22:01 schrieb Tomas Brandalik: >>> >>> Hi Tobi and Philippe, >>> Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. >>> As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. >>> On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. >>> >>> best regards >>> -Tomas >>> >>>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>>> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >>>> >>>> Best regards, >>>> Tobi >>>> >>>> >>>>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>>>> >>>>> Hello, >>>>> >>>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>>> >>>>> If it works how to use ? Otherwise the roadmap is .... >>>>> >>>>> Best Regard. >>>>> >>>>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. From tobi at ultramixer.com Thu Oct 10 22:51:07 2013 From: tobi at ultramixer.com (Tobi) Date: Fri, 11 Oct 2013 07:51:07 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525783F6.4090309@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> Message-ID: Is this standalone vim working with JIT? Does it works well? We recently tried to use the embedded version of oracle JdKs com Linux/ARMv7 soft float on Android but if doesn't work because if missing linked dylibs on Android..,. > Am 11.10.2013 um 06:52 schrieb Tomas Brandalik : > > COMPILE_TARGETS=android > Good, then use FX78 and you can give it a try. I have my local fork of javafx for testing DalvikLauncher. Standalone Vm for Android is not available for download. > > -Tomas > >> FX78 should be compatible with Java6 because RoboVM is built on dalvik >> classlib and JavaFX works there! >> >> Tom >> >>> On 10.10.13 22:42, Tobi wrote: >>> Hi Tomas, >>> >>> How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? >>> >>> And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? >>> >>>> Am 10.10.2013 um 22:01 schrieb Tomas Brandalik: >>>> >>>> Hi Tobi and Philippe, >>>> Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. >>>> As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. >>>> On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. >>>> >>>> best regards >>>> -Tomas >>>> >>>>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>>>> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >>>>> >>>>> Best regards, >>>>> Tobi >>>>> >>>>> >>>>>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>>>> >>>>>> If it works how to use ? Otherwise the roadmap is .... >>>>>> >>>>>> Best Regard. >>>>>> >>>>>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. > From hang.vo at oracle.com Fri Oct 11 05:17:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 12:17:43 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: fix for regression in image rendering (RT-33459) Message-ID: <20131011121834.9168C62F6B@hg.openjdk.java.net> Changeset: d6facd8f36a1 Author: Martin Soch Date: 2013-10-11 14:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d6facd8f36a1 SW pipeline: fix for regression in image rendering (RT-33459) reviewed by lnerad ! modules/graphics/src/main/native-prism-sw/JPiscesRenderer.c ! modules/graphics/src/main/native-prism-sw/PiscesPaint.c ! modules/graphics/src/main/native-prism-sw/PiscesRenderer.h From hang.vo at oracle.com Fri Oct 11 06:47:51 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 13:47:51 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33440: fixed initial window size when scene is oriented right-to-left. Message-ID: <20131011134828.A6EF762F70@hg.openjdk.java.net> Changeset: ee1ee95de5e4 Author: Pavel Safrata Date: 2013-10-11 14:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ee1ee95de5e4 RT-33440: fixed initial window size when scene is oriented right-to-left. ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/test/java/com/sun/javafx/pgstub/StubStage.java ! modules/graphics/src/test/java/javafx/scene/NodeTest.java From hang.vo at oracle.com Fri Oct 11 07:17:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 14:17:42 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33391: FX component incorrectly reports its bounds when in fxcanvas Message-ID: <20131011141814.CA76662F75@hg.openjdk.java.net> Changeset: d4dc6599f0c8 Author: snorthov Date: 2013-10-11 10:05 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d4dc6599f0c8 RT-33391: FX component incorrectly reports its bounds when in fxcanvas Summary: The fix was to listen for move events using a Display filter Reviewed-by: ant, art ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java From hang.vo at oracle.com Fri Oct 11 08:32:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 15:32:46 +0000 Subject: hg: openjfx/8/graphics/rt: 12 new changesets Message-ID: <20131011153620.3CFD962F81@hg.openjdk.java.net> Changeset: 6aad9af3ed3c Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6aad9af3ed3c [DOCS ONLY] RT-32973 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 8bb6671d6057 Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8bb6671d6057 [DOCS ONLY] RT-32922 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 8c943319624d Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8c943319624d [DOCS ONLY] RT-32849 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 3759aa5b55dd Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3759aa5b55dd [DOCS ONLY] RT-29770 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: a11ed2217411 Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a11ed2217411 [DOCS ONLY] RT-29768 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: b289c84d519f Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b289c84d519f [DOCS ONLY] RT-29767 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 0bf5238f24bc Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0bf5238f24bc [DOCS ONLY] RT-29765 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 606eec1b94cd Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/606eec1b94cd [DOCS ONLY] RT-29757 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 6ed32af3f7a9 Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6ed32af3f7a9 [DOCS ONLY] RT-29753 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 3e28ba6faaa4 Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3e28ba6faaa4 [DOCS ONLY] RT-28031 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: 7ec084a35334 Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7ec084a35334 [DOCS ONLY] RT-27994 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html Changeset: c97dca550a7e Author: David Grieve Date: 2013-10-11 11:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c97dca550a7e [DOCS ONLY] RT-29760 cssref ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html From haenel at ultramixer.com Fri Oct 11 09:10:39 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Fri, 11 Oct 2013 18:10:39 +0200 Subject: JAVAFX on ANDROID In-Reply-To: References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> Message-ID: <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> Hi Tomas, today, I took the time to investigate a little more time on this. 1. I build an entirely new openjfx78 build for android 2. starting this gave me several errors that lead me to the conclusion that I need a java6 openjfx 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper is called with a static call to createStyleHelper. That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore CssStyleHelper crashes. Do you have any idea how to proceed? Do I really have to port JFX8 from Java8 back to Java6 to get a full flegded JFX8 running on Android? That would be pretty heavy it took me nearly 10 hours to port jfx78 to Java6 (without Ensemble). I am willing to contribute, in case we've got a development direction. kind regards Matthias Am 11.10.2013 um 07:51 schrieb Tobi : > Is this standalone vim working with JIT? Does it works well? > > We recently tried to use the embedded version of oracle JdKs com Linux/ARMv7 soft float on Android but if doesn't work because if missing linked dylibs on Android..,. > > >> Am 11.10.2013 um 06:52 schrieb Tomas Brandalik : >> >> COMPILE_TARGETS=android >> Good, then use FX78 and you can give it a try. I have my local fork of javafx for testing DalvikLauncher. Standalone Vm for Android is not available for download. >> >> -Tomas >> >>> FX78 should be compatible with Java6 because RoboVM is built on dalvik >>> classlib and JavaFX works there! >>> >>> Tom >>> >>>> On 10.10.13 22:42, Tobi wrote: >>>> Hi Tomas, >>>> >>>> How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? >>>> >>>> And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? >>>> >>>>> Am 10.10.2013 um 22:01 schrieb Tomas Brandalik: >>>>> >>>>> Hi Tobi and Philippe, >>>>> Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. >>>>> As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. >>>>> On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. >>>>> >>>>> best regards >>>>> -Tomas >>>>> >>>>>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>>>>> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >>>>>> >>>>>> Best regards, >>>>>> Tobi >>>>>> >>>>>> >>>>>>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>>>>> >>>>>>> If it works how to use ? Otherwise the roadmap is .... >>>>>>> >>>>>>> Best Regard. >>>>>>> >>>>>>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. >> From hang.vo at oracle.com Fri Oct 11 08:47:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 15:47:44 +0000 Subject: hg: openjfx/8/graphics/rt: [DOC-ONLY]: added SB-dependency flag (related to RT-21475) Message-ID: <20131011154815.3FE2562F82@hg.openjdk.java.net> Changeset: c5c9f86edb89 Author: Pavel Safrata Date: 2013-10-11 16:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c5c9f86edb89 [DOC-ONLY]: added SB-dependency flag (related to RT-21475) ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java From tom.schindl at bestsolution.at Fri Oct 11 09:22:08 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 11 Oct 2013 18:22:08 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> Message-ID: <525825B0.604@bestsolution.at> On 11.10.13 18:10, Matthias H?nel wrote: > Hi Tomas, > > > today, I took the time to investigate a little more time on this. > > 1. I build an entirely new openjfx78 build for android > 2. starting this gave me several errors that lead me to the > conclusion that I need a java6 openjfx > 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) > 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper > is called with a static call to createStyleHelper. > > That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore On OS-X font stuff is definately there in jfx78, but the low-level font stuff is loaded using reflection (at least this was the cause on robovm)! Tom From rdarrylr at yahoo.com Fri Oct 11 09:34:09 2013 From: rdarrylr at yahoo.com (rdarrylr at yahoo.com) Date: Fri, 11 Oct 2013 16:34:09 +0000 Subject: JAVAFX on ANDROID In-Reply-To: <525783F6.4090309@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> Message-ID: <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> So Oracle has a standalone VM for android that isn't available for download. Is there a plan to ever release this or this is the main piece the community has to create? Is there some kind of legal reason why Oracle can't release this or is it just not wanting to support it? How much time did oracle spend on creating this? How much time do you think it would take community designers to develop this? Does it support swing and javafx or just javafx like the Pi port? What parts of java8 don't work on your standalone VM? -----Original Message----- From: Tomas Brandalik Sender: openjfx-dev-bounces at openjdk.java.net Date: Fri, 11 Oct 2013 06:52:06 To: Subject: Re: JAVAFX on ANDROID COMPILE_TARGETS=android Good, then use FX78 and you can give it a try. I have my local fork of javafx for testing DalvikLauncher. Standalone Vm for Android is not available for download. -Tomas > FX78 should be compatible with Java6 because RoboVM is built on dalvik > classlib and JavaFX works there! > > Tom > > On 10.10.13 22:42, Tobi wrote: >> Hi Tomas, >> >> How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? >> >> And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? >> >>> Am 10.10.2013 um 22:01 schrieb Tomas Brandalik: >>> >>> Hi Tobi and Philippe, >>> Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. >>> As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. >>> On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. >>> >>> best regards >>> -Tomas >>> >>>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>>> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >>>> >>>> Best regards, >>>> Tobi >>>> >>>> >>>>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>>>> >>>>> Hello, >>>>> >>>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>>> >>>>> If it works how to use ? Otherwise the roadmap is .... >>>>> >>>>> Best Regard. >>>>> >>>>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. From richard.bair at oracle.com Fri Oct 11 09:53:32 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 11 Oct 2013 09:53:32 -0700 Subject: JAVAFX on ANDROID In-Reply-To: <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> Message-ID: <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> As frustrating as it is, the fact is that today Oracle has no announced plans to release any official JVM for Android and iOS. That being the case, the biggest hurdle to getting FX on iOS and Android is the VM. On the iOS side there has been some success with RoboVM. On Android you can just use Dalvik if you back port to Java 6, or you have to find another VM (XMLVM maybe?? Anybody convince Excelsior to support Android?) that can do the job. There are two parts the problem of a "VM". One is the VM technology itself, which is probably the lesser of the two issues because there are a handful of decent VMs around (if you include Dalvik, you've already got one on Android). The second problem are the class libraries. Generally JavaFX doesn't rely on too much from JavaSE beyond what is in the "base" module; threading and collections and concurrency and so forth. However we are using the diamond operator and in a few places we might use multi-catch (although I don't know of such places myself) and definitely we use default methods in interfaces in one location (ObservableList). Generally we've tried to make it easy to back port to 7, but haven't tried to keep 6 up to date. I would be very interested in the list of code changes Matthias had to make to better understand the situation. As far as fonts (from Matthias' email) I believe the Android port currently uses T2K but Felipe and Tomas were talking about using the new Font support which would delegate directly to Android APIs. This might be one area that Matthias' and Felipe and Tomas can work closely on to get a contribution to make this happen! > How much time do you think it would take community designers to develop this? RoboVM for iOS I think is basically at this stage, where they've got something up and running to the point of being able to do performance analysis and looking for bugs. It has been a several month process with stops and starts. Tom and the others working on RoboVM might be able to give a better estimate. > Does it support swing and javafx or just javafx like the Pi port? What parts of java8 don't work on your standalone VM? I couldn't tell you what does / doesn't work on the standalone VM as that would break all kinds of confidential legal mumbo-jumbo. But I can tell you I've never seen a port of AWT to iOS or Android. Richard > -----Original Message----- > From: Tomas Brandalik > Sender: openjfx-dev-bounces at openjdk.java.net > Date: Fri, 11 Oct 2013 06:52:06 > To: > Subject: Re: JAVAFX on ANDROID > > COMPILE_TARGETS=android > Good, then use FX78 and you can give it a try. I have my local fork of > javafx for testing DalvikLauncher. Standalone Vm for Android is not > available for download. > > -Tomas > >> FX78 should be compatible with Java6 because RoboVM is built on dalvik >> classlib and JavaFX works there! >> >> Tom >> >> On 10.10.13 22:42, Tobi wrote: >>> Hi Tomas, >>> >>> How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? >>> >>> And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? >>> >>>> Am 10.10.2013 um 22:01 schrieb Tomas Brandalik: >>>> >>>> Hi Tobi and Philippe, >>>> Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. >>>> As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. >>>> On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. >>>> >>>> best regards >>>> -Tomas >>>> >>>>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>>>> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >>>>> >>>>> Best regards, >>>>> Tobi >>>>> >>>>> >>>>>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>>>> >>>>>> If it works how to use ? Otherwise the roadmap is .... >>>>>> >>>>>> Best Regard. >>>>>> >>>>>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. > From hang.vo at oracle.com Fri Oct 11 11:32:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 18:32:58 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed RT-33142: TextArea not printed Message-ID: <20131011183429.255C362F95@hg.openjdk.java.net> Changeset: a270c556990f Author: prr Date: 2013-10-11 11:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a270c556990f Fixed RT-33142: TextArea not printed Reviewed-by: kcr, jgodinez ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java From hang.vo at oracle.com Fri Oct 11 11:47:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 18:47:46 +0000 Subject: hg: openjfx/8/graphics/rt: [NETBEANS-ONLY] Add resource directory to netbeans IDE Message-ID: <20131011184806.DE20662F99@hg.openjdk.java.net> Changeset: 853b9b601911 Author: kcr Date: 2013-10-11 11:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/853b9b601911 [NETBEANS-ONLY] Add resource directory to netbeans IDE ! netbeans/systemTests/nbproject/build-impl.xml ! netbeans/systemTests/nbproject/genfiles.properties ! netbeans/systemTests/nbproject/project.properties ! netbeans/systemTests/nbproject/project.xml From hang.vo at oracle.com Fri Oct 11 15:17:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 22:17:52 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131011221930.161E962FAA@hg.openjdk.java.net> Changeset: c0bb338b4285 Author: Chien Yang Date: 2013-10-11 13:46 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c0bb338b4285 Fix to RT-29991: Linux: Crash when scrolling a ScrollPane Reviewed-by: flar, kcr ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PresentingPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseResourcePool.java ! modules/graphics/src/main/java/com/sun/prism/impl/ManagedResource.java ! modules/graphics/src/main/java/com/sun/prism/impl/ResourcePool.java Changeset: 356273aa4596 Author: psomashe Date: 2013-10-11 14:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/356273aa4596 RT-24813 BarChart does not show all data. reviewed by Jonathan. ! modules/controls/src/main/java/javafx/scene/chart/BarChart.java From snfuchs at gmx.de Fri Oct 11 15:47:14 2013 From: snfuchs at gmx.de (Stefan Fuchs) Date: Sat, 12 Oct 2013 00:47:14 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> Message-ID: <52587FF2.8070601@gmx.de> Hi Matthias, I think you must |add the flag ||-PCOMPILE_PANGO=true to build the new opensource font stuff. If I remember correctly I got a similar error, when I first build jfx78 on linux. I made some experiments with javafx on android by myself. I found the following interesting read: http://stackoverflow.com/questions/7153989/java-7-language-features-with-android One other problem I hit, when trying to compile a larger application was: http://stackoverflow.com/questions/15508477/android-my-application-is-too-large-and-gives-unable-to-execute-dex-method-id Apparently there is a limit of ||65536 methods per apk file. Besides, I'm currently two releases behind with the jfx78. I'll try to catch up soon. | Best regards, Stefan > Hi Tomas, > > > today, I took the time to investigate a little more time on this. > > 1. I build an entirely new openjfx78 build for android > 2. starting this gave me several errors that lead me to the > conclusion that I need a java6 openjfx > 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) > 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper > is called with a static call to createStyleHelper. > > That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore > CssStyleHelper crashes. Do you have any idea how to proceed? Do I really have to port JFX8 from Java8 > back to Java6 to get a full flegded JFX8 running on Android? That would be pretty heavy it took me > nearly 10 hours to port jfx78 to Java6 (without Ensemble). I am willing to contribute, in case we've got > a development direction. > > > kind regards > Matthias > > > > Am 11.10.2013 um 07:51 schrieb Tobi : > >> Is this standalone vim working with JIT? Does it works well? >> >> We recently tried to use the embedded version of oracle JdKs com Linux/ARMv7 soft float on Android but if doesn't work because if missing linked dylibs on Android..,. >> >> >>> Am 11.10.2013 um 06:52 schrieb Tomas Brandalik : >>> >>> COMPILE_TARGETS=android >>> Good, then use FX78 and you can give it a try. I have my local fork of javafx for testing DalvikLauncher. Standalone Vm for Android is not available for download. >>> >>> -Tomas >>> >>>> FX78 should be compatible with Java6 because RoboVM is built on dalvik >>>> classlib and JavaFX works there! >>>> >>>> Tom >>>> >>>>> On 10.10.13 22:42, Tobi wrote: >>>>> Hi Tomas, >>>>> >>>>> How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? >>>>> >>>>> And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? >>>>> >>>>>> Am 10.10.2013 um 22:01 schrieb Tomas Brandalik: >>>>>> >>>>>> Hi Tobi and Philippe, >>>>>> Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. >>>>>> As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. >>>>>> On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. >>>>>> >>>>>> best regards >>>>>> -Tomas >>>>>> >>>>>>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>>>>>> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >>>>>>> >>>>>>> Best regards, >>>>>>> Tobi >>>>>>> >>>>>>> >>>>>>>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>>>>>> >>>>>>>> If it works how to use ? Otherwise the roadmap is .... >>>>>>>> >>>>>>>> Best Regard. >>>>>>>> >>>>>>>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. > From hang.vo at oracle.com Fri Oct 11 15:47:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 22:47:56 +0000 Subject: hg: openjfx/8/graphics/rt: set triangleMesh.getFaceSmoothingGroups to have a max size of facesInd Message-ID: <20131011224849.9A58262FAD@hg.openjdk.java.net> Changeset: 480236e38a68 Author: John Yoon Date: 2013-10-11 15:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/480236e38a68 set triangleMesh.getFaceSmoothingGroups to have a max size of facesInd ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMeshView.java From hang.vo at oracle.com Fri Oct 11 16:03:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 11 Oct 2013 23:03:22 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131011230358.2156962FAE@hg.openjdk.java.net> Changeset: 0aad999d0017 Author: leifs Date: 2013-10-11 15:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0aad999d0017 RT-33340: Unable to select last word Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java Changeset: dee7bd7a7233 Author: John Yoon Date: 2013-10-11 15:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dee7bd7a7233 3DViewer : allocated smoothingGroupsArray size to be numOfFacesAfter ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/shape3d/PolygonMeshView.java From felipe.heidrich at oracle.com Fri Oct 11 16:36:12 2013 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Fri, 11 Oct 2013 16:36:12 -0700 Subject: JAVAFX on ANDROID In-Reply-To: <52587FF2.8070601@gmx.de> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <52587FF2.8070601@gmx.de> Message-ID: <08E1B06B-2BDC-4B64-B024-5A1BFBC406B0@oracle.com> Hi, The 'native' font stack for Linux uses Pango (to handle complex text) and freetype (rendering glyph images, outlines, metrics, etc). As long as we manage to build our freetype code on Android we should be able to have something that works. As for pango, I heard it is not available on Android, but JavaFX should be able to work without it (except that Arabic, Hebrew, Thai, Indic and other complex scripts won't work). For the long run I would like to implement our glyph-layout code based on Harfbuzz, which is would replace pango entirely and is available on Android. Cheers Felipe On Oct 11, 2013, at 3:47 PM, Stefan Fuchs wrote: > Hi Matthias, > > I think you must |add the flag ||-PCOMPILE_PANGO=true to build the new opensource font stuff. > > If I remember correctly I got a similar error, when I first build jfx78 on linux. > > I made some experiments with javafx on android by myself. > > I found the following interesting read: > http://stackoverflow.com/questions/7153989/java-7-language-features-with-android > > One other problem I hit, when trying to compile a larger application was: > http://stackoverflow.com/questions/15508477/android-my-application-is-too-large-and-gives-unable-to-execute-dex-method-id > > Apparently there is a limit of ||65536 methods per apk file. > > > Besides, I'm currently two releases behind with the jfx78. > > I'll try to catch up soon. > | > Best regards, > > Stefan > >> Hi Tomas, >> >> >> today, I took the time to investigate a little more time on this. >> >> 1. I build an entirely new openjfx78 build for android >> 2. starting this gave me several errors that lead me to the >> conclusion that I need a java6 openjfx >> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >> is called with a static call to createStyleHelper. >> >> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore >> CssStyleHelper crashes. Do you have any idea how to proceed? Do I really have to port JFX8 from Java8 >> back to Java6 to get a full flegded JFX8 running on Android? That would be pretty heavy it took me >> nearly 10 hours to port jfx78 to Java6 (without Ensemble). I am willing to contribute, in case we've got >> a development direction. >> >> >> kind regards >> Matthias >> >> >> >> Am 11.10.2013 um 07:51 schrieb Tobi : >> >>> Is this standalone vim working with JIT? Does it works well? >>> >>> We recently tried to use the embedded version of oracle JdKs com Linux/ARMv7 soft float on Android but if doesn't work because if missing linked dylibs on Android..,. >>> >>> >>>> Am 11.10.2013 um 06:52 schrieb Tomas Brandalik : >>>> >>>> COMPILE_TARGETS=android >>>> Good, then use FX78 and you can give it a try. I have my local fork of javafx for testing DalvikLauncher. Standalone Vm for Android is not available for download. >>>> >>>> -Tomas >>>> >>>>> FX78 should be compatible with Java6 because RoboVM is built on dalvik >>>>> classlib and JavaFX works there! >>>>> >>>>> Tom >>>>> >>>>>> On 10.10.13 22:42, Tobi wrote: >>>>>> Hi Tomas, >>>>>> >>>>>> How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? >>>>>> >>>>>> And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? >>>>>> >>>>>>> Am 10.10.2013 um 22:01 schrieb Tomas Brandalik: >>>>>>> >>>>>>> Hi Tobi and Philippe, >>>>>>> Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. >>>>>>> As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. >>>>>>> On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. >>>>>>> >>>>>>> best regards >>>>>>> -Tomas >>>>>>> >>>>>>>> On 10/10/2013 06:10 PM, Tobias Bley wrote: >>>>>>>> Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme ?JavaFX on Android?. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Tobi >>>>>>>> >>>>>>>> >>>>>>>>> Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAU: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Someone can make a clear answer about JavaFX on ANDROID ? >>>>>>>>> >>>>>>>>> If it works how to use ? Otherwise the roadmap is .... >>>>>>>>> >>>>>>>>> Best Regard. >>>>>>>>> >>>>>>>>> This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent. >> > From tomas.brandalik at oracle.com Sat Oct 12 05:04:58 2013 From: tomas.brandalik at oracle.com (Tomas Brandalik) Date: Sat, 12 Oct 2013 14:04:58 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525825B0.604@bestsolution.at> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> Message-ID: <52593AEA.8070800@oracle.com> I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. -Tomas On 10/11/2013 06:22 PM, Tom Schindl wrote: > On 11.10.13 18:10, Matthias H?nel wrote: >> Hi Tomas, >> >> >> today, I took the time to investigate a little more time on this. >> >> 1. I build an entirely new openjfx78 build for android >> 2. starting this gave me several errors that lead me to the >> conclusion that I need a java6 openjfx >> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >> is called with a static call to createStyleHelper. >> >> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore > On OS-X font stuff is definately there in jfx78, but the low-level font > stuff is loaded using reflection (at least this was the cause on robovm)! > > Tom From hang.vo at oracle.com Sat Oct 12 14:18:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 12 Oct 2013 21:18:59 +0000 Subject: hg: openjfx/8/graphics/rt: [BUILD] updating arm SDK toolchain Message-ID: <20131012212023.2E81B62FDD@hg.openjdk.java.net> Changeset: 31b9c81a434d Author: ddhill Date: 2013-10-12 16:34 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/31b9c81a434d [BUILD] updating arm SDK toolchain review: lisa.selle ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle From niklas at therning.org Sun Oct 13 02:49:45 2013 From: niklas at therning.org (Niklas Therning) Date: Sun, 13 Oct 2013 11:49:45 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <52593AEA.8070800@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> Message-ID: For PlatformLogger et al you can probably use the compatibility lib we have been using for jfx78+RoboVM: https://github.com/robovm/robovm-jfx78-compat Den l?rdagen den 12:e oktober 2013 skrev Tomas Brandalik: > I think that PlatformLogger initialization in CssHelper was causing > problems. I had to write one. Not 100% sure though I will look at it when > I'm back in the office. (Or you can comment out css processing in the > node.) I was able to run without font then. > > -Tomas > > > On 10/11/2013 06:22 PM, Tom Schindl wrote: > >> On 11.10.13 18:10, Matthias H?nel wrote: >> >>> Hi Tomas, >>> >>> >>> today, I took the time to investigate a little more time on this. >>> >>> 1. I build an entirely new openjfx78 build for android >>> 2. starting this gave me several errors that lead me to the >>> conclusion that I need a java6 openjfx >>> 3. based on openjfx78 I ported it back to java6 (adapted gradled >>> scripts, and tons of java source code) >>> 4. Now it's almost running on an 18th android. All libraries are firing >>> up until the CssStyleHelper >>> is called with a static call to createStyleHelper. >>> >>> That looks like the font stuff is not in jfx78. That's why "new Font" >>> returns with null and therefore >>> >> On OS-X font stuff is definately there in jfx78, but the low-level font >> stuff is loaded using reflection (at least this was the cause on robovm)! >> >> Tom >> > > From rafaljfx at gmail.com Sun Oct 13 16:06:09 2013 From: rafaljfx at gmail.com (Rafal) Date: Mon, 14 Oct 2013 01:06:09 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> Message-ID: <525B2761.5040602@gmail.com> On 11.10.2013 18:53, Richard Bair wrote: >> How much time do you think it would take community designers to >> develop this? > RoboVM for iOS I think is basically at this stage, where they've got > something up and running to the point of being able to do performance > analysis and looking for bugs. It has been a several month process > with stops and starts. Tom and the others working on RoboVM might be > able to give a better estimate. I don't understand one thing. If you honestly encourage community to make a such big effort as developing, adjusting and maintaining JVMs on the two leading mobile platforms, you don't have any illusions that Oracle VM on android will be released in the next 2 years. :/ Otherwise, if such community's VM will come in blood, sweat and tears and be usable and Oracle announce own VM, then all this community's effort be for nothing and pointless. Sorry for my English. -- Best Regards Rafal From felix.bembrick at gmail.com Sun Oct 13 16:14:03 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 14 Oct 2013 10:14:03 +1100 Subject: JAVAFX on ANDROID In-Reply-To: <525B2761.5040602@gmail.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <525B2761.5040602@gmail.com> Message-ID: Perhaps having more than one JVM on iOS/Android implementation is good for JavaFX as a whole? On 14 October 2013 10:06, Rafal wrote: > On 11.10.2013 18:53, Richard Bair wrote: > >> How much time do you think it would take community designers to develop >>> this? >>> >> RoboVM for iOS I think is basically at this stage, where they've got >> something up and running to the point of being able to do performance >> analysis and looking for bugs. It has been a several month process with >> stops and starts. Tom and the others working on RoboVM might be able to >> give a better estimate. >> > > I don't understand one thing. > If you honestly encourage community to make a such big effort as > developing, adjusting and maintaining JVMs on the two leading mobile > platforms, you don't have any illusions that Oracle VM on android will be > released in the next 2 years. :/ > Otherwise, if such community's VM will come in blood, sweat and tears and > be usable and Oracle announce own VM, then all this community's effort be > for nothing and pointless. > > > Sorry for my English. > > > -- > Best Regards > Rafal > From tbee at tbee.org Sun Oct 13 22:09:33 2013 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 14 Oct 2013 07:09:33 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525B2761.5040602@gmail.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <525B2761.5040602@gmail.com> Message-ID: <525B7C8D.9070506@tbee.org> On 2013-10-14 01:06, Rafal wrote: > If you honestly encourage community to make a such big effort as developing, adjusting and maintaining JVMs on the two leading mobile platforms, you don't have any plans that Oracle VM on android will be released in the next 2 years. :/ > Otherwise, if Oracle announce own VM, then all this community's effort be for nothing and pointless. Open source done in the spare time by people with a full time job usually never grows much bigger than a nice but not too complex library; layout engines, testing frameworks, a web framework, that kind of stuff. Because as a project grows in size and complexity, so do the (number of) issues and the time required to provide support. That usually is the point where either a company is started (projects like Maven and Gradle) or the project gets corporate "funding" usually by that a corporation allows some developers to spent worktime on it (Apache, Eclipse, and Java & JavaFX is getting there). A full fledged port of a JVM to a mobile platform cannot be carried in spare time, it can be showcased (which it has), but to make it production worthy one or more corporations needs to put their weight behind it. My 2 cents, Tom From tobi at ultramixer.com Sun Oct 13 23:27:55 2013 From: tobi at ultramixer.com (Tobi) Date: Mon, 14 Oct 2013 08:27:55 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525B7C8D.9070506@tbee.org> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <525B2761.5040602@gmail.com> <525B7C8D.9070506@tbee.org> Message-ID: I absolutely agree. The point is: nobody can expect from oracle to build such a vm. But if they won't do it, JavaFX will die. Even in the embedded space where companies will use QT or HTML5 instead. Without license fees.... So to sell JavaFX for embedded devices oracle MUST support mobile platforms via VM too. Von meinem iPhone gesendet > Am 14.10.2013 um 07:09 schrieb Tom Eugelink : > > >> On 2013-10-14 01:06, Rafal wrote: >> If you honestly encourage community to make a such big effort as developing, adjusting and maintaining JVMs on the two leading mobile platforms, you don't have any plans that Oracle VM on android will be released in the next 2 years. :/ >> Otherwise, if Oracle announce own VM, then all this community's effort be for nothing and pointless. > > Open source done in the spare time by people with a full time job usually never grows much bigger than a nice but not too complex library; layout engines, testing frameworks, a web framework, that kind of stuff. Because as a project grows in size and complexity, so do the (number of) issues and the time required to provide support. That usually is the point where either a company is started (projects like Maven and Gradle) or the project gets corporate "funding" usually by that a corporation allows some developers to spent worktime on it (Apache, Eclipse, and Java & JavaFX is getting there). > > A full fledged port of a JVM to a mobile platform cannot be carried in spare time, it can be showcased (which it has), but to make it production worthy one or more corporations needs to put their weight behind it. > > My 2 cents, > > Tom > From haenel at ultramixer.com Sun Oct 13 23:30:44 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 08:30:44 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525825B0.604@bestsolution.at> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> Message-ID: Hey Tom, thanks for you answer. while the OSX font stuff is there and Orcale's goal is to use the native font renderer on each platform. I am sure there must be some kind of an Android font renderer in the code. I couldn't find one until now. Another question: Since I ported you latest jfx78 to Java6 it's now jfx678 ;) What would be the best way to contribute the port? Do you think it's good to contribute it to jfx78 or to have a separate jfx68 branch? regards Matthias Am 11.10.2013 um 18:22 schrieb Tom Schindl : > On 11.10.13 18:10, Matthias H?nel wrote: >> Hi Tomas, >> >> >> today, I took the time to investigate a little more time on this. >> >> 1. I build an entirely new openjfx78 build for android >> 2. starting this gave me several errors that lead me to the >> conclusion that I need a java6 openjfx >> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >> is called with a static call to createStyleHelper. >> >> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore > > On OS-X font stuff is definately there in jfx78, but the low-level font > stuff is loaded using reflection (at least this was the cause on robovm)! > > Tom From haenel at ultramixer.com Sun Oct 13 23:49:39 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 08:49:39 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> Message-ID: <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> Hi Richard, thanks for your fast answer. Am 11.10.2013 um 18:53 schrieb Richard Bair : > As frustrating as it is, the fact is that today Oracle has no announced plans to release any official JVM for Android and iOS. That being the case, the biggest hurdle to getting FX on iOS and Android is the VM. On the iOS side there has been some success with RoboVM. On Android you can just use Dalvik if you back port to Java 6, or you have to find another VM (XMLVM maybe?? Anybody convince Excelsior to support Android?) that can do the job. The main point of irritation comes from an quite unclear position about providing the JVM and JFX of the Java-platform. That's why I will sumarize what I heard between the lines: 1. there is NO official jvm planned for iOS and Android in the near future. 2. jfx8 is beeing officially maintained until some point for iOS and Android but the actual port is left to the open source community. 3. Linux ARM support is beeing focused officially on the Freescale ARM-platform. our conclusion is: 1. that's not that bad anymore since we have RoboVM for iOS and Davlik on Android. 2. this statement should have been made 1 year ago. Probably, I missed it but it was not clear to my team as well until last week. That's why we took the challenge to do it our selves. 3. This is good for the open source development since we probably can rely on the CPU optimized parts for ARM. > There are two parts the problem of a "VM". One is the VM technology itself, which is probably the lesser of the two issues because there are a handful of decent VMs around (if you include Dalvik, you've already got one on Android). The second problem are the class libraries. Generally JavaFX doesn't rely on too much from JavaSE beyond what is in the "base" module; threading and collections and concurrency and so forth. However we are using the diamond operator and in a few places we might use multi-catch (although I don't know of such places myself) and definitely we use default methods in interfaces in one location (ObservableList). Generally we've tried to make it easy to back port to 7, but haven't tried to keep 6 up to date. I would be very interested in the list of code changes Matthias had to make to better understand the situation. Yes, mainly it was the multi-catch stuff and the diamonds and some default methods. It's still enough to maintain ;) > As far as fonts (from Matthias' email) I believe the Android port currently uses T2K but Felipe and Tomas were talking about using the new Font support which would delegate directly to Android APIs. This might be one area that Matthias' and Felipe and Tomas can work closely on to get a contribution to make this happen! I have seen T2K in the ARM-Linux port but it's not in the sources since it's one of the libraries that are still in the closed parts of OpenJFX. Is there a fallback? Pango doesn't work either it's not used in the android gradle scripts. I would be happy to integrate it and I am sure I can compile pango for android. I just need a pointer to how I can integrate it into the build process. I changed android.gradle but I am not sure where to put the pango sources. >> How much time do you think it would take community designers to develop this? > > RoboVM for iOS I think is basically at this stage, where they've got something up and running to the point of being able to do performance analysis and looking for bugs. It has been a several month process with stops and starts. Tom and the others working on RoboVM might be able to give a better estimate. > >> Does it support swing and javafx or just javafx like the Pi port? What parts of java8 don't work on your standalone VM? > > I couldn't tell you what does / doesn't work on the standalone VM as that would break all kinds of confidential legal mumbo-jumbo. But I can tell you I've never seen a port of AWT to iOS or Android. kind regards Matthias From haenel at ultramixer.com Sun Oct 13 23:53:05 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 08:53:05 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <52587FF2.8070601@gmx.de> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <52587FF2.8070601@gmx.de> Message-ID: <6806C6E4-3F67-4023-8195-FCC28F9D3D11@ultramixer.com> Hi Stefan, thanks for your fast answer. Am 12.10.2013 um 00:47 schrieb Stefan Fuchs : > I think you must |add the flag ||-PCOMPILE_PANGO=true to build the new opensource font stuff. I am sure that's not that easy ;) Actually, I tried it but it didn't do anything in the first place. > If I remember correctly I got a similar error, when I first build jfx78 on linux. > > I made some experiments with javafx on android by myself. > > I found the following interesting read: > http://stackoverflow.com/questions/7153989/java-7-language-features-with-android Well, I didn't use jfx78 vanilla, I used it as a base for the port to java6. I am quite sure that we need a java6 port on the long run to support davlik stable. > One other problem I hit, when trying to compile a larger application was: > http://stackoverflow.com/questions/15508477/android-my-application-is-too-large-and-gives-unable-to-execute-dex-method-id Ok, interessting, I'll take a look at it when I hit the error. > Apparently there is a limit of ||65536 methods per apk file. > > > Besides, I'm currently two releases behind with the jfx78. > > I'll try to catch up soon. It would be great to read your findings. kind regards Matthias From haenel at ultramixer.com Sun Oct 13 23:57:30 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 08:57:30 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <08E1B06B-2BDC-4B64-B024-5A1BFBC406B0@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <52587FF2.8070601@gmx.de> <08E1B06B-2BDC-4B64-B024-5A1BFBC406B0@oracle.com> Message-ID: <9625ABA6-4332-4822-AAE1-54814EF8834E@ultramixer.com> Hi Felie, thanks for you fast answer. Am 12.10.2013 um 01:36 schrieb Felipe Heidrich : > The 'native' font stack for Linux uses Pango (to handle complex text) and freetype (rendering glyph images, outlines, metrics, etc). > > As long as we manage to build our freetype code on Android we should be able to have something that works. > > As for pango, I heard it is not available on Android, but JavaFX should be able to work without it (except that Arabic, Hebrew, Thai, Indic and other complex scripts won't work). > For the long run I would like to implement our glyph-layout code based on Harfbuzz, which is would replace pango entirely and is available on Android. As far as I can see freetype and pango are conntected to each other in the linux implementation. It's not yet possible to compile just freetype without pango and the other way around. Just an idea. Shouldn't it be possible to have javafx running by default when the font renderer is not working? Most applications don't need a very fancy font renderer, many could rely on any software fallback. Don't you think so? kind regards Matthias From haenel at ultramixer.com Mon Oct 14 00:01:21 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 09:01:21 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <52593AEA.8070800@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> Message-ID: <6A83DE69-B63B-4F99-BBF0-409329E51E00@ultramixer.com> Hi Tomas, thanks for your fast answer. Am 12.10.2013 um 14:04 schrieb Tomas Brandalik : > I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. I took the compat library fro robovm. I believe this should be sufficient. But the CssStyleHelper was still causing problems. > Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. Commenting out Css processing in the node is a good I idea which I tried yesterday but the I ran into other errors that will be caused by the same reason front is missing. I would be great, I you could give me a direction for further investigation. regards Matthias From haenel at ultramixer.com Mon Oct 14 00:03:10 2013 From: haenel at ultramixer.com (=?iso-8859-1?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 09:03:10 +0200 Subject: JAVAFX on ANDROID In-Reply-To: References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> Message-ID: Hey Niklas, Am 13.10.2013 um 11:49 schrieb Niklas Therning : > For PlatformLogger et al you can probably use the compatibility lib we have > been using for jfx78+RoboVM: https://github.com/robovm/robovm-jfx78-compat Hehe, yes I read it in Tobi's blog post that you wrote one that's why this is what I did in the first place ;) regards Matthias From niklas at therning.org Mon Oct 14 00:25:52 2013 From: niklas at therning.org (Niklas Therning) Date: Mon, 14 Oct 2013 09:25:52 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <6806C6E4-3F67-4023-8195-FCC28F9D3D11@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <52587FF2.8070601@gmx.de> <6806C6E4-3F67-4023-8195-FCC28F9D3D11@ultramixer.com> Message-ID: I don't think a Java6 backport is necessary. If the jfx78 backport works on RoboVM it should work on Android (provided that the native stuff is there of course). The problem is the dx tool which doesn't accept Java7 .class files, right? IIUC not much happened to the class file format between Java6 and Java7 (except for invokedynamic and what is need to support it but Java7's javac never generates invokedynamic ops). The APIs to support try-with-resources (AutoCloseable) is already in Android and the syntactic sugar added in Java7 (multi-catch, switch on string, diamond, etc) compiles to Java6 compatible bytecode and uses no new APIs. So it should be easy to make a tool using ASM or similar which takes the jfx78 jar file and rewrites the .class files in it to target 1.6 instead of 1.7 and repackage as a new jar. Just my ?0.02. If you want to maintain a backport of the backport :-) then go for it. On Mon, Oct 14, 2013 at 8:53 AM, Matthias H?nel wrote: > Hi Stefan, > > > thanks for your fast answer. > > > Am 12.10.2013 um 00:47 schrieb Stefan Fuchs : > > > I think you must |add the flag ||-PCOMPILE_PANGO=true to build the new > opensource font stuff. > > I am sure that's not that easy ;) > Actually, I tried it but it didn't do anything in the first place. > > > > If I remember correctly I got a similar error, when I first build jfx78 > on linux. > > > > I made some experiments with javafx on android by myself. > > > > I found the following interesting read: > > > http://stackoverflow.com/questions/7153989/java-7-language-features-with-android > > Well, I didn't use jfx78 vanilla, I used it as a base for the port to > java6. > I am quite sure that we need a java6 port on the long run to support > davlik stable. > > > > One other problem I hit, when trying to compile a larger application was: > > > http://stackoverflow.com/questions/15508477/android-my-application-is-too-large-and-gives-unable-to-execute-dex-method-id > > Ok, interessting, I'll take a look at it when I hit the error. > > > > Apparently there is a limit of ||65536 methods per apk file. > > > > > > Besides, I'm currently two releases behind with the jfx78. > > > > I'll try to catch up soon. > > It would be great to read your findings. > > > kind regards > Matthias > > > > From haenel at ultramixer.com Mon Oct 14 03:17:52 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 12:17:52 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <52593AEA.8070800@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> Message-ID: <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> Hi Tomas, since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) 10-14 06:06:49.719: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) 10-14 06:06:49.729: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) 10-14 06:06:49.729: WARN/System.err(1546): Caused by: java.lang.RuntimeException: Error creating vertex shader 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:132) 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:173) 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createShader(ES2ResourceFactory.java:168) 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.shader.Texture_Color_Loader.loadShader(Texture_Color_Loader.java:47) 10-14 06:06:49.749: WARN/System.err(1546): ... 19 more 10-14 06:06:49.749: WARN/System.err(1546): java.lang.InternalError: Error loading stock shader Texture_Color 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:256) 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) 10-14 06:06:49.779: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) 10-14 06:06:49.779: INFO/GLASS(1546): glass_view_drawEnd I track the error down to, compileShader in ES2Shader.java on line 130. This is returning 0 from native code. The native codes looks okay for me and the Android Simulator is supposed to emulate OpenGL ES 2.0 correclty, so I am not sure why the compileShader returns 0... int vertexShaderID = glCtx.compileShader(vert, true); if (vertexShaderID == 0) { throw new RuntimeException("Error creating vertex shader"); //<<--- this Exception occours. } I know this is the common error from the shader compiler, but this should have worked for you, when you started your own application. Do you have a hint, what I could have been done wrong? I assume right now that the native build is correctly, since it is called from java and it does return the correct EGLContext. This assumption might be wrong. regards Matthias Am 12.10.2013 um 14:04 schrieb Tomas Brandalik : > I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. > > -Tomas > > > On 10/11/2013 06:22 PM, Tom Schindl wrote: >> On 11.10.13 18:10, Matthias H?nel wrote: >>> Hi Tomas, >>> >>> >>> today, I took the time to investigate a little more time on this. >>> >>> 1. I build an entirely new openjfx78 build for android >>> 2. starting this gave me several errors that lead me to the >>> conclusion that I need a java6 openjfx >>> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >>> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >>> is called with a static call to createStyleHelper. >>> >>> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore >> On OS-X font stuff is definately there in jfx78, but the low-level font >> stuff is loaded using reflection (at least this was the cause on robovm)! >> >> Tom > From hang.vo at oracle.com Mon Oct 14 04:33:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 14 Oct 2013 11:33:02 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131014113357.698F862374@hg.openjdk.java.net> Changeset: 30f8458fc228 Author: Martin Sladecek Date: 2013-10-14 13:17 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/30f8458fc228 RT-33476 Improve performance of SortedList over FilteredList when FilteredList predicate changes Reviewed-by: ekrejcir ! modules/base/src/main/java/javafx/collections/transformation/SortedList.java Changeset: 18866f1dbe7b Author: Eva Krejcirova Date: 2013-10-14 12:31 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/18866f1dbe7b RT-32505: GridPane - changing column prefWidth does not relayout Reviewed-by: msladecek ! modules/graphics/src/main/java/javafx/scene/layout/ConstraintsBase.java ! modules/graphics/src/test/java/javafx/scene/layout/GridPaneTest.java From haenel at ultramixer.com Mon Oct 14 04:45:56 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 13:45:56 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> Message-ID: Hi Tomas, never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. There are two things missing: 1. fonts - here we probably need to get pango working for Android right? 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. kind regards Matthias Am 14.10.2013 um 12:17 schrieb Matthias H?nel : > Hi Tomas, > > > since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. > We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. > > 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin > 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. > 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) > 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) > 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API > 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException > 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) > 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) > 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms > 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) > 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) > 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) > 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) > 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) > 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) > 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) > 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) > 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) > 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) > 10-14 06:06:49.719: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) > 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) > 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) > 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) > 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) > 10-14 06:06:49.729: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) > 10-14 06:06:49.729: WARN/System.err(1546): Caused by: java.lang.RuntimeException: Error creating vertex shader > 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:132) > 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:173) > 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createShader(ES2ResourceFactory.java:168) > 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.shader.Texture_Color_Loader.loadShader(Texture_Color_Loader.java:47) > 10-14 06:06:49.749: WARN/System.err(1546): ... 19 more > 10-14 06:06:49.749: WARN/System.err(1546): java.lang.InternalError: Error loading stock shader Texture_Color > 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:256) > 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) > 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) > 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) > 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) > 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) > 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) > 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) > 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) > 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) > 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) > 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) > 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) > 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) > 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) > 10-14 06:06:49.779: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) > 10-14 06:06:49.779: INFO/GLASS(1546): glass_view_drawEnd > > > I track the error down to, compileShader in ES2Shader.java on line 130. This is returning 0 from native code. > The native codes looks okay for me and the Android Simulator is supposed to emulate OpenGL ES 2.0 correclty, so I am not sure > why the compileShader returns 0... > > int vertexShaderID = glCtx.compileShader(vert, true); > if (vertexShaderID == 0) { > throw new RuntimeException("Error creating vertex shader"); //<<--- this Exception occours. > } > > I know this is the common error from the shader compiler, but this should have worked for you, > when you started your own application. Do you have a hint, what I could have been done wrong? > > I assume right now that the native build is correctly, since it is called from java and it does > return the correct EGLContext. This assumption might be wrong. > > > regards > Matthias > > > > > Am 12.10.2013 um 14:04 schrieb Tomas Brandalik : > >> I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. >> >> -Tomas >> >> >> On 10/11/2013 06:22 PM, Tom Schindl wrote: >>> On 11.10.13 18:10, Matthias H?nel wrote: >>>> Hi Tomas, >>>> >>>> >>>> today, I took the time to investigate a little more time on this. >>>> >>>> 1. I build an entirely new openjfx78 build for android >>>> 2. starting this gave me several errors that lead me to the >>>> conclusion that I need a java6 openjfx >>>> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >>>> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >>>> is called with a static call to createStyleHelper. >>>> >>>> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore >>> On OS-X font stuff is definately there in jfx78, but the low-level font >>> stuff is loaded using reflection (at least this was the cause on robovm)! >>> >>> Tom >> > From hang.vo at oracle.com Mon Oct 14 04:47:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 14 Oct 2013 11:47:52 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31362 FXML error reporting Message-ID: <20131014114821.4988462377@hg.openjdk.java.net> Changeset: f027bd6fd54d Author: Martin Sladecek Date: 2013-10-14 13:42 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f027bd6fd54d RT-31362 FXML error reporting Reviewed-by: ekrejcir ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java ! modules/fxml/src/test/java/javafx/fxml/RT_17646Test.java ! modules/fxml/src/test/java/javafx/fxml/RT_18933Test.java From hang.vo at oracle.com Mon Oct 14 05:03:38 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 14 Oct 2013 12:03:38 +0000 Subject: hg: openjfx/8/graphics/rt: RT-23861: Mac: Check: use NewGlobalRef when caching jclass Message-ID: <20131014120417.BC6AC6237B@hg.openjdk.java.net> Changeset: 2ba9e3de19a0 Author: Anthony Petrov Date: 2013-10-14 15:52 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2ba9e3de19a0 RT-23861: Mac: Check: use NewGlobalRef when caching jclass Reviewed-by: art, kcr, pchelko ! modules/graphics/src/main/native-glass/mac/GlassCursor.m ! modules/graphics/src/main/native-glass/mac/GlassHelper.m ! modules/graphics/src/main/native-glass/mac/GlassMenu.m ! modules/graphics/src/main/native-glass/mac/GlassView.m ! modules/graphics/src/main/native-glass/mac/GlassWindow.m From tomas.brandalik at oracle.com Mon Oct 14 05:31:09 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Mon, 14 Oct 2013 14:31:09 +0200 Subject: JAVAFX on ANDROID In-Reply-To: References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> Message-ID: <525BE40D.6090808@oracle.com> Hi Matthias, cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA8888 in emulator. But that could have changed overtime. Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. good luck -Tomas On 10/14/2013 01:45 PM, Matthias H?nel wrote: > Hi Tomas, > > > never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. > > So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. > > There are two things missing: > 1. fonts - here we probably need to get pango working for Android right? > 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative > This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. > > After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. > > > kind regards > Matthias > > > > Am 14.10.2013 um 12:17 schrieb Matthias H?nel : > >> Hi Tomas, >> >> >> since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. >> We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. >> >> 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin >> 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. >> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) >> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) >> 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >> 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException >> 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) >> 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) >> 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms >> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) >> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) >> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) >> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) >> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) >> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) >> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) >> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) >> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) >> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) >> 10-14 06:06:49.719: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) >> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) >> 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) >> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) >> 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) >> 10-14 06:06:49.729: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) >> 10-14 06:06:49.729: WARN/System.err(1546): Caused by: java.lang.RuntimeException: Error creating vertex shader >> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:132) >> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:173) >> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createShader(ES2ResourceFactory.java:168) >> 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.shader.Texture_Color_Loader.loadShader(Texture_Color_Loader.java:47) >> 10-14 06:06:49.749: WARN/System.err(1546): ... 19 more >> 10-14 06:06:49.749: WARN/System.err(1546): java.lang.InternalError: Error loading stock shader Texture_Color >> 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:256) >> 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) >> 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) >> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) >> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) >> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) >> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) >> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) >> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) >> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) >> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) >> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) >> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) >> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) >> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) >> 10-14 06:06:49.779: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) >> 10-14 06:06:49.779: INFO/GLASS(1546): glass_view_drawEnd >> >> >> I track the error down to, compileShader in ES2Shader.java on line 130. This is returning 0 from native code. >> The native codes looks okay for me and the Android Simulator is supposed to emulate OpenGL ES 2.0 correclty, so I am not sure >> why the compileShader returns 0... >> >> int vertexShaderID = glCtx.compileShader(vert, true); >> if (vertexShaderID == 0) { >> throw new RuntimeException("Error creating vertex shader"); //<<--- this Exception occours. >> } >> >> I know this is the common error from the shader compiler, but this should have worked for you, >> when you started your own application. Do you have a hint, what I could have been done wrong? >> >> I assume right now that the native build is correctly, since it is called from java and it does >> return the correct EGLContext. This assumption might be wrong. >> >> >> regards >> Matthias >> >> >> >> >> Am 12.10.2013 um 14:04 schrieb Tomas Brandalik : >> >>> I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. >>> >>> -Tomas >>> >>> >>> On 10/11/2013 06:22 PM, Tom Schindl wrote: >>>> On 11.10.13 18:10, Matthias H?nel wrote: >>>>> Hi Tomas, >>>>> >>>>> >>>>> today, I took the time to investigate a little more time on this. >>>>> >>>>> 1. I build an entirely new openjfx78 build for android >>>>> 2. starting this gave me several errors that lead me to the >>>>> conclusion that I need a java6 openjfx >>>>> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >>>>> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >>>>> is called with a static call to createStyleHelper. >>>>> >>>>> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore >>>> On OS-X font stuff is definately there in jfx78, but the low-level font >>>> stuff is loaded using reflection (at least this was the cause on robovm)! >>>> >>>> Tom From haenel at ultramixer.com Mon Oct 14 06:49:15 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Mon, 14 Oct 2013 15:49:15 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525BE40D.6090808@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> <525BE40D.6090808@oracle.com> Message-ID: <1370ACDE-6498-4B38-9B72-9E6AA02D2351@ultramixer.com> Hi Tomas, Am 14.10.2013 um 14:31 schrieb tomas.brandalik : > Hi Matthias, > cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA8888 in emulator. But that could have changed overtime. well, this is probably not an coinsidence. I have seen your BGRA8888 quirk, but this doesn't apply to Android actually. I fixed it like someone fixed it for iOS: public boolean isFormatSupported(PixelFormat format) { GLFactory glFactory = ES2Pipeline.glFactory; switch (format) { case BYTE_RGB: case BYTE_GRAY: case BYTE_ALPHA: case MULTI_YCbCr_420: return true; case BYTE_BGRA_PRE: case INT_ARGB_PRE: if (glFactory.isGL2() || PlatformUtil.isIOS() || PlatformUtil.isAndroid()) { > Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. It would be great, if you could pass the changes to me as well, since I have a backport (java6) from a backport(java7) running over here ;) Otherwise, it could take a while. > In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. Hhm, this sounds like quite some work. Pango would probably the fastest way to do. Do you know where I have to place it? regards Matthias From richard.bair at oracle.com Mon Oct 14 06:49:18 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 14 Oct 2013 06:49:18 -0700 Subject: JAVAFX on ANDROID In-Reply-To: <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> Message-ID: <8BD75CA6-6CF7-4C11-9971-EAC2D924DE90@oracle.com> Hi Matthias, > The main point of irritation comes from an quite unclear position about providing the JVM and JFX of the Java-platform. > That's why I will sumarize what I heard between the lines: > > 1. there is NO official jvm planned for iOS and Android in the near future. > 2. jfx8 is beeing officially maintained until some point for iOS and Android but the actual port is left to the open source community. > 3. Linux ARM support is beeing focused officially on the Freescale ARM-platform. That is right. > our conclusion is: > 1. that's not that bad anymore since we have RoboVM for iOS and Davlik on Android. > 2. this statement should have been made 1 year ago. Probably, I missed it but it was not clear to my team as well until last week. > That's why we took the challenge to do it our selves. You rock :-) > 3. This is good for the open source development since we probably can rely on the CPU optimized parts for ARM. This exactly. All the work we do for embedded translates directly to iOS and android, since it is the same hardware and graphics chips. Cheers Richard From hang.vo at oracle.com Mon Oct 14 07:03:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 14 Oct 2013 14:03:27 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-33412: The mouse cursor needs to move in order for a setCursor(Cursor) to take effect Message-ID: <20131014140546.241C16237E@hg.openjdk.java.net> Changeset: 344b7903fd4c Author: Lubomir Nerad Date: 2013-10-14 15:55 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/344b7903fd4c Fix for RT-33412: The mouse cursor needs to move in order for a setCursor(Cursor) to take effect Reviewed by: Pavel Safrata ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/test/java/javafx/scene/SceneTest.java From hang.vo at oracle.com Mon Oct 14 07:32:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 14 Oct 2013 14:32:54 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed test method names Message-ID: <20131014143328.F31EC62380@hg.openjdk.java.net> Changeset: 64359ff1b288 Author: Lubomir Nerad Date: 2013-10-14 16:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/64359ff1b288 Fixed test method names ! modules/graphics/src/test/java/javafx/scene/SceneTest.java From hang.vo at oracle.com Mon Oct 14 08:17:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 14 Oct 2013 15:17:57 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31426 Modaility/toFront issues Message-ID: <20131014151854.E864662383@hg.openjdk.java.net> Changeset: ab44fa8be486 Author: ddhill Date: 2013-10-14 11:01 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab44fa8be486 RT-31426 Modaility/toFront issues reviewed: anthony, pchelko, kselle ! modules/graphics/src/main/java/com/sun/glass/ui/Window.java ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensWindow.java ! modules/graphics/src/main/native-glass/lens/LensApplication.c ! modules/graphics/src/main/native-glass/lens/LensWindow.c From felipe.heidrich at oracle.com Mon Oct 14 08:45:04 2013 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Mon, 14 Oct 2013 08:45:04 -0700 Subject: JAVAFX on ANDROID In-Reply-To: <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> Message-ID: <52373365-9972-46FB-980A-4C95E37844A3@oracle.com> Hi, I'm not familiar with the Android build process but basically this is what you need: Build graphics/src/main/native-font/fontpath_linux.c to a library called "javafx_font", that it will be loaded by PrismFontFactory.java (but used by FontConfigManager.java). This is our fontconfig binding used to locate fonts. All references to fontconfig in the native code are dynamic, so you should only need the JNI references while building this object. Build graphics/src/main/native-font/freetype.c and graphics/src/main/native-font/pango.c To a library named "javafx-font-pango" The cc flags to build them are "pkg-config --cflags pangoft2" + "-D_ENABLE_PANGO", the lib flags are pkg-config --libs pangoft2 (see rt/buildSrc/linux.gradle, search pangoCCFlags and pangoLinkFlags). This library will be used by graphics/src/main/java/com/sun/javafx/font/pango/OS.java During runtime you will need to explicitly set "-Dprism.text=native" so that PangoFactory.java is used (instead of T2KFactory.java). Note: if that is too hard to build pango.o I suppose you could link javafx-font-pango.so only with freetype.o, you should not see any unsatisfied link exception as long as PangoFactory.createGlyphLayout is not called. Setting -Dprism.debugfonts=true should help to see what is getting loaded, -Djavafx.verbose=true prints what library as being loaded by JFX. Regards, Felipe On Oct 13, 2013, at 11:49 PM, Matthias H?nel wrote: > Is there a fallback? Pango doesn't work either it's not used in the android gradle scripts. > I would be happy to integrate it and I am sure I can compile pango for android. I just need a pointer to how I can integrate it into the build process. > I changed android.gradle but I am not sure where to put the pango sources. From hang.vo at oracle.com Mon Oct 14 12:18:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 14 Oct 2013 19:18:03 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131014191859.DB70962397@hg.openjdk.java.net> Changeset: 0273f76722e7 Author: Daniel Blaukopf Date: 2013-10-14 22:05 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0273f76722e7 RT-29151 EGLFB: showFileChooser throws IllegalStateException ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java - modules/graphics/src/main/java/com/sun/glass/ui/lens/LensCommonDialogs.java Changeset: 13215a622f6a Author: Daniel Blaukopf Date: 2013-10-14 22:12 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/13215a622f6a RT-30743 EGLFB: Cursor cannot be moved to right or bottom of screen on Beagleboard Reviewed-by: Rafi Tayar, kselle ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c ! modules/graphics/src/main/native-glass/lens/platform-util/omapCursor.c From hang.vo at oracle.com Mon Oct 14 14:03:25 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 14 Oct 2013 21:03:25 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131014210435.8238B6239F@hg.openjdk.java.net> Changeset: bdcdde212f13 Author: jgiles Date: 2013-10-14 15:45 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bdcdde212f13 RT-32700: TreeTableView alignment is not correct Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: c0624eaccdb0 Author: jgiles Date: 2013-10-15 09:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c0624eaccdb0 Removing bad line from previous commit. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkinBase.java From hang.vo at oracle.com Mon Oct 14 17:32:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 00:32:55 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33527: Style -fx-wrap-text worked only when set minWidth to control Message-ID: <20131015003408.47324623B4@hg.openjdk.java.net> Changeset: 7aa32bd90b97 Author: leifs Date: 2013-10-14 17:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7aa32bd90b97 RT-33527: Style -fx-wrap-text worked only when set minWidth to control Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/CheckBoxSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/RadioButtonSkin.java From hang.vo at oracle.com Mon Oct 14 17:47:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 00:47:37 +0000 Subject: hg: openjfx/8/graphics/rt: [TOYS ONLY] Fix an old SubScene constructor call to use the new API. Message-ID: <20131015004755.80B9B623B5@hg.openjdk.java.net> Changeset: 829cb36bdc4e Author: Chien Yang Date: 2013-10-14 17:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/829cb36bdc4e [TOYS ONLY] Fix an old SubScene constructor call to use the new API. ! apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCameraSubScene.java From hang.vo at oracle.com Mon Oct 14 18:17:41 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 01:17:41 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20131015011828.EC6B3623B6@hg.openjdk.java.net> Changeset: 554cf8a1c3aa Author: jgiles Date: 2013-10-15 10:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/554cf8a1c3aa RT-33229: [ListView] page up/down navigation doesn't work, when items are large Reviewed-by: psomashe ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java Changeset: 2cbb5014e387 Author: jgiles Date: 2013-10-15 11:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2cbb5014e387 RT-33558: [Virtualised Controls] Clicking a row twice should not send selection change events the second time Reviewed-by: psomashe ! modules/controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/ListViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java Changeset: aa9149c6bf5d Author: jgiles Date: 2013-10-15 12:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/aa9149c6bf5d RT-33559: [TreeView, TreeTableView] Errant permutation events when selected row is expanded Reviewed-by: psomashe ! modules/controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java ! modules/controls/src/test/java/javafx/scene/control/ListViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewTest.java From hang.vo at oracle.com Mon Oct 14 19:47:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 02:47:43 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131015024834.A9731623BC@hg.openjdk.java.net> Changeset: 9f888001d100 Author: jgiles Date: 2013-10-15 14:45 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9f888001d100 RT-32310: Issue on fixed cell height implementation ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: ace4d0178ecb Author: jgiles Date: 2013-10-15 15:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ace4d0178ecb RT-20915: [ListView] CTRL-SHIFT-SPACE does not work in multi-selection mode Fixed for ListView, TreeView, TableView and TreeTableView. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/test/java/javafx/scene/control/ListViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java From haenel at ultramixer.com Tue Oct 15 00:07:06 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Tue, 15 Oct 2013 09:07:06 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <52373365-9972-46FB-980A-4C95E37844A3@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> <52373365-9972-46FB-980A-4C95E37844A3@oracle.com> Message-ID: <60B74720-0C9A-4614-8FD0-A0C762BBC203@ultramixer.com> Hi Felipe, thanks for your fast answer. Unfortunately, this is not enough information for a sufficient solution ;) Maybe I am too far from gradle away in my thinking (Makefiles) to understand this one fully. I know where the sources are and I am pretty sure I can build a library by hand. Actually, I added to the android gradle script the Linux fontpango parts and the pkg-config tool. I assume that the default linux gradle script looks for the pango libs in /usr/share ... (default paths). Now we are in a cross platform enviornment for Android. At least I have to call ./configure with the android toolchain. That should not be hard to do. What I don't know is, how do I add this to the gradle script? I see the pkg-config in crosslibs but that relies on the assumption that pango resides somewhere in ${SYSROOT}. Well, I probably could build pango (haven't tried yet) for android and put it in the NDK, from my point of view, that wouldn't work later at run time. The .so must be linked and delivered with the App. Maybe someone can enlighten me how I can integrate a third party library build into the gradle universe ;) regards Matthias Am 14.10.2013 um 17:45 schrieb Felipe Heidrich : > > Hi, I'm not familiar with the Android build process but basically this is what you need: > > Build graphics/src/main/native-font/fontpath_linux.c to a library called "javafx_font", that it will be loaded by PrismFontFactory.java (but used by FontConfigManager.java). > This is our fontconfig binding used to locate fonts. All references to fontconfig in the native code are dynamic, so you should only need the JNI references while building this object. > > > Build > graphics/src/main/native-font/freetype.c > and > graphics/src/main/native-font/pango.c > To a library named "javafx-font-pango" > > The cc flags to build them are "pkg-config --cflags pangoft2" + "-D_ENABLE_PANGO", the lib flags are pkg-config --libs pangoft2 > (see rt/buildSrc/linux.gradle, search pangoCCFlags and pangoLinkFlags). > > This library will be used by graphics/src/main/java/com/sun/javafx/font/pango/OS.java > > During runtime you will need to explicitly set "-Dprism.text=native" so that PangoFactory.java is used (instead of T2KFactory.java). > > Note: if that is too hard to build pango.o I suppose you could link javafx-font-pango.so only with freetype.o, you should not see any unsatisfied link exception as long as PangoFactory.createGlyphLayout is not called. > > Setting -Dprism.debugfonts=true should help to see what is getting loaded, -Djavafx.verbose=true prints what library as being loaded by JFX. > > Regards, > Felipe > > > On Oct 13, 2013, at 11:49 PM, Matthias H?nel wrote: > >> Is there a fallback? Pango doesn't work either it's not used in the android gradle scripts. >> I would be happy to integrate it and I am sure I can compile pango for android. I just need a pointer to how I can integrate it into the build process. >> I changed android.gradle but I am not sure where to put the pango sources. > From hang.vo at oracle.com Tue Oct 15 02:37:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 09:37:42 +0000 Subject: hg: openjfx/8/graphics/rt: [RT-32802] Lens: touch events are not handled corectly - step 2 Message-ID: <20131015093952.735D6623D3@hg.openjdk.java.net> Changeset: de742211e084 Author: Assaf Yavani Date: 2013-10-15 12:27 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/de742211e084 [RT-32802] Lens: touch events are not handled corectly - step 2 Summary: in this patch: [major] 1) added touch screen protocol detection (not fully used yet) 2) downgrade protocol B device to protocol A, our code can handle it 3) converted ST devices events into same data structures used by MT 4) remove touch events handling from key event handling 5) due to item #4 added missing functionality for 'no new events, but some old events -> release points' As a result: a)all touch event are processed by the same code b) mouse handling and mouse synthesizing is done is standalone code c)exception throwing have decreased dramatically (still happening when pushing it.... see JIRA for details) This webrev include step1.1 changes as crusiable couldn't attached the diff into a repository, although step 1.1 was already committed (timing i guess) - so please ignore them [minor] 1) extended multi touch event toString() for debugging Tested by: running helloworld.HelloSanity::controls and LinuxInputTests Reviewed-by: David Hill (ddhill), Lisa Selle (lisa.selle at oracle.com), Rafi Tayar (rafi.tayar at oracle.com) and Daniel Blaukopf (dblaukop) Contributed-by: ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensApplication.java ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c ! modules/graphics/src/main/native-glass/lens/input/x11Container/x11Input.c ! modules/graphics/src/main/native-glass/lens/lensRFB/rfb.c ! modules/graphics/src/main/native-glass/lens/wm/LensWindowManager.c ! modules/graphics/src/main/native-glass/lens/wm/LensWindowManager.h ! modules/graphics/src/main/native-glass/lens/wm/robot.c From hang.vo at oracle.com Tue Oct 15 03:03:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 10:03:22 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28490: Mac: FXML-LoginDemo hangs in the browser when returning from full screen Message-ID: <20131015100350.7DABE623DB@hg.openjdk.java.net> Changeset: 399ffe9e82f9 Author: art Date: 2013-10-15 13:54 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/399ffe9e82f9 RT-28490: Mac: FXML-LoginDemo hangs in the browser when returning from full screen Reviewed-by: anthony, pchelko ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java From hang.vo at oracle.com Tue Oct 15 03:47:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 10:47:57 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33490 Gtk: Linux : Issues with Drag and Drop on Linux platform Message-ID: <20131015104822.09E7A623E1@hg.openjdk.java.net> Changeset: b0b86abdaddd Author: Alexander Zvegintsev Date: 2013-10-15 14:28 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b0b86abdaddd RT-33490 Gtk: Linux : Issues with Drag and Drop on Linux platform Reviewed-by: anthony ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp From hang.vo at oracle.com Tue Oct 15 04:17:46 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 11:17:46 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33538: [macosx] Assertion failure when toggling fullscreen Message-ID: <20131015111806.B3E73623E4@hg.openjdk.java.net> Changeset: 195924590faf Author: Petr Pchelko Date: 2013-10-15 15:03 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/195924590faf RT-33538: [macosx] Assertion failure when toggling fullscreen Reviewed-by: anthony, art ! modules/graphics/src/main/native-glass/mac/GlassViewDelegate.m From haenel at ultramixer.com Tue Oct 15 04:50:39 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Tue, 15 Oct 2013 13:50:39 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525BE40D.6090808@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> <525BE40D.6090808@oracle.com> Message-ID: <72E7A9DA-1D60-49BD-B04E-2DD8067BB5EB@ultramixer.com> Hey Tomas, I've seen a check-in for RT-32802. This seems to be your fix. There are a lot of interface changes. Could you explain the changes a bit, so I can merge it by hand into my jfx678 code? Today, I merged from Stefans b111 JFX78 but it will take a while to get your changes through this way ;) regards Matthias Am 14.10.2013 um 14:31 schrieb tomas.brandalik : > Hi Matthias, > cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA8888 in emulator. But that could have changed overtime. > Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. > In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. > > good luck > -Tomas > > On 10/14/2013 01:45 PM, Matthias H?nel wrote: >> Hi Tomas, >> >> >> never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. >> >> So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. >> >> There are two things missing: >> 1. fonts - here we probably need to get pango working for Android right? >> 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative >> This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. >> >> After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. >> >> >> kind regards >> Matthias >> >> >> >> Am 14.10.2013 um 12:17 schrieb Matthias H?nel : >> >>> Hi Tomas, >>> >>> >>> since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. >>> We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. >>> >>> 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin >>> 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) >>> 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException >>> 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) >>> 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) >>> 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) >>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) >>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) >>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) >>> 10-14 06:06:49.719: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) >>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) >>> 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) >>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) >>> 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) >>> 10-14 06:06:49.729: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) >>> 10-14 06:06:49.729: WARN/System.err(1546): Caused by: java.lang.RuntimeException: Error creating vertex shader >>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:132) >>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:173) >>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createShader(ES2ResourceFactory.java:168) >>> 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.shader.Texture_Color_Loader.loadShader(Texture_Color_Loader.java:47) >>> 10-14 06:06:49.749: WARN/System.err(1546): ... 19 more >>> 10-14 06:06:49.749: WARN/System.err(1546): java.lang.InternalError: Error loading stock shader Texture_Color >>> 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:256) >>> 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) >>> 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) >>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) >>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) >>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) >>> 10-14 06:06:49.779: INFO/GLASS(1546): glass_view_drawEnd >>> >>> >>> I track the error down to, compileShader in ES2Shader.java on line 130. This is returning 0 from native code. >>> The native codes looks okay for me and the Android Simulator is supposed to emulate OpenGL ES 2.0 correclty, so I am not sure >>> why the compileShader returns 0... >>> >>> int vertexShaderID = glCtx.compileShader(vert, true); >>> if (vertexShaderID == 0) { >>> throw new RuntimeException("Error creating vertex shader"); //<<--- this Exception occours. >>> } >>> >>> I know this is the common error from the shader compiler, but this should have worked for you, >>> when you started your own application. Do you have a hint, what I could have been done wrong? >>> >>> I assume right now that the native build is correctly, since it is called from java and it does >>> return the correct EGLContext. This assumption might be wrong. >>> >>> >>> regards >>> Matthias >>> >>> >>> >>> >>> Am 12.10.2013 um 14:04 schrieb Tomas Brandalik : >>> >>>> I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. >>>> >>>> -Tomas >>>> >>>> >>>> On 10/11/2013 06:22 PM, Tom Schindl wrote: >>>>> On 11.10.13 18:10, Matthias H?nel wrote: >>>>>> Hi Tomas, >>>>>> >>>>>> >>>>>> today, I took the time to investigate a little more time on this. >>>>>> >>>>>> 1. I build an entirely new openjfx78 build for android >>>>>> 2. starting this gave me several errors that lead me to the >>>>>> conclusion that I need a java6 openjfx >>>>>> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >>>>>> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >>>>>> is called with a static call to createStyleHelper. >>>>>> >>>>>> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore >>>>> On OS-X font stuff is definately there in jfx78, but the low-level font >>>>> stuff is loaded using reflection (at least this was the cause on robovm)! >>>>> >>>>> Tom > From phdoerfler at gmail.com Tue Oct 15 04:50:47 2013 From: phdoerfler at gmail.com (=?windows-1252?Q?Philipp_D=F6rfler?=) Date: Tue, 15 Oct 2013 13:50:47 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <60B74720-0C9A-4614-8FD0-A0C762BBC203@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> <52373365-9972-46FB-980A-4C95E37844A3@oracle.com> <60B74720-0C9A-4614-8FD0-A0C762BBC203@ultramixer.com> Message-ID: <26DAB8BD-4976-45C4-8FFE-B98E149CCD0F@gmail.com> I might be a bit late to the party but I lately discovered something that might be useful for backporting JavaFX 8 to Java 6: > Retrolambda lets you run Java 8 code with lambda expressions on Java 7 or lower. It does this by transforming your Java 8 compiled bytecode so that it can run on a Java 7 runtime. After the transformation they are just a bunch of normal .class files, without adding any runtime dependencies. https://github.com/orfjackal/retrolambda Hope this helps, Philipp D?rfler From tobi at ultramixer.com Tue Oct 15 05:10:02 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 15 Oct 2013 14:10:02 +0200 Subject: developers wanted to port RoboVM AOT compiler to Android Message-ID: <411723E2-6C32-46D5-8B12-0A932E78172F@ultramixer.com> https://github.com/robovm/robovm/issues/186 discussion here: https://groups.google.com/forum/#!searchin/robovm/android/robovm/x_X33VLMxDU/sHnozCJiY4kJ From haenel at ultramixer.com Tue Oct 15 06:07:33 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Tue, 15 Oct 2013 15:07:33 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525BE40D.6090808@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> <525BE40D.6090808@oracle.com> Message-ID: <7F87527D-8E3C-4231-B7DE-3D837F75DE75@ultramixer.com> Hi Tomas, I couldn't stand to merge it by hand ;) I merged the changes from RT-32802 into my backport. Unfortunately, it still crashes: 10-15 08:59:47.182: INFO/GLASS(3644): JNI call notifyTouchEvent 10-15 08:59:47.202: INFO/GLASS(3644): Window 1[0x2a41a138] isVisible=true, state=NORMAL 10-15 08:59:47.202: INFO/GLASS(3644): Absolute coordinates 542,414 are on window 1[0x2a41a138] as relative coordinates 670,292 10-15 08:59:47.202: INFO/GLASS(3644): Returning focused window 1[0x2a41a138] 10-15 08:59:47.202: ERROR/dalvikvm(3644): ERROR: detaching thread with interp frames (count=42) 10-15 08:59:47.213: INFO/dalvikvm(3644): "main" prio=5 tid=1 RUNNABLE 10-15 08:59:47.213: INFO/dalvikvm(3644): | group="main" sCount=0 dsCount=0 obj=0x414c5578 self=0x2a00d090 10-15 08:59:47.222: INFO/dalvikvm(3644): | sysTid=3644 nice=0 sched=0/0 cgrp=apps handle=1073811452 10-15 08:59:47.222: INFO/dalvikvm(3644): | state=R schedstat=( 6545290672 1534059118 8044 ) utm=610 stm=44 core=0 10-15 08:59:47.252: INFO/dalvikvm(3644): at com.oracle.dalvik.FXActivity$InternalSurfaceView.onMultiTouchEventNative(Native Method) 10-15 08:59:47.252: INFO/dalvikvm(3644): at com.oracle.dalvik.FXActivity$InternalSurfaceView.dispatchTouchEvent(FXActivity.java:234) Do you have any idea? The error "ERROR: detaching thread with interp frames (count=42)" seems to be a thread attach/detach mistake in the code. In androidLens.c there is some ATTACH_JNI_THREAD and DTACH_JNI_THREAD code. There are two implementations. One that's filled with (*vm)-> and the other one is left blank. Currently, the macro DALVI_VM is not defined, so the code is filled. This seems to be odd to me. Actually, I tried defining DAVLIK_VM but it doesn't help. It still crashes with the sme error. regards Matthais Am 14.10.2013 um 14:31 schrieb tomas.brandalik : > Hi Matthias, > cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA8888 in emulator. But that could have changed overtime. > Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. > In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. > > good luck > -Tomas > > On 10/14/2013 01:45 PM, Matthias H?nel wrote: >> Hi Tomas, >> >> >> never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. >> >> So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. >> >> There are two things missing: >> 1. fonts - here we probably need to get pango working for Android right? >> 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative >> This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. >> >> After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. >> >> >> kind regards >> Matthias >> >> >> >> Am 14.10.2013 um 12:17 schrieb Matthias H?nel : >> >>> Hi Tomas, >>> >>> >>> since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. >>> We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. >>> >>> 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin >>> 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) >>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) >>> 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>> 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException >>> 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) >>> 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) >>> 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) >>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) >>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) >>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) >>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) >>> 10-14 06:06:49.719: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) >>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) >>> 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) >>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) >>> 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) >>> 10-14 06:06:49.729: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) >>> 10-14 06:06:49.729: WARN/System.err(1546): Caused by: java.lang.RuntimeException: Error creating vertex shader >>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:132) >>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:173) >>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createShader(ES2ResourceFactory.java:168) >>> 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.shader.Texture_Color_Loader.loadShader(Texture_Color_Loader.java:47) >>> 10-14 06:06:49.749: WARN/System.err(1546): ... 19 more >>> 10-14 06:06:49.749: WARN/System.err(1546): java.lang.InternalError: Error loading stock shader Texture_Color >>> 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:256) >>> 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) >>> 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) >>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) >>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) >>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) >>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) >>> 10-14 06:06:49.779: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) >>> 10-14 06:06:49.779: INFO/GLASS(1546): glass_view_drawEnd >>> >>> >>> I track the error down to, compileShader in ES2Shader.java on line 130. This is returning 0 from native code. >>> The native codes looks okay for me and the Android Simulator is supposed to emulate OpenGL ES 2.0 correclty, so I am not sure >>> why the compileShader returns 0... >>> >>> int vertexShaderID = glCtx.compileShader(vert, true); >>> if (vertexShaderID == 0) { >>> throw new RuntimeException("Error creating vertex shader"); //<<--- this Exception occours. >>> } >>> >>> I know this is the common error from the shader compiler, but this should have worked for you, >>> when you started your own application. Do you have a hint, what I could have been done wrong? >>> >>> I assume right now that the native build is correctly, since it is called from java and it does >>> return the correct EGLContext. This assumption might be wrong. >>> >>> >>> regards >>> Matthias >>> >>> >>> >>> >>> Am 12.10.2013 um 14:04 schrieb Tomas Brandalik : >>> >>>> I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. >>>> >>>> -Tomas >>>> >>>> >>>> On 10/11/2013 06:22 PM, Tom Schindl wrote: >>>>> On 11.10.13 18:10, Matthias H?nel wrote: >>>>>> Hi Tomas, >>>>>> >>>>>> >>>>>> today, I took the time to investigate a little more time on this. >>>>>> >>>>>> 1. I build an entirely new openjfx78 build for android >>>>>> 2. starting this gave me several errors that lead me to the >>>>>> conclusion that I need a java6 openjfx >>>>>> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >>>>>> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >>>>>> is called with a static call to createStyleHelper. >>>>>> >>>>>> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore >>>>> On OS-X font stuff is definately there in jfx78, but the low-level font >>>>> stuff is loaded using reflection (at least this was the cause on robovm)! >>>>> >>>>> Tom > From tomas.brandalik at oracle.com Tue Oct 15 06:28:21 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Tue, 15 Oct 2013 15:28:21 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <26DAB8BD-4976-45C4-8FFE-B98E149CCD0F@gmail.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> <52373365-9972-46FB-980A-4C95E37844A3@oracle.com> <60B74720-0C9A-4614-8FD0-A0C762BBC203@ultramixer.com> <26DAB8BD-4976-45C4-8FFE-B98E149CCD0F@gmail.com> Message-ID: <525D42F5.1030905@oracle.com> Hi Philip, I do backport jfx8 to jfx7 and then retrolambda it to be jdk6 compatible. It sort of works ok. I suppose that it just replaces class file version since there are not used lambda expressions in jfx8 yet. Will see if that solution works when lambdas start to appear in jfx. -Tomas On 10/15/2013 01:50 PM, Philipp D?rfler wrote: > I might be a bit late to the party but I lately discovered something that might be useful for backporting JavaFX 8 to Java 6: > >> Retrolambda lets you run Java 8 code with lambda expressions on Java 7 or lower. It does this by transforming your Java 8 compiled bytecode so that it can run on a Java 7 runtime. After the transformation they are just a bunch of normal .class files, without adding any runtime dependencies. > https://github.com/orfjackal/retrolambda > > Hope this helps, > Philipp D?rfler From tomas.brandalik at oracle.com Tue Oct 15 07:26:46 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Tue, 15 Oct 2013 16:26:46 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <60B74720-0C9A-4614-8FD0-A0C762BBC203@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <1364102331-1381509250-cardhu_decombobulator_blackberry.rim.net-872396709-@b15.c11.bise6.blackberry> <19E72954-1E5D-48EC-91A8-022615BDC3E3@oracle.com> <3B9D1317-A4EC-4732-963B-6938514D10F0@ultramixer.com> <52373365-9972-46FB-980A-4C95E37844A3@oracle.com> <60B74720-0C9A-4614-8FD0-A0C762BBC203@ultramixer.com> Message-ID: <525D50A6.2020000@oracle.com> I would recommend to build pango by hand first. I don't think that it is so straightforward. It has many dependencies iconv, expat, fontconfig, freetype, glib at least. After a whole day of struggling my pango build failed somewhere in the middle at "who-knows-where-it-comes-from" macro :( -wish you more luck Tomas On 10/15/2013 09:07 AM, Matthias H?nel wrote: > Hi Felipe, > > > thanks for your fast answer. > > Unfortunately, this is not enough information for a sufficient solution ;) > Maybe I am too far from gradle away in my thinking (Makefiles) to understand this one fully. > > > I know where the sources are and I am pretty sure I can build a library by hand. Actually, I added > to the android gradle script the Linux fontpango parts and the pkg-config tool. > > I assume that the default linux gradle script looks for the pango libs in /usr/share ... > (default paths). Now we are in a cross platform enviornment for Android. At least I have to call > ./configure with the android toolchain. That should not be hard to do. > > What I don't know is, how do I add this to the gradle script? > I see the pkg-config in crosslibs but that relies on the assumption that pango resides > somewhere in ${SYSROOT}. > > Well, I probably could build pango (haven't tried yet) for android and put it in the NDK, > from my point of view, that wouldn't work later at run time. The .so must be linked and > delivered with the App. Maybe someone can enlighten me how I can integrate a third party > library build into the gradle universe ;) > > > regards > Matthias > > > > Am 14.10.2013 um 17:45 schrieb Felipe Heidrich : > >> Hi, I'm not familiar with the Android build process but basically this is what you need: >> >> Build graphics/src/main/native-font/fontpath_linux.c to a library called "javafx_font", that it will be loaded by PrismFontFactory.java (but used by FontConfigManager.java). >> This is our fontconfig binding used to locate fonts. All references to fontconfig in the native code are dynamic, so you should only need the JNI references while building this object. >> >> >> Build >> graphics/src/main/native-font/freetype.c >> and >> graphics/src/main/native-font/pango.c >> To a library named "javafx-font-pango" >> >> The cc flags to build them are "pkg-config --cflags pangoft2" + "-D_ENABLE_PANGO", the lib flags are pkg-config --libs pangoft2 >> (see rt/buildSrc/linux.gradle, search pangoCCFlags and pangoLinkFlags). >> >> This library will be used by graphics/src/main/java/com/sun/javafx/font/pango/OS.java >> >> During runtime you will need to explicitly set "-Dprism.text=native" so that PangoFactory.java is used (instead of T2KFactory.java). >> >> Note: if that is too hard to build pango.o I suppose you could link javafx-font-pango.so only with freetype.o, you should not see any unsatisfied link exception as long as PangoFactory.createGlyphLayout is not called. >> >> Setting -Dprism.debugfonts=true should help to see what is getting loaded, -Djavafx.verbose=true prints what library as being loaded by JFX. >> >> Regards, >> Felipe >> >> >> On Oct 13, 2013, at 11:49 PM, Matthias H?nel wrote: >> >>> Is there a fallback? Pango doesn't work either it's not used in the android gradle scripts. >>> I would be happy to integrate it and I am sure I can compile pango for android. I just need a pointer to how I can integrate it into the build process. >>> I changed android.gradle but I am not sure where to put the pango sources. From hang.vo at oracle.com Tue Oct 15 07:48:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 14:48:07 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20131015144905.B1FAA623EB@hg.openjdk.java.net> Changeset: f726500421e6 Author: mickf Date: 2013-10-15 15:36 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f726500421e6 RT-31970 : SplitPane doesn't clip its content, reviewed by David ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java Changeset: 0bb70100941c Author: psomashe Date: 2013-10-15 07:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0bb70100941c RT-33526 NPE when Drag&Drop MenuBar reviewed by Jonathan ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java From hang.vo at oracle.com Tue Oct 15 08:47:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 15:47:50 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33578 Lens: Warnings when compiling omapCursor.c Message-ID: <20131015154832.AB0E3623EF@hg.openjdk.java.net> Changeset: ff50caf00759 Author: Daniel Blaukopf Date: 2013-10-15 17:56 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ff50caf00759 RT-33578 Lens: Warnings when compiling omapCursor.c Reviewed-by: Assaf Yavnai ! modules/graphics/src/main/native-glass/lens/platform-util/omapCursor.c From hang.vo at oracle.com Tue Oct 15 09:17:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 16:17:56 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed RT-28501: Button Printed improperly Message-ID: <20131015161824.90195623F2@hg.openjdk.java.net> Changeset: 30e0e283ef1b Author: prr Date: 2013-10-15 09:16 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/30e0e283ef1b Fixed RT-28501: Button Printed improperly Reviewed-by: kcr, jgodinez ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java From hang.vo at oracle.com Tue Oct 15 09:47:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 16:47:58 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20131015164851.72A38623F9@hg.openjdk.java.net> Changeset: 88d3bef80ffc Author: hudson Date: 2013-10-10 10:25 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/88d3bef80ffc Added tag 8.0-b111 for changeset e6331b4daf15 ! .hgtags Changeset: ff093aa890dd Author: mv157916 Date: 2013-10-11 15:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ff093aa890dd RT-33478: Update the JDK 8 build number to b111 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: d20ce439f1f3 Author: jgodinez Date: 2013-10-15 09:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d20ce439f1f3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/graphics/src/main/java/com/sun/glass/ui/lens/LensCommonDialogs.java - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFImageLoader.java - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFImageMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFStreamMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGImageLoader.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGImageMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGRowFilter.java From hang.vo at oracle.com Tue Oct 15 09:33:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 16:33:06 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28070 : [Embedded][Touch] Move scrollbars 1px away from the border of the pane, from Jindra, reviewed by mickf Message-ID: <20131015163332.3F5A1623F6@hg.openjdk.java.net> Changeset: 658b1ca57a8b Author: mickf Date: 2013-10-15 17:19 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/658b1ca57a8b RT-28070 : [Embedded][Touch] Move scrollbars 1px away from the border of the pane, from Jindra, reviewed by mickf ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/embedded.css ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/touch.css From hang.vo at oracle.com Tue Oct 15 12:18:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 19:18:31 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33203: Regression: incorrect size for OPEN_HAND and CLOSED_HAND cursors on Windows Message-ID: <20131015191910.4423F62403@hg.openjdk.java.net> Changeset: 8346ecdaeb96 Author: kcr Date: 2013-10-15 11:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8346ecdaeb96 RT-33203: Regression: incorrect size for OPEN_HAND and CLOSED_HAND cursors on Windows Reviewed-by: jgodinez Contributed-by: Mo Chicharro ! modules/graphics/src/main/native-glass/win/Hand-Closed.cur ! modules/graphics/src/main/native-glass/win/Hand-Open.cur From pedro.duquevieira at gmail.com Tue Oct 15 14:18:36 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 15 Oct 2013 22:18:36 +0100 Subject: Project Shumway - running swf files without plugins Message-ID: Hi, Mozilla has a project called Shumway - https://github.com/mozilla/shumway. It's basically the same idea as Bck2Brwsr but for flash. Basically people are disappointed with HTML5 which still isn't able to fully compete with Flash and are coming up with stuff like this. Perhaps Oracle could partner with Mozilla to bring Bck2Brwsr to Firefox. I think it would be a great idea and would put pressure on other browsers to take the same steps. Thanks, best regards, -- Pedro Duque Vieira From hang.vo at oracle.com Tue Oct 15 14:17:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 21:17:56 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30158: Investigate String Measurement in FX (cache results, call less, ...) Message-ID: <20131015211849.37F9962418@hg.openjdk.java.net> Changeset: 19834ed34339 Author: Felipe Heidrich Date: 2013-10-15 14:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/19834ed34339 RT-30158: Investigate String Measurement in FX (cache results, call less, ...) Reviewed-By: Steve Northover, Phil Race ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java ! modules/graphics/src/main/java/com/sun/javafx/text/LayoutCache.java ! modules/graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java From hang.vo at oracle.com Tue Oct 15 14:32:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 21:32:52 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33562: Java_com_sun_prism_es2_GLContext_nReadPixelsByte/Int need to check null pointer Message-ID: <20131015213313.6CF866241F@hg.openjdk.java.net> Changeset: 38e7cca64cd7 Author: Yao Wang Date: 2013-10-15 14:28 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/38e7cca64cd7 RT-33562: Java_com_sun_prism_es2_GLContext_nReadPixelsByte/Int need to check null pointer Reviewed-by: kcr, cyang ! modules/graphics/src/main/native-prism-es2/GLContext.c From hjohn at xs4all.nl Tue Oct 15 15:35:23 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 16 Oct 2013 00:35:23 +0200 Subject: Problem with Timeline keeping references around Message-ID: <525DC32B.6050809@xs4all.nl> Hi List, I just submitted https://javafx-jira.kenai.com/browse/RT-33600 which is asking for the Timeline JavaDocs to be more clear on when and where hard references are being created and how to properly clean up after oneself. Most of the docs hardly mention anything when it comes to references causing memory leaks, and Timeline is no exception. However, apart from the docs not really discussing this topic, I actually cannot get proper cleanup to work at all when working with a Timeline. If my Timeline is referencing properties from a StackPane and the Timeline was run atleast once, I cannot figure out how to get this Pane to be gc'd. Calling stop() and even doing getKeyFrames().clear() doesn't help. I'm sure it must be the Timeline because if I remove the KeyFrames that access the StackPane, it will get gc'd properly. If I never run the animation, it also gets gc'd properly. See code below. The System.outs will occur exactly as expected when the StackPane becomes part of the Scene and when it is removed from the Scene. I call stop() on my Timeline and even clear its KeyFrames, but the StackPane refuses to be gc'd (even after hitting the GC button I created for this occasion dozens of times). Not calling playFromStart() or not using the KeyFrames that refer to detailsOverlay.opacityProperty() will solve the problem, and the finalize() System.out will occur usually after the first or second time I press my GC button. Anything else I can try or is this a bug? --John public class PlaybackOverlayPane extends StackPane { private final Timeline fadeInSustainAndFadeOut = new Timeline( new KeyFrame(Duration.seconds(0)), new KeyFrame(Duration.seconds(1), new KeyValue(detailsOverlay.opacityProperty(), 1.0)), new KeyFrame(Duration.seconds(6), new KeyValue(detailsOverlay.opacityProperty(), 1.0)), new KeyFrame(Duration.seconds(9), new KeyValue(detailsOverlay.opacityProperty(), 0.0)) ); private final ChangeListener sceneChangeListener = new ChangeListener() { @Override public void changed(ObservableValue observable, Scene oldValue, Scene newValue) { if(newValue != null) { System.out.println(">>> Starting fadeIn anim"); fadeInSustainAndFadeOut.playFromStart(); } else { System.out.println(">>> Stopping fadeIn anim"); fadeInSustainAndFadeOut.stop(); fadeInSustainAndFadeOut.getKeyFrames().clear(); fadeInSustainAndFadeOut.stop(); } } }; private final GridPane detailsOverlay = GridPaneUtil.create(new double[] {5, 20, 5, 65, 5}, new double[] {45, 50, 5}); ... @Override protected void finalize() throws Throwable { super.finalize(); System.out.println(">>> Finalized " + this); } } From steve.x.northover at oracle.com Tue Oct 15 15:47:51 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Tue, 15 Oct 2013 18:47:51 -0400 Subject: Problem with Timeline keeping references around In-Reply-To: <525DC32B.6050809@xs4all.nl> References: <525DC32B.6050809@xs4all.nl> Message-ID: <525DC617.4020600@oracle.com> This looks like a bug. Timeline should not be holding on to references. Please enter a JIRA. Steve On 2013-10-15 6:35 PM, John Hendrikx wrote: > Hi List, > > I just submitted https://javafx-jira.kenai.com/browse/RT-33600 which > is asking for the Timeline JavaDocs to be more clear on when and where > hard references are being created and how to properly clean up after > oneself. Most of the docs hardly mention anything when it comes to > references causing memory leaks, and Timeline is no exception. > > However, apart from the docs not really discussing this topic, I > actually cannot get proper cleanup to work at all when working with a > Timeline. > > If my Timeline is referencing properties from a StackPane and the > Timeline was run atleast once, I cannot figure out how to get this > Pane to be gc'd. Calling stop() and even doing getKeyFrames().clear() > doesn't help. I'm sure it must be the Timeline because if I remove > the KeyFrames that access the StackPane, it will get gc'd properly. > If I never run the animation, it also gets gc'd properly. > > See code below. The System.outs will occur exactly as expected when > the StackPane becomes part of the Scene and when it is removed from > the Scene. I call stop() on my Timeline and even clear its KeyFrames, > but the StackPane refuses to be gc'd (even after hitting the GC button > I created for this occasion dozens of times). > > Not calling playFromStart() or not using the KeyFrames that refer to > detailsOverlay.opacityProperty() will solve the problem, and the > finalize() System.out will occur usually after the first or second > time I press my GC button. > > Anything else I can try or is this a bug? > --John > > public class PlaybackOverlayPane extends StackPane { > private final Timeline fadeInSustainAndFadeOut = new Timeline( > new KeyFrame(Duration.seconds(0)), > new KeyFrame(Duration.seconds(1), new > KeyValue(detailsOverlay.opacityProperty(), 1.0)), > new KeyFrame(Duration.seconds(6), new > KeyValue(detailsOverlay.opacityProperty(), 1.0)), > new KeyFrame(Duration.seconds(9), new > KeyValue(detailsOverlay.opacityProperty(), 0.0)) > ); > > private final ChangeListener sceneChangeListener = new > ChangeListener() { > @Override > public void changed(ObservableValue observable, > Scene oldValue, Scene newValue) { > if(newValue != null) { > System.out.println(">>> Starting fadeIn anim"); > fadeInSustainAndFadeOut.playFromStart(); > } > else { > System.out.println(">>> Stopping fadeIn anim"); > fadeInSustainAndFadeOut.stop(); > fadeInSustainAndFadeOut.getKeyFrames().clear(); > fadeInSustainAndFadeOut.stop(); > } > } > }; > > private final GridPane detailsOverlay = GridPaneUtil.create(new > double[] {5, 20, 5, 65, 5}, new double[] {45, 50, 5}); > > ... > > @Override > protected void finalize() throws Throwable { > super.finalize(); > System.out.println(">>> Finalized " + this); > } > } From hang.vo at oracle.com Tue Oct 15 16:03:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 15 Oct 2013 23:03:09 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33597: TriangleMeshValidationTest unit test fails on SW pipeline Message-ID: <20131015230403.2911B6242C@hg.openjdk.java.net> Changeset: 477dedf698ed Author: Yao Wang Date: 2013-10-15 15:53 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/477dedf698ed RT-33597: TriangleMeshValidationTest unit test fails on SW pipeline Reviewed-by: kcr ! tests/system/src/test/java/test3d/TriangleMeshValidationTest.java From kevin.rushforth at oracle.com Tue Oct 15 17:45:23 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Oct 2013 17:45:23 -0700 Subject: FX 8 ramp down Message-ID: <525DE1A3.2020001@oracle.com> In order to let community members know what is going on with the bugs, etc., targeted to Lombard (FX 8), here is the current status. We are continuing to ramp-down the FX 8 release in conjunction with the ramp-down of JDK 8. Here are the key dates to be aware of for FX fixes that are going into FX 8: 10/24 - 12/4 : P1 - P3 bugs may be fixed, with code review, but no additional approval needed 12/5 - end of release : Only release-critical bugs may be fixed, release team approval needed This means that any P4 - P5 bugs that are not fixed by 10/23 will be deferred out of FX 8. It also means that any enhancement requests (Tweak or Feature) regardless of priority will likely be deferred out of FX 8. Exceptions will require release team approval, and such approval is unlikely. Note that we are currently using "Van Ness" as a placeholder for both JDK 9 and JDK 8u releases. We will soon be adopting the same release versions as used by the JDK. -- Kevin From hjohn at xs4all.nl Tue Oct 15 17:48:20 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 16 Oct 2013 02:48:20 +0200 Subject: Problem with Timeline keeping references around In-Reply-To: <525DC617.4020600@oracle.com> References: <525DC32B.6050809@xs4all.nl> <525DC617.4020600@oracle.com> Message-ID: <525DE254.8020008@xs4all.nl> I'm having trouble creating a reproducable test case. There seems to be more going on -- if I open and close the Pane involved several times, eventually some of them will start to be GC'd (but never all, unless I disable the animation). I've used VisualVM to inspect the Pane involved, and here is what it says is keeping it alive (clearly something animation related atleast): this - value: hs.mediasystem.screens.playback.PlaybackOverlayPane #1 <- this$0 - class: javafx.scene.Node$8, value: hs.mediasystem.screens.playback.PlaybackOverlayPane #1 <- target - class: com.sun.scenario.animation.shared.InterpolationInterval$DoubleInterpolationInterval, value: javafx.scene.Node$8 #149 <- [0] - class: com.sun.scenario.animation.shared.InterpolationInterval[], value: com.sun.scenario.animation.shared.InterpolationInterval$DoubleInterpolationInterval #28 <- [0] - class: com.sun.scenario.animation.shared.InterpolationInterval[][], value: com.sun.scenario.animation.shared.InterpolationInterval[] #10 (3 items) <- interval - class: com.sun.scenario.animation.shared.GeneralClipInterpolator, value: com.sun.scenario.animation.shared.InterpolationInterval[][] #16 (1 items) <- clipInterpolator - class: com.sun.scenario.animation.shared.TimelineClipCore, value: com.sun.scenario.animation.shared.GeneralClipInterpolator #16 <- clipCore - class: javafx.animation.Timeline, value: com.sun.scenario.animation.shared.TimelineClipCore #19 <- this$0 - class: javafx.animation.Animation$1, value: javafx.animation.Timeline #19 <- [5] - class: com.sun.scenario.animation.shared.PulseReceiver[], value: javafx.animation.Animation$1 #19 <- receivers - class: com.sun.javafx.tk.quantum.MasterTimer, value: com.sun.scenario.animation.shared.PulseReceiver[] #1 (7 items) <- this$0 - class: com.sun.scenario.animation.AbstractMasterTimer$MainLoop, value: com.sun.javafx.tk.quantum.MasterTimer #1 <- animationRunnable - class: com.sun.javafx.tk.quantum.QuantumToolkit, value: com.sun.scenario.animation.AbstractMasterTimer$MainLoop #1 <- this$0 (JNI global) - class: com.sun.javafx.tk.quantum.QuantumToolkit$14, value: com.sun.javafx.tk.quantum.QuantumToolkit #1 If that is enough for a bugreport, I'll create one. A naive simple test case which spawns several panes and animations was unable to reproduce this issue I'm having: package hs.mediasystem; import javafx.animation.KeyFrame; import javafx.animation.KeyValue; import javafx.animation.Timeline; import javafx.application.Application; import javafx.application.Platform; import javafx.beans.value.ChangeListener; import javafx.beans.value.ObservableValue; import javafx.beans.value.WeakChangeListener; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.StackPane; import javafx.stage.Stage; import javafx.util.Duration; public class TimelineGCProblem extends Application { public static void main(String[] args) { Application.launch(args); } @Override public void start(Stage stage) throws Exception { StackPane rootPane = new StackPane(); Scene scene = new Scene(rootPane); stage.setScene(scene); stage.show(); new Thread() { @Override public void run() { for(;;) { Platform.runLater(new Runnable() { @Override public void run() { rootPane.getChildren().setAll(new FadeInPane()); } }); try { System.gc(); Thread.sleep(1500); System.gc(); } catch(InterruptedException e) { e.printStackTrace(); } } } }.start(); } public static class FadeInPane extends StackPane { private final Timeline fadeInSustainAndFadeOut = new Timeline( new KeyFrame(Duration.seconds(0)), new KeyFrame(Duration.seconds(1), new KeyValue(opacityProperty(), 1.0)), new KeyFrame(Duration.seconds(6), new KeyValue(opacityProperty(), 1.0)), new KeyFrame(Duration.seconds(8), new KeyValue(opacityProperty(), 0.0)) ); private final ChangeListener sceneChangeListener = new ChangeListener() { @Override public void changed(ObservableValue observable, Scene oldValue, Scene newValue) { if(newValue != null) { System.out.println(">>> Starting fadeIn anim"); fadeInSustainAndFadeOut.playFromStart(); } else { System.out.println(">>> Stopping fadeIn anim"); fadeInSustainAndFadeOut.stop(); } } }; public FadeInPane() { sceneProperty().addListener(new WeakChangeListener<>(sceneChangeListener)); setStyle("background-color: red"); getChildren().add(new Button("Hi")); } @Override protected void finalize() throws Throwable { super.finalize(); System.out.println("FadeInPane finalized"); } } } --John On 16/10/2013 00:47, Stephen F Northover wrote: > This looks like a bug. Timeline should not be holding on to > references. Please enter a JIRA. > > Steve > > On 2013-10-15 6:35 PM, John Hendrikx wrote: >> Hi List, >> >> I just submitted https://javafx-jira.kenai.com/browse/RT-33600 which >> is asking for the Timeline JavaDocs to be more clear on when and >> where hard references are being created and how to properly clean up >> after oneself. Most of the docs hardly mention anything when it >> comes to references causing memory leaks, and Timeline is no exception. >> >> However, apart from the docs not really discussing this topic, I >> actually cannot get proper cleanup to work at all when working with a >> Timeline. >> >> If my Timeline is referencing properties from a StackPane and the >> Timeline was run atleast once, I cannot figure out how to get this >> Pane to be gc'd. Calling stop() and even doing >> getKeyFrames().clear() doesn't help. I'm sure it must be the >> Timeline because if I remove the KeyFrames that access the StackPane, >> it will get gc'd properly. If I never run the animation, it also >> gets gc'd properly. >> >> See code below. The System.outs will occur exactly as expected when >> the StackPane becomes part of the Scene and when it is removed from >> the Scene. I call stop() on my Timeline and even clear its >> KeyFrames, but the StackPane refuses to be gc'd (even after hitting >> the GC button I created for this occasion dozens of times). >> >> Not calling playFromStart() or not using the KeyFrames that refer to >> detailsOverlay.opacityProperty() will solve the problem, and the >> finalize() System.out will occur usually after the first or second >> time I press my GC button. >> >> Anything else I can try or is this a bug? >> --John >> >> public class PlaybackOverlayPane extends StackPane { >> private final Timeline fadeInSustainAndFadeOut = new Timeline( >> new KeyFrame(Duration.seconds(0)), >> new KeyFrame(Duration.seconds(1), new >> KeyValue(detailsOverlay.opacityProperty(), 1.0)), >> new KeyFrame(Duration.seconds(6), new >> KeyValue(detailsOverlay.opacityProperty(), 1.0)), >> new KeyFrame(Duration.seconds(9), new >> KeyValue(detailsOverlay.opacityProperty(), 0.0)) >> ); >> >> private final ChangeListener sceneChangeListener = new >> ChangeListener() { >> @Override >> public void changed(ObservableValue observable, >> Scene oldValue, Scene newValue) { >> if(newValue != null) { >> System.out.println(">>> Starting fadeIn anim"); >> fadeInSustainAndFadeOut.playFromStart(); >> } >> else { >> System.out.println(">>> Stopping fadeIn anim"); >> fadeInSustainAndFadeOut.stop(); >> fadeInSustainAndFadeOut.getKeyFrames().clear(); >> fadeInSustainAndFadeOut.stop(); >> } >> } >> }; >> >> private final GridPane detailsOverlay = GridPaneUtil.create(new >> double[] {5, 20, 5, 65, 5}, new double[] {45, 50, 5}); >> >> ... >> >> @Override >> protected void finalize() throws Throwable { >> super.finalize(); >> System.out.println(">>> Finalized " + this); >> } >> } > From hang.vo at oracle.com Tue Oct 15 19:18:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 02:18:34 +0000 Subject: hg: openjfx/8/graphics/rt: 16 new changesets Message-ID: <20131016022500.A0B2862434@hg.openjdk.java.net> Changeset: 548a2cec1c7f Author: mhowe Date: 2013-10-15 12:53 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/548a2cec1c7f RT-33393: Mac: standalone app built with packager doesn't start up [ddehaven] ! modules/fxpackager/src/main/native/launcher/mac/main.m Changeset: 30fceec780f7 Author: mhowe Date: 2013-10-15 14:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/30fceec780f7 Merge - modules/graphics/src/main/java/com/sun/glass/ui/lens/LensCommonDialogs.java - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFImageLoader.java - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFImageMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/gif/GIFStreamMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGImageLoader.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGImageMetadata.java - modules/graphics/src/main/java/com/sun/javafx/iio/png/PNGRowFilter.java Changeset: f438aac6de7a Author: Lubomir Nerad Date: 2013-08-09 15:36 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f438aac6de7a Fix for RT-31739: Enhance clipboard clips + modules/graphics/src/main/java/com/sun/javafx/tk/LocalClipboard.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java ! modules/graphics/src/main/java/javafx/scene/input/Clipboard.java Changeset: 2e2146750d09 Author: kcr Date: 2013-08-09 16:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2e2146750d09 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-1304/dev/jfx/rt ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java Changeset: 65d6afd00f90 Author: kcr Date: 2013-08-14 14:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/65d6afd00f90 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java Changeset: 6635bf0e01e7 Author: Artem Ananiev Date: 2013-08-19 19:07 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6635bf0e01e7 RT-32270: Enhance displaying of windows Reviewed-by: Kevin Rushforth, Marc Schonefeld ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassStage.java Changeset: e3ea46ae5101 Author: kcr Date: 2013-08-26 09:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e3ea46ae5101 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 152b0fa2ee73 Author: kcr Date: 2013-08-31 14:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/152b0fa2ee73 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: b3346e91e555 Author: kcr Date: 2013-09-06 15:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b3346e91e555 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 7bae615fd3e2 Author: kcr Date: 2013-09-10 16:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7bae615fd3e2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: e0c944c6d0a9 Author: kcr Date: 2013-09-18 07:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e0c944c6d0a9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 8540379c41b0 Author: kcr Date: 2013-09-27 08:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8540379c41b0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassStage.java Changeset: 856bacc1d3e9 Author: kcr Date: 2013-10-03 18:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/856bacc1d3e9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: a19b6f85332b Author: kcr Date: 2013-10-10 04:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a19b6f85332b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 915737d79cc6 Author: kcr Date: 2013-10-15 16:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/915737d79cc6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java Changeset: eb08481a0c71 Author: kcr Date: 2013-10-15 19:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eb08481a0c71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From kevin.rushforth at oracle.com Tue Oct 15 19:43:27 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 15 Oct 2013 19:43:27 -0700 Subject: Changes for October 2013 CPU release synced into FX 8 Message-ID: <525DFD4F.6020209@oracle.com> Note: I have synced up the pending FX changes from the just-release October 2013 CPU release into FX 8. I also pulled them into the graphics/rt repo. -- Kevin From hang.vo at oracle.com Tue Oct 15 19:52:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 02:52:08 +0000 Subject: hg: openjfx/2u/dev/rt: 30 new changesets Message-ID: <20131016025236.AA59362435@hg.openjdk.java.net> Changeset: e9bc9793d347 Author: hudson Date: 2013-07-02 15:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/e9bc9793d347 Added tag 2.2.45-b01 for changeset d34eb1f7e15d ! .hgtags Changeset: fb9231170967 Author: hudson Date: 2013-07-09 21:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/fb9231170967 Added tag 2.2.45-b02 for changeset e9bc9793d347 ! .hgtags Changeset: a148cf130207 Author: hudson Date: 2013-07-16 10:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/a148cf130207 Added tag 2.2.45-b03 for changeset fb9231170967 ! .hgtags Changeset: c8b10c32d9e5 Author: kcr Date: 2013-07-18 11:01 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/c8b10c32d9e5 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.40/MASTER/jfx/rt ! .hgtags Changeset: 9de698e64a91 Author: hudson Date: 2013-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/9de698e64a91 Added tag 2.2.45-b04 for changeset c8b10c32d9e5 ! .hgtags Changeset: 3739ad4075e9 Author: kcr Date: 2013-07-29 15:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/3739ad4075e9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.40/MASTER/jfx/rt ! .hgtags Changeset: d866c14851eb Author: kcr Date: 2013-07-31 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/d866c14851eb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.40/MASTER/jfx/rt ! .hgtags Changeset: f6b725b6db13 Author: hudson Date: 2013-08-01 09:30 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/f6b725b6db13 Added tag 2.2.45-b05 for changeset d866c14851eb ! .hgtags Changeset: 46e018bddc3f Author: kcr Date: 2013-08-07 12:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/46e018bddc3f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.40/MASTER/jfx/rt ! .hgtags Changeset: 073e36862313 Author: hudson Date: 2013-08-08 11:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/073e36862313 Added tag 2.2.45-b06 for changeset 46e018bddc3f ! .hgtags Changeset: a6e335804e80 Author: Lubomir Nerad Date: 2013-08-09 09:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/a6e335804e80 Fix for RT-31739: Enhance clipboard clips + javafx-ui-common/src/com/sun/javafx/tk/LocalClipboard.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/input/Clipboard.java Changeset: 5bc50b0916b5 Author: kcr Date: 2013-08-09 14:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/5bc50b0916b5 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.45/MASTER/jfx/rt Changeset: e23e4054e61b Author: kcr Date: 2013-08-14 12:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/e23e4054e61b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.40/MASTER/jfx/rt ! .hgtags Changeset: a9c11d0c5266 Author: hudson Date: 2013-08-15 07:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/a9c11d0c5266 Added tag 2.2.45-b07 for changeset e23e4054e61b ! .hgtags Changeset: 7865113cdb2b Author: kcr Date: 2013-08-19 11:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/7865113cdb2b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.40/MASTER/jfx/rt ! .hgtags Changeset: fc1760c5e1b3 Author: hudson Date: 2013-08-20 10:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/fc1760c5e1b3 Added tag 2.2.45-b08 for changeset 7865113cdb2b ! .hgtags Changeset: 5c4a0e47513f Author: kcr Date: 2013-08-26 08:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/5c4a0e47513f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.40/MASTER/jfx/rt ! .hgtags Changeset: 77b43ce86e20 Author: hudson Date: 2013-08-27 08:15 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/77b43ce86e20 Added tag 2.2.45-b09 for changeset 9d70678d42d2 ! .hgtags Changeset: fc2f6ee296f9 Author: kcr Date: 2013-08-31 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/fc2f6ee296f9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.40/MASTER/jfx/rt ! .hgtags Changeset: c76ec783536b Author: hudson Date: 2013-09-02 10:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/c76ec783536b Added tag 2.2.45-b09 for changeset 5c4a0e47513f ! .hgtags Changeset: 5da35d9dcfb7 Author: hudson Date: 2013-09-04 11:31 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/5da35d9dcfb7 Added tag 2.2.45-b10 for changeset c76ec783536b ! .hgtags Changeset: a8d22fe9d780 Author: hudson Date: 2013-09-11 09:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/a8d22fe9d780 Added tag 2.2.45-b11 for changeset 5da35d9dcfb7 ! .hgtags Changeset: c5e4c706d491 Author: hudson Date: 2013-09-17 21:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/c5e4c706d491 Added tag 2.2.45-b12 for changeset a8d22fe9d780 ! .hgtags Changeset: 996fe54459c9 Author: hudson Date: 2013-09-23 07:59 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/996fe54459c9 Added tag 2.2.45-b13 for changeset c5e4c706d491 ! .hgtags Changeset: e902993889f3 Author: hudson Date: 2013-09-26 07:14 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/e902993889f3 Added tag 2.2.45-b14 for changeset 996fe54459c9 ! .hgtags Changeset: ba64e43a17af Author: hudson Date: 2013-09-27 07:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/ba64e43a17af Added tag 2.2.45-b15 for changeset e902993889f3 ! .hgtags Changeset: 4b0151651241 Author: hudson Date: 2013-10-02 20:28 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/4b0151651241 Added tag 2.2.45-b16 for changeset ba64e43a17af ! .hgtags Changeset: 28bf72b54f55 Author: hudson Date: 2013-10-07 22:19 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/28bf72b54f55 Added tag 2.2.45-b17 for changeset 4b0151651241 ! .hgtags Changeset: 36b33d09b274 Author: hudson Date: 2013-10-08 11:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/36b33d09b274 Added tag 2.2.45-b18 for changeset 28bf72b54f55 ! .hgtags Changeset: 8fd11d02dec6 Author: kcr Date: 2013-10-15 15:59 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/8fd11d02dec6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.45/MASTER/jfx/rt From hang.vo at oracle.com Wed Oct 16 00:33:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 07:33:17 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31084 Some Table Cells are blank when column is made visible. Message-ID: <20131016073339.F26156244C@hg.openjdk.java.net> Changeset: 0f8099895353 Author: Martin Sladecek Date: 2013-10-16 09:28 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0f8099895353 RT-31084 Some Table Cells are blank when column is made visible. Reviewed-by:jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkinBase.java From hang.vo at oracle.com Wed Oct 16 00:47:48 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 07:47:48 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33265 fx:script not loading file defined in the source attribute in JDK8 Message-ID: <20131016074803.E13E96244D@hg.openjdk.java.net> Changeset: e56c8f6f8228 Author: Martin Sladecek Date: 2013-10-16 09:41 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e56c8f6f8228 RT-33265 fx:script not loading file defined in the source attribute in JDK8 + Also enabled FXML event tests that were accidentaly not running (the class didn't have Test suffix) + Fixed one event issue - when handler() and handler(event) were both presen in controller for property handlers Reviewed-by: ekrejcir, kcr ! build.gradle ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java + modules/fxml/src/test/java/javafx/fxml/FXMLLoader_EventsTest.java + modules/fxml/src/test/java/javafx/fxml/FXMLLoader_ScriptTest.java - modules/fxml/src/test/java/javafx/fxml/FXMLLoader_events.java - modules/fxml/src/test/java/javafx/fxml/RT_18046Test.java ! modules/fxml/src/test/java/javafx/fxml/Widget.java ! modules/fxml/src/test/resources/javafx/fxml/events_test.fxml - modules/fxml/src/test/resources/javafx/fxml/rt_18046.fxml + modules/fxml/src/test/resources/javafx/fxml/script_handler.fxml + modules/fxml/src/test/resources/javafx/fxml/script_handler_external.fxml + modules/fxml/src/test/resources/javafx/fxml/script_handler_external.js + modules/fxml/src/test/resources/javafx/fxml/static_script_load.fxml From pavel.safrata at oracle.com Wed Oct 16 01:04:27 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 16 Oct 2013 10:04:27 +0200 Subject: Half-baked API (Camera position) Message-ID: <525E488B.40105@oracle.com> Hello, it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough time&priority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a "known limitation". 2. PickResult on events which reports "intersectedDistance" between the camera and the picked point. This is worse because we can't just "not support" it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes "in front of Z=-1" it reports negative distances). This may change when the camera position is properly discussed and specified. Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the "intersectedDistance" in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? Thanks, Pavel From haenel at ultramixer.com Wed Oct 16 01:59:34 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Wed, 16 Oct 2013 10:59:34 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <525D48B6.1040907@oracle.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> <525BE40D.6090808@oracle.com> <7F87527D-8E3C-4231-B7DE-3D837F75DE75@ultramixer.com> <525D48B6.1040907@oracle.com> Message-ID: <9F70925E-5B11-4EDB-BD73-CAA8DE3C41A0@ultramixer.com> Hi Tomas, thanks for your patch. Your way doesn't seem to be so different to the jfx78 approach except the retro-stuff ;) In the meanwhile I am pretty sure, this will not be entirely needed since DAVLIK can run java7 class code. Nevertheless, I tried your patch... Patching works. After adapting some files and putting the correct pathes in the configuration I got the gradle script working. Unfortunatly, I used the tip of openjfx8. That means there is a lot of new stuff e.g. usage of Function.java that's required from jdk8. Which tag did you use? B111 or are you on the cutting edge at tip? I'll try B111 from master hopefully this new stuff isn't in there ;) It looks like porting Function.java back to java7 is not so easy. regards Matthias Am 15.10.2013 um 15:52 schrieb tomas.brandalik : > Hi Matthias, > you are right when I build for dalvik I build with a flag DALVIK_VM. > Pls be careful when building changes in native code you have to do clean build. There is still an issue in jfx gradle script. > I create my build differently. I start with openjfx patch it to be jdk7 compatible then use retrolambda to replace class file versions to jdk6. > If you want give it a try use attached patch and do following: > clone openjfx > cd rt > patch -p1 < fix_jdk7_compat.patch > edit android-build.sh with your paths > android-build.sh retrojfxrt > > iI will build dalvik compatible jfxrt6.jar > > -Tomas > > On 10/15/2013 03:07 PM, Matthias H?nel wrote: >> Hi Tomas, >> >> >> I couldn't stand to merge it by hand ;) I merged the changes from RT-32802 into my backport. >> >> Unfortunately, it still crashes: >> >> 10-15 08:59:47.182: INFO/GLASS(3644): JNI call notifyTouchEvent >> 10-15 08:59:47.202: INFO/GLASS(3644): Window 1[0x2a41a138] isVisible=true, state=NORMAL >> 10-15 08:59:47.202: INFO/GLASS(3644): Absolute coordinates 542,414 are on window 1[0x2a41a138] as relative coordinates 670,292 >> 10-15 08:59:47.202: INFO/GLASS(3644): Returning focused window 1[0x2a41a138] >> 10-15 08:59:47.202: ERROR/dalvikvm(3644): ERROR: detaching thread with interp frames (count=42) >> 10-15 08:59:47.213: INFO/dalvikvm(3644): "main" prio=5 tid=1 RUNNABLE >> 10-15 08:59:47.213: INFO/dalvikvm(3644): | group="main" sCount=0 dsCount=0 obj=0x414c5578 self=0x2a00d090 >> 10-15 08:59:47.222: INFO/dalvikvm(3644): | sysTid=3644 nice=0 sched=0/0 cgrp=apps handle=1073811452 >> 10-15 08:59:47.222: INFO/dalvikvm(3644): | state=R schedstat=( 6545290672 1534059118 8044 ) utm=610 stm=44 core=0 >> 10-15 08:59:47.252: INFO/dalvikvm(3644): at com.oracle.dalvik.FXActivity$InternalSurfaceView.onMultiTouchEventNative(Native Method) >> 10-15 08:59:47.252: INFO/dalvikvm(3644): at com.oracle.dalvik.FXActivity$InternalSurfaceView.dispatchTouchEvent(FXActivity.java:234) >> >> Do you have any idea? >> The error "ERROR: detaching thread with interp frames (count=42)" seems to be a thread attach/detach mistake >> in the code. In androidLens.c there is some ATTACH_JNI_THREAD and DTACH_JNI_THREAD code. >> There are two implementations. One that's filled with (*vm)-> and the other one is left blank. >> Currently, the macro DALVI_VM is not defined, so the code is filled. This seems to be odd to me. >> Actually, I tried defining DAVLIK_VM but it doesn't help. It still crashes with the sme error. >> >> >> regards >> Matthais >> >> >> Am 14.10.2013 um 14:31 schrieb tomas.brandalik : >> >>> Hi Matthias, >>> cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA8888 in emulator. But that could have changed overtime. >>> Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. >>> In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. >>> >>> good luck >>> -Tomas >>> >>> On 10/14/2013 01:45 PM, Matthias H?nel wrote: >>>> Hi Tomas, >>>> >>>> >>>> never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. >>>> >>>> So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. >>>> >>>> There are two things missing: >>>> 1. fonts - here we probably need to get pango working for Android right? >>>> 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative >>>> This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. >>>> >>>> After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. >>>> >>>> >>>> kind regards >>>> Matthias >>>> >>>> >>>> >>>> Am 14.10.2013 um 12:17 schrieb Matthias H?nel : >>>> >>>>> Hi Tomas, >>>>> >>>>> >>>>> since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. >>>>> We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. >>>>> >>>>> 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin >>>>> 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. >>>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) >>>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) >>>>> 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>>> 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException >>>>> 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) >>>>> 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) >>>>> 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms >>>>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) >>>>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) >>>>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) >>>>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) >>>>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) >>>>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) >>>>> 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) >>>>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) >>>>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) >>>>> 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) >>>>> 10-14 06:06:49.719: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) >>>>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) >>>>> 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>>>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) >>>>> 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) >>>>> 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) >>>>> 10-14 06:06:49.729: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) >>>>> 10-14 06:06:49.729: WARN/System.err(1546): Caused by: java.lang.RuntimeException: Error creating vertex shader >>>>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:132) >>>>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:173) >>>>> 10-14 06:06:49.740: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createShader(ES2ResourceFactory.java:168) >>>>> 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.shader.Texture_Color_Loader.loadShader(Texture_Color_Loader.java:47) >>>>> 10-14 06:06:49.749: WARN/System.err(1546): ... 19 more >>>>> 10-14 06:06:49.749: WARN/System.err(1546): java.lang.InternalError: Error loading stock shader Texture_Color >>>>> 10-14 06:06:49.749: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:256) >>>>> 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) >>>>> 10-14 06:06:49.759: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) >>>>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) >>>>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) >>>>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) >>>>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) >>>>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) >>>>> 10-14 06:06:49.769: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) >>>>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) >>>>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) >>>>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) >>>>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) >>>>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) >>>>> 10-14 06:06:49.779: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) >>>>> 10-14 06:06:49.779: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) >>>>> 10-14 06:06:49.779: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) >>>>> 10-14 06:06:49.779: INFO/GLASS(1546): glass_view_drawEnd >>>>> >>>>> >>>>> I track the error down to, compileShader in ES2Shader.java on line 130. This is returning 0 from native code. >>>>> The native codes looks okay for me and the Android Simulator is supposed to emulate OpenGL ES 2.0 correclty, so I am not sure >>>>> why the compileShader returns 0... >>>>> >>>>> int vertexShaderID = glCtx.compileShader(vert, true); >>>>> if (vertexShaderID == 0) { >>>>> throw new RuntimeException("Error creating vertex shader"); //<<--- this Exception occours. >>>>> } >>>>> >>>>> I know this is the common error from the shader compiler, but this should have worked for you, >>>>> when you started your own application. Do you have a hint, what I could have been done wrong? >>>>> >>>>> I assume right now that the native build is correctly, since it is called from java and it does >>>>> return the correct EGLContext. This assumption might be wrong. >>>>> >>>>> >>>>> regards >>>>> Matthias >>>>> >>>>> >>>>> >>>>> >>>>> Am 12.10.2013 um 14:04 schrieb Tomas Brandalik : >>>>> >>>>>> I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. >>>>>> >>>>>> -Tomas >>>>>> >>>>>> >>>>>> On 10/11/2013 06:22 PM, Tom Schindl wrote: >>>>>>> On 11.10.13 18:10, Matthias H?nel wrote: >>>>>>>> Hi Tomas, >>>>>>>> >>>>>>>> >>>>>>>> today, I took the time to investigate a little more time on this. >>>>>>>> >>>>>>>> 1. I build an entirely new openjfx78 build for android >>>>>>>> 2. starting this gave me several errors that lead me to the >>>>>>>> conclusion that I need a java6 openjfx >>>>>>>> 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) >>>>>>>> 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper >>>>>>>> is called with a static call to createStyleHelper. >>>>>>>> >>>>>>>> That looks like the font stuff is not in jfx78. That's why "new Font" returns with null and therefore >>>>>>> On OS-X font stuff is definately there in jfx78, but the low-level font >>>>>>> stuff is loaded using reflection (at least this was the cause on robovm)! >>>>>>> >>>>>>> Tom > > From eva.krejcirova at oracle.com Wed Oct 16 02:22:20 2013 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 16 Oct 2013 11:22:20 +0200 Subject: Constructor annotation Message-ID: <525E5ACC.1030103@oracle.com> Hi All, when we retired builders, we caused a problem for FXML which doesn't have a way to create classes without default constructors. Back then we decided to use an annotation for this but never actually got to implement it and we need to fix this for FX8. I am in the process of adding this functionality to FXMLLoader but we need to decide how the annotation will look like and I could use some help with this. We cannot use already existing ConstructorProperties for this, because it's java.beans package and we don't want to create to dependency on this package in JavaFX, so we need to introduce a new annotation. We have two options: 1. Annotate the whole constructor: e.g. @ConstructorArguments({"a", "b", "list"}) public ImmutableClass(int a, int b, Integer... list) 2. Annotate the arguments: e.g. public ImmutableClass(@FXMLArgument("a") int a, @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) Which option do you like more and how should the annotation be named? Thanks, Eva From tbee at tbee.org Wed Oct 16 02:26:18 2013 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 16 Oct 2013 11:26:18 +0200 Subject: Constructor annotation In-Reply-To: <525E5ACC.1030103@oracle.com> References: <525E5ACC.1030103@oracle.com> Message-ID: <525E5BBA.7010704@tbee.org> Would the duality of using the parameter info when available or else the annotation (2nd option) be an viable approach? Tom On 2013-10-16 11:22, Eva Krejcirova wrote: > Hi All, > > when we retired builders, we caused a problem for FXML which doesn't have a way to create classes without default constructors. Back then we decided to use an annotation for this but never actually got to implement it and we need to fix this for FX8. I am in the process of adding this functionality to FXMLLoader but we need to decide how the annotation will look like and I could use some help with this. > > We cannot use already existing ConstructorProperties for this, because it's java.beans package and we don't want to create to dependency on this package in JavaFX, so we need to introduce a new annotation. > > We have two options: > > 1. Annotate the whole constructor: > e.g. > @ConstructorArguments({"a", "b", "list"}) > public ImmutableClass(int a, int b, Integer... list) > > 2. Annotate the arguments: > e.g. > public ImmutableClass(@FXMLArgument("a") int a, @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) > > > Which option do you like more and how should the annotation be named? > > Thanks, > Eva From Claus.Luethje at osys.ch Wed Oct 16 03:26:12 2013 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Wed, 16 Oct 2013 10:26:12 +0000 Subject: Constructor annotation In-Reply-To: <525E5ACC.1030103@oracle.com> References: <525E5ACC.1030103@oracle.com> Message-ID: <193FF4ED343AF14F8CDC65B4792C954D23BF0479@Jeri.osys.ch> Hi I'd prefer the second option, because the correlation of the order of arguments in the annotation and in the constructors parameters is irritating and error prone. The way it is structured in option two is seen elsewhere also. So, nothing new to learn/absorb. @FXMLArgument is a useful name to describe what's going on. My 2 cents... Regards Claus -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Eva Krejcirova Sent: Mittwoch, 16. Oktober 2013 11:22 To: openjfx-dev at openjdk.java.net Subject: Constructor annotation Hi All, when we retired builders, we caused a problem for FXML which doesn't have a way to create classes without default constructors. Back then we decided to use an annotation for this but never actually got to implement it and we need to fix this for FX8. I am in the process of adding this functionality to FXMLLoader but we need to decide how the annotation will look like and I could use some help with this. We cannot use already existing ConstructorProperties for this, because it's java.beans package and we don't want to create to dependency on this package in JavaFX, so we need to introduce a new annotation. We have two options: 1. Annotate the whole constructor: e.g. @ConstructorArguments({"a", "b", "list"}) public ImmutableClass(int a, int b, Integer... list) 2. Annotate the arguments: e.g. public ImmutableClass(@FXMLArgument("a") int a, @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) Which option do you like more and how should the annotation be named? Thanks, Eva From jack at moxley.co.uk Wed Oct 16 04:12:53 2013 From: jack at moxley.co.uk (Jack Moxley) Date: Wed, 16 Oct 2013 12:12:53 +0100 Subject: Constructor annotation In-Reply-To: <193FF4ED343AF14F8CDC65B4792C954D23BF0479@Jeri.osys.ch> Message-ID: <20131016111253.8ba6c953@mailgate.office.moxley.co.uk> I would prefer @FXMLConstructor and for the names of the parameters to be automagicaly detected and linked, and then an optional @FXMLArgument to allow us to specify if the actual name deviates from the name of the parameter. I understand this can be an issue, as parameter names are not retained, but we can fetch either from the debugging symbols, or at compile time. _____ From: Claus Luethje [mailto:Claus.Luethje at osys.ch] To: Eva Krejcirova [mailto:eva.krejcirova at oracle.com], openjfx-dev at openjdk.java.net [mailto:openjfx-dev at openjdk.java.net] Sent: Wed, 16 Oct 2013 11:26:12 +0000 Subject: RE: Constructor annotation Hi I'd prefer the second option, because the correlation of the order of arguments in the annotation and in the constructors parameters is irritating and error prone. The way it is structured in option two is seen elsewhere also. So, nothing new to learn/absorb. @FXMLArgument is a useful name to describe what's going on. My 2 cents... Regards Claus -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Eva Krejcirova Sent: Mittwoch, 16. Oktober 2013 11:22 To: openjfx-dev at openjdk.java.net Subject: Constructor annotation Hi All, when we retired builders, we caused a problem for FXML which doesn't have a way to create classes without default constructors. Back then we decided to use an annotation for this but never actually got to implement it and we need to fix this for FX8. I am in the process of adding this functionality to FXMLLoader but we need to decide how the annotation will look like and I could use some help with this. We cannot use already existing ConstructorProperties for this, because it's java.beans package and we don't want to create to dependency on this package in JavaFX, so we need to introduce a new annotation. We have two options: 1. Annotate the whole constructor: e.g. @ConstructorArguments({"a", "b", "list"}) public ImmutableClass(int a, int b, Integer... list) 2. Annotate the arguments: e.g. public ImmutableClass(@FXMLArgument("a") int a, @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) Which option do you like more and how should the annotation be named? Thanks, Eva From eva.krejcirova at oracle.com Wed Oct 16 04:18:15 2013 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 16 Oct 2013 13:18:15 +0200 Subject: Constructor annotation In-Reply-To: <20131016111253.8ba6c953@mailgate.office.moxley.co.uk> References: <20131016111253.8ba6c953@mailgate.office.moxley.co.uk> Message-ID: <525E75F7.8050900@oracle.com> Hi Jack, On 16.10.2013 13:12, Jack Moxley wrote: > I would prefer @FXMLConstructor and for the names of the parameters to > be automagicaly detected and linked, and then an optional > @FXMLArgument to allow us to specify if the actual name deviates from > the name of the parameter. > > I understand this can be an issue, as parameter names are not > retained, but we can fetch either from the debugging symbols, or at > compile time. This would be nice, but I don't think that it's feasible in FX8 time frame, unfortunately. Eva > ------------------------------------------------------------------------ > *From:* Claus Luethje [mailto:Claus.Luethje at osys.ch] > *To:* Eva Krejcirova [mailto:eva.krejcirova at oracle.com], > openjfx-dev at openjdk.java.net [mailto:openjfx-dev at openjdk.java.net] > *Sent:* Wed, 16 Oct 2013 11:26:12 +0000 > *Subject:* RE: Constructor annotation > > Hi > I'd prefer the second option, because the correlation of the order > of arguments in the annotation and in the constructors parameters > is irritating and error prone. > The way it is structured in option two is seen elsewhere also. So, > nothing new to learn/absorb. > @FXMLArgument is a useful name to describe what's going on. > My 2 cents... > Regards > Claus > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > > [mailto:openjfx-dev-bounces at openjdk.java.net > ] On Behalf Of Eva > Krejcirova > Sent: Mittwoch, 16. Oktober 2013 11:22 > To: openjfx-dev at openjdk.java.net > Subject: Constructor annotation > > Hi All, > > when we retired builders, we caused a problem for FXML which > doesn't have a way to create classes without default constructors. > Back then we decided to use an annotation for this but never > actually got to implement it and we need to fix this for FX8. I am > in the process of adding this functionality to FXMLLoader but we > need to decide how the annotation will look like and I could use > some help with this. > > We cannot use already existing ConstructorProperties for this, > because it's java.beans package and we don't want to create to > dependency on this package in JavaFX, so we need to introduce a > new annotation. > > We have two options: > > 1. Annotate the whole constructor: > e.g. > @ConstructorArguments({"a", "b", "list"}) > public ImmutableClass(int a, int b, Integer... list) > > 2. Annotate the arguments: > e.g. > public ImmutableClass(@FXMLArgument("a") int a, > @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) > > > Which option do you like more and how should the annotation be named? > > Thanks, > Eva > From tom.schindl at bestsolution.at Wed Oct 16 04:20:20 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 16 Oct 2013 13:20:20 +0200 Subject: Constructor annotation In-Reply-To: <525E5ACC.1030103@oracle.com> References: <525E5ACC.1030103@oracle.com> Message-ID: <525E7674.9040108@bestsolution.at> On 16.10.13 11:22, Eva Krejcirova wrote: > Hi All, > > when we retired builders, we caused a problem for FXML which doesn't > have a way to create classes without default constructors. Back then we > decided to use an annotation for this but never actually got to > implement it and we need to fix this for FX8. I am in the process of > adding this functionality to FXMLLoader but we need to decide how the > annotation will look like and I could use some help with this. > > We cannot use already existing ConstructorProperties for this, because > it's java.beans package and we don't want to create to dependency on > this package in JavaFX, so we need to introduce a new annotation. > > We have two options: > > 1. Annotate the whole constructor: > e.g. > @ConstructorArguments({"a", "b", "list"}) > public ImmutableClass(int a, int b, Integer... list) > > 2. Annotate the arguments: > e.g. > public ImmutableClass(@FXMLArgument("a") int a, > @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) > > > Which option do you like more and how should the annotation be named? Option 2, but does it really have to hold FXML in the annotation name? Where would you put the annotation? I think it should NOT be in the FXML-Package-Namespace because the core should NOT depend on FXML! I'd go with @Argument or simply @NamedArgument (@Named is already used by javax.inject) Tom From hang.vo at oracle.com Wed Oct 16 04:18:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 11:18:27 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33605 Message-ID: <20131016112020.7422A62457@hg.openjdk.java.net> Changeset: 6a30ae549629 Author: Martin Sladecek Date: 2013-10-16 13:11 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6a30ae549629 RT-33605 Timeline prevents objects that are animated to be gc'ed Reviewed-by: ekrejcir ! modules/graphics/src/main/java/com/sun/scenario/animation/AbstractMasterTimer.java From hang.vo at oracle.com Wed Oct 16 06:33:14 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 13:33:14 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33607 correct warnings about redefining __USE_GNU Message-ID: <20131016133425.DF9B66245E@hg.openjdk.java.net> Changeset: 6626ff47763a Author: ddhill Date: 2013-10-16 09:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6626ff47763a RT-33607 correct warnings about redefining __USE_GNU reviewer: kcr ! modules/graphics/src/main/native-prism-es2/PrismES2Defs.h From eva.krejcirova at oracle.com Wed Oct 16 06:49:43 2013 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 16 Oct 2013 15:49:43 +0200 Subject: Constructor annotation In-Reply-To: <525E5BBA.7010704@tbee.org> References: <525E5ACC.1030103@oracle.com> <525E5BBA.7010704@tbee.org> Message-ID: <525E9977.7080601@oracle.com> On 16.10.2013 11:26, Tom Eugelink wrote: > > Would the duality of using the parameter info when available or else > the annotation (2nd option) be an viable approach? This is probably doable but I am not sure whether we want to turn on the parameter info for the whole JavaFX - last time I checked it was not possible to specify that we need it only for constructors, so the class files then contain names of arguments of all methods even if we don't need them. Eva > > Tom > > > On 2013-10-16 11:22, Eva Krejcirova wrote: >> Hi All, >> >> when we retired builders, we caused a problem for FXML which doesn't >> have a way to create classes without default constructors. Back then >> we decided to use an annotation for this but never actually got to >> implement it and we need to fix this for FX8. I am in the process of >> adding this functionality to FXMLLoader but we need to decide how the >> annotation will look like and I could use some help with this. >> >> We cannot use already existing ConstructorProperties for this, >> because it's java.beans package and we don't want to create to >> dependency on this package in JavaFX, so we need to introduce a new >> annotation. >> >> We have two options: >> >> 1. Annotate the whole constructor: >> e.g. >> @ConstructorArguments({"a", "b", "list"}) >> public ImmutableClass(int a, int b, Integer... list) >> >> 2. Annotate the arguments: >> e.g. >> public ImmutableClass(@FXMLArgument("a") int a, >> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >> >> >> Which option do you like more and how should the annotation be named? >> >> Thanks, >> Eva > > From richard.bair at oracle.com Wed Oct 16 07:36:05 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 16 Oct 2013 07:36:05 -0700 Subject: Constructor annotation In-Reply-To: <525E7674.9040108@bestsolution.at> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> Message-ID: <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> +1 this is my preference. It is useful for things other than FXML, and should be considered part of our javafx.beans API. > On Oct 16, 2013, at 4:20 AM, Tom Schindl wrote: > >> On 16.10.13 11:22, Eva Krejcirova wrote: >> Hi All, >> >> when we retired builders, we caused a problem for FXML which doesn't >> have a way to create classes without default constructors. Back then we >> decided to use an annotation for this but never actually got to >> implement it and we need to fix this for FX8. I am in the process of >> adding this functionality to FXMLLoader but we need to decide how the >> annotation will look like and I could use some help with this. >> >> We cannot use already existing ConstructorProperties for this, because >> it's java.beans package and we don't want to create to dependency on >> this package in JavaFX, so we need to introduce a new annotation. >> >> We have two options: >> >> 1. Annotate the whole constructor: >> e.g. >> @ConstructorArguments({"a", "b", "list"}) >> public ImmutableClass(int a, int b, Integer... list) >> >> 2. Annotate the arguments: >> e.g. >> public ImmutableClass(@FXMLArgument("a") int a, >> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >> >> >> Which option do you like more and how should the annotation be named? > > Option 2, but does it really have to hold FXML in the annotation name? > Where would you put the annotation? I think it should NOT be in the > FXML-Package-Namespace because the core should NOT depend on FXML! > > I'd go with @Argument or simply @NamedArgument (@Named is already used > by javax.inject) > > Tom From richard.bair at oracle.com Wed Oct 16 07:46:02 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 16 Oct 2013 07:46:02 -0700 Subject: Half-baked API (Camera position) In-Reply-To: <525E488B.40105@oracle.com> References: <525E488B.40105@oracle.com> Message-ID: My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. > On Oct 16, 2013, at 1:04 AM, Pavel Safrata wrote: > > Hello, > it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough time&priority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: > > 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a "known limitation". > > 2. PickResult on events which reports "intersectedDistance" between the camera and the picked point. This is worse because we can't just "not support" it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes "in front of Z=-1" it reports negative distances). This may change when the camera position is properly discussed and specified. > > Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. > > So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the "intersectedDistance" in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? > > Thanks, > Pavel From richard.bair at oracle.com Wed Oct 16 07:52:48 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 16 Oct 2013 07:52:48 -0700 Subject: Problem with Timeline keeping references around In-Reply-To: <525DE254.8020008@xs4all.nl> References: <525DC32B.6050809@xs4all.nl> <525DC617.4020600@oracle.com> <525DE254.8020008@xs4all.nl> Message-ID: <50ADD878-4384-4AB8-811F-1A53AFBB98F4@oracle.com> I saw some fix go flying by this morning, check the changelog on graphics and see if there is a fix. Cheers Richard From kevin.rushforth at oracle.com Wed Oct 16 07:53:31 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Oct 2013 07:53:31 -0700 Subject: Constructor annotation In-Reply-To: <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> Message-ID: <525EA86B.2090208@oracle.com> Not to mention Tom's point that it can't be in the fxml module without created unwanted (and circular) module dependencies. Seems like it needs to be in the "base" module then, right? -- Kevin Richard Bair wrote: > +1 this is my preference. It is useful for things other than FXML, and should be considered part of our javafx.beans API. > > >> On Oct 16, 2013, at 4:20 AM, Tom Schindl wrote: >> >> >>> On 16.10.13 11:22, Eva Krejcirova wrote: >>> Hi All, >>> >>> when we retired builders, we caused a problem for FXML which doesn't >>> have a way to create classes without default constructors. Back then we >>> decided to use an annotation for this but never actually got to >>> implement it and we need to fix this for FX8. I am in the process of >>> adding this functionality to FXMLLoader but we need to decide how the >>> annotation will look like and I could use some help with this. >>> >>> We cannot use already existing ConstructorProperties for this, because >>> it's java.beans package and we don't want to create to dependency on >>> this package in JavaFX, so we need to introduce a new annotation. >>> >>> We have two options: >>> >>> 1. Annotate the whole constructor: >>> e.g. >>> @ConstructorArguments({"a", "b", "list"}) >>> public ImmutableClass(int a, int b, Integer... list) >>> >>> 2. Annotate the arguments: >>> e.g. >>> public ImmutableClass(@FXMLArgument("a") int a, >>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>> >>> >>> Which option do you like more and how should the annotation be named? >>> >> Option 2, but does it really have to hold FXML in the annotation name? >> Where would you put the annotation? I think it should NOT be in the >> FXML-Package-Namespace because the core should NOT depend on FXML! >> >> I'd go with @Argument or simply @NamedArgument (@Named is already used >> by javax.inject) >> >> Tom >> From kevin.rushforth at oracle.com Wed Oct 16 07:57:07 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Oct 2013 07:57:07 -0700 Subject: Half-baked API (Camera position) In-Reply-To: References: <525E488B.40105@oracle.com> Message-ID: <525EA943.1060006@oracle.com> Regarding #2, I'm OK with an exception being thrown. Regarding #1, do you think moving the clip planes to PerspectiveCamera (rather than in the base class) be better for FX 8? We can compatibly move it up to a superclass in a future release. Or would this be too disruptive? -- Kevin Richard Bair wrote: > My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. > > >> On Oct 16, 2013, at 1:04 AM, Pavel Safrata wrote: >> >> Hello, >> it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough time&priority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: >> >> 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a "known limitation". >> >> 2. PickResult on events which reports "intersectedDistance" between the camera and the picked point. This is worse because we can't just "not support" it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes "in front of Z=-1" it reports negative distances). This may change when the camera position is properly discussed and specified. >> >> Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. >> >> So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the "intersectedDistance" in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? >> >> Thanks, >> Pavel >> From steve.x.northover at oracle.com Wed Oct 16 07:58:37 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 16 Oct 2013 10:58:37 -0400 Subject: Constructor annotation In-Reply-To: <525EA86B.2090208@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> Message-ID: <525EA99D.4090605@oracle.com> +1 for base. Should we not follow closely what Java Beans is doing for consistency? I realize that we can't have the reference. Steve On 2013-10-16 10:53 AM, Kevin Rushforth wrote: > Not to mention Tom's point that it can't be in the fxml module without > created unwanted (and circular) module dependencies. Seems like it > needs to be in the "base" module then, right? > > -- Kevin > > > Richard Bair wrote: >> +1 this is my preference. It is useful for things other than FXML, >> and should be considered part of our javafx.beans API. >> >>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>> wrote: >>> >>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>> Hi All, >>>> >>>> when we retired builders, we caused a problem for FXML which doesn't >>>> have a way to create classes without default constructors. Back >>>> then we >>>> decided to use an annotation for this but never actually got to >>>> implement it and we need to fix this for FX8. I am in the process of >>>> adding this functionality to FXMLLoader but we need to decide how the >>>> annotation will look like and I could use some help with this. >>>> >>>> We cannot use already existing ConstructorProperties for this, because >>>> it's java.beans package and we don't want to create to dependency on >>>> this package in JavaFX, so we need to introduce a new annotation. >>>> >>>> We have two options: >>>> >>>> 1. Annotate the whole constructor: >>>> e.g. >>>> @ConstructorArguments({"a", "b", "list"}) >>>> public ImmutableClass(int a, int b, Integer... list) >>>> >>>> 2. Annotate the arguments: >>>> e.g. >>>> public ImmutableClass(@FXMLArgument("a") int a, >>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>> >>>> >>>> Which option do you like more and how should the annotation be named? >>> Option 2, but does it really have to hold FXML in the annotation name? >>> Where would you put the annotation? I think it should NOT be in the >>> FXML-Package-Namespace because the core should NOT depend on FXML! >>> >>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>> by javax.inject) >>> >>> Tom From steve.x.northover at oracle.com Wed Oct 16 08:03:49 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 16 Oct 2013 11:03:49 -0400 Subject: Half-baked API (Camera position) In-Reply-To: References: <525E488B.40105@oracle.com> Message-ID: <525EAAD5.3050808@oracle.com> Could do something useful with what was there now? We can always fix this in future by adding another API to govern the interpretation of the value. Throwing the exception indicates that the call is unsupported, but application code can be written to catch the exception and when we implement the API, it can break (I realize that this is unlikely). Steve On 2013-10-16 10:46 AM, Richard Bair wrote: > My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. > >> On Oct 16, 2013, at 1:04 AM, Pavel Safrata wrote: >> >> Hello, >> it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough time&priority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: >> >> 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a "known limitation". >> >> 2. PickResult on events which reports "intersectedDistance" between the camera and the picked point. This is worse because we can't just "not support" it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes "in front of Z=-1" it reports negative distances). This may change when the camera position is properly discussed and specified. >> >> Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. >> >> So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the "intersectedDistance" in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? >> >> Thanks, >> Pavel From tom.schindl at bestsolution.at Wed Oct 16 08:12:54 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 16 Oct 2013 17:12:54 +0200 Subject: Constructor annotation In-Reply-To: <525EA99D.4090605@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> Message-ID: <525EACF6.6030607@bestsolution.at> To me the JavaBean solution with one annotation looks error prone, does anybody know why they did not use an annotation per field? Tom On 16.10.13 16:58, Stephen F Northover wrote: > +1 for base. Should we not follow closely what Java Beans is doing for > consistency? I realize that we can't have the reference. > > Steve > > On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >> Not to mention Tom's point that it can't be in the fxml module without >> created unwanted (and circular) module dependencies. Seems like it >> needs to be in the "base" module then, right? >> >> -- Kevin >> >> >> Richard Bair wrote: >>> +1 this is my preference. It is useful for things other than FXML, >>> and should be considered part of our javafx.beans API. >>> >>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>> wrote: >>>> >>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>> Hi All, >>>>> >>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>> have a way to create classes without default constructors. Back >>>>> then we >>>>> decided to use an annotation for this but never actually got to >>>>> implement it and we need to fix this for FX8. I am in the process of >>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>> annotation will look like and I could use some help with this. >>>>> >>>>> We cannot use already existing ConstructorProperties for this, because >>>>> it's java.beans package and we don't want to create to dependency on >>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>> >>>>> We have two options: >>>>> >>>>> 1. Annotate the whole constructor: >>>>> e.g. >>>>> @ConstructorArguments({"a", "b", "list"}) >>>>> public ImmutableClass(int a, int b, Integer... list) >>>>> >>>>> 2. Annotate the arguments: >>>>> e.g. >>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>> >>>>> >>>>> Which option do you like more and how should the annotation be named? >>>> Option 2, but does it really have to hold FXML in the annotation name? >>>> Where would you put the annotation? I think it should NOT be in the >>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>> >>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>> by javax.inject) >>>> >>>> Tom > From sven.reimers at gmail.com Wed Oct 16 08:21:49 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 16 Oct 2013 17:21:49 +0200 Subject: Constructor annotation In-Reply-To: <525EACF6.6030607@bestsolution.at> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> Message-ID: +1 for base module +1 for option 2 Only thing that troubles me is the readability if the annotation is long.. you will end up with a lot of boilerplate annotation characters vs. content in the constructor argument declaration... -Sven On Wed, Oct 16, 2013 at 5:12 PM, Tom Schindl wrote: > To me the JavaBean solution with one annotation looks error prone, does > anybody know why they did not use an annotation per field? > > Tom > > On 16.10.13 16:58, Stephen F Northover wrote: > > +1 for base. Should we not follow closely what Java Beans is doing for > > consistency? I realize that we can't have the reference. > > > > Steve > > > > On 2013-10-16 10:53 AM, Kevin Rushforth wrote: > >> Not to mention Tom's point that it can't be in the fxml module without > >> created unwanted (and circular) module dependencies. Seems like it > >> needs to be in the "base" module then, right? > >> > >> -- Kevin > >> > >> > >> Richard Bair wrote: > >>> +1 this is my preference. It is useful for things other than FXML, > >>> and should be considered part of our javafx.beans API. > >>> > >>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl > >>>> wrote: > >>>> > >>>>> On 16.10.13 11:22, Eva Krejcirova wrote: > >>>>> Hi All, > >>>>> > >>>>> when we retired builders, we caused a problem for FXML which doesn't > >>>>> have a way to create classes without default constructors. Back > >>>>> then we > >>>>> decided to use an annotation for this but never actually got to > >>>>> implement it and we need to fix this for FX8. I am in the process of > >>>>> adding this functionality to FXMLLoader but we need to decide how the > >>>>> annotation will look like and I could use some help with this. > >>>>> > >>>>> We cannot use already existing ConstructorProperties for this, > because > >>>>> it's java.beans package and we don't want to create to dependency on > >>>>> this package in JavaFX, so we need to introduce a new annotation. > >>>>> > >>>>> We have two options: > >>>>> > >>>>> 1. Annotate the whole constructor: > >>>>> e.g. > >>>>> @ConstructorArguments({"a", "b", "list"}) > >>>>> public ImmutableClass(int a, int b, Integer... list) > >>>>> > >>>>> 2. Annotate the arguments: > >>>>> e.g. > >>>>> public ImmutableClass(@FXMLArgument("a") int a, > >>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) > >>>>> > >>>>> > >>>>> Which option do you like more and how should the annotation be named? > >>>> Option 2, but does it really have to hold FXML in the annotation name? > >>>> Where would you put the annotation? I think it should NOT be in the > >>>> FXML-Package-Namespace because the core should NOT depend on FXML! > >>>> > >>>> I'd go with @Argument or simply @NamedArgument (@Named is already used > >>>> by javax.inject) > >>>> > >>>> Tom > > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From pavel.safrata at oracle.com Wed Oct 16 08:22:00 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 16 Oct 2013 17:22:00 +0200 Subject: Half-baked API (Camera position) In-Reply-To: <525EAAD5.3050808@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> Message-ID: <525EAF18.4080303@oracle.com> On 16.10.2013 17:03, Stephen F Northover wrote: > Could do something useful with what was there now? We can always fix > this in future by adding another API to govern the interpretation of > the value. Not much useful. Anyway, any such stuff can be quite easily done by reading the intersectedPoint's Z coordinate. > > Throwing the exception indicates that the call is unsupported, but > application code can be written to catch the exception and when we > implement the API, it can break (I realize that this is unlikely). The exception can tell by the message that the operation will be supported in the future. Pavel > > Steve > > On 2013-10-16 10:46 AM, Richard Bair wrote: >> My quick vote would be throwing the exception, but is like to hear >> from Steve and Kevin. >> >>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata >>> wrote: >>> >>> Hello, >>> it looks like we can't help releasing a not-fully-baked piece of API >>> with FX8. We've added bunch of new APIs for 3D and did our best to >>> make them work well. Unfortunately, there's been not enough >>> time&priority to fine-tune their behavior in 2D world. Right now I'm >>> concerned about camera position in scene. It is inherent in the 3D >>> perspective camera that it has its specific position in world, but >>> the 2D parallel camera as we have it projects everything to the XY >>> plane basically by ignoring the Z coordinate, so the camera position >>> doesn't matter all that much. However, some of the newly added APIs >>> depend on it: >>> >>> 1. Near/far clip on camera. This obviously cannot work without >>> knowing where the camera is. Right now the parallel camera does no >>> clipping though, so I guess we are OK to go with it as a "known >>> limitation". >>> >>> 2. PickResult on events which reports "intersectedDistance" between >>> the camera and the picked point. This is worse because we can't just >>> "not support" it - there will be some value and once somebody uses >>> it we'll have a backward compatibility issue. The state right now is >>> that the camera is (tentatively, by my arbitrary decision) at [0, 0, >>> -1] and reports distances from there (note that as the camera >>> renders everything, for nodes "in front of Z=-1" it reports negative >>> distances). This may change when the camera position is properly >>> discussed and specified. >>> >>> Note that this post is *not* meant to discuss the camera position. >>> Even if we could find the answer quickly (which I doubt), it's most >>> probably too late to apply the change for FX8. >>> >>> So finally here is my question: do you think it's OK to solve this >>> by keeping the current behavior and documenting the >>> "intersectedDistance" in a way that for parallel camera the numbers >>> are unspecified and subject to change in future versions? Or would >>> you prefer something more drastic like throwing an >>> UnsupportedOperationException (losing the possibility to compare the >>> distances)? >>> >>> Thanks, >>> Pavel > From tom.schindl at bestsolution.at Wed Oct 16 08:24:32 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 16 Oct 2013 17:24:32 +0200 Subject: Constructor annotation In-Reply-To: <525EACF6.6030607@bestsolution.at> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> Message-ID: <525EAFB0.9080500@bestsolution.at> One thing that just came to my mind is that maybe also need a way to define the default value to be used, with a builder I could e.g. define that the default for fields are different from their real native default. class MyBuilder { private boolean a = true; private int x = -1; private Insets i = new Insets(10); } If we want to have a full replacement for builders the annotation must have the possibility define this (in future). public @interface NamedArgument { String value(); String defaultValue(); Class converterClass(); } If no converterClass is given we'd have to do our best to auto-convert the String. I don't want to say that we should implement the default value definition in FX8 but it would feel more natural with an annotation per argument. Tom On 16.10.13 17:12, Tom Schindl wrote: > To me the JavaBean solution with one annotation looks error prone, does > anybody know why they did not use an annotation per field? > > Tom > > On 16.10.13 16:58, Stephen F Northover wrote: >> +1 for base. Should we not follow closely what Java Beans is doing for >> consistency? I realize that we can't have the reference. >> >> Steve >> >> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>> Not to mention Tom's point that it can't be in the fxml module without >>> created unwanted (and circular) module dependencies. Seems like it >>> needs to be in the "base" module then, right? >>> >>> -- Kevin >>> >>> >>> Richard Bair wrote: >>>> +1 this is my preference. It is useful for things other than FXML, >>>> and should be considered part of our javafx.beans API. >>>> >>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>> wrote: >>>>> >>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>> Hi All, >>>>>> >>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>> have a way to create classes without default constructors. Back >>>>>> then we >>>>>> decided to use an annotation for this but never actually got to >>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>> annotation will look like and I could use some help with this. >>>>>> >>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>> it's java.beans package and we don't want to create to dependency on >>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>> >>>>>> We have two options: >>>>>> >>>>>> 1. Annotate the whole constructor: >>>>>> e.g. >>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>> >>>>>> 2. Annotate the arguments: >>>>>> e.g. >>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>> >>>>>> >>>>>> Which option do you like more and how should the annotation be named? >>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>> Where would you put the annotation? I think it should NOT be in the >>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>> >>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>> by javax.inject) >>>>> >>>>> Tom >> > From eva.krejcirova at oracle.com Wed Oct 16 08:41:44 2013 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 16 Oct 2013 17:41:44 +0200 Subject: Constructor annotation In-Reply-To: <525EAFB0.9080500@bestsolution.at> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> <525EAFB0.9080500@bestsolution.at> Message-ID: <525EB3B8.8030705@oracle.com> Good point! In FX sources, we already use the @Default annotation which was used by annotation processor when generating the builders. Because of this, it has source retention policy, so it cannot be used by FXMLLoader. I was thinking about promoting this to runtime annotation but maybe your solution is better. We should solve this for FX8 otherwise the FXMLLoader will behave differently from how the generated builders behaved. Eva On 16.10.2013 17:24, Tom Schindl wrote: > One thing that just came to my mind is that maybe also need a way to > define the default value to be used, with a builder I could e.g. define > that the default for fields are different from their real native default. > > class MyBuilder { > private boolean a = true; > private int x = -1; > private Insets i = new Insets(10); > } > > If we want to have a full replacement for builders the annotation must > have the possibility define this (in future). > > public @interface NamedArgument { > String value(); > String defaultValue(); > Class converterClass(); > } > > If no converterClass is given we'd have to do our best to auto-convert > the String. I don't want to say that we should implement the default > value definition in FX8 but it would feel more natural with an > annotation per argument. > > Tom > > On 16.10.13 17:12, Tom Schindl wrote: >> To me the JavaBean solution with one annotation looks error prone, does >> anybody know why they did not use an annotation per field? >> >> Tom >> >> On 16.10.13 16:58, Stephen F Northover wrote: >>> +1 for base. Should we not follow closely what Java Beans is doing for >>> consistency? I realize that we can't have the reference. >>> >>> Steve >>> >>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>> Not to mention Tom's point that it can't be in the fxml module without >>>> created unwanted (and circular) module dependencies. Seems like it >>>> needs to be in the "base" module then, right? >>>> >>>> -- Kevin >>>> >>>> >>>> Richard Bair wrote: >>>>> +1 this is my preference. It is useful for things other than FXML, >>>>> and should be considered part of our javafx.beans API. >>>>> >>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>> wrote: >>>>>> >>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>>> have a way to create classes without default constructors. Back >>>>>>> then we >>>>>>> decided to use an annotation for this but never actually got to >>>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>>> annotation will look like and I could use some help with this. >>>>>>> >>>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>>> it's java.beans package and we don't want to create to dependency on >>>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>>> >>>>>>> We have two options: >>>>>>> >>>>>>> 1. Annotate the whole constructor: >>>>>>> e.g. >>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>> >>>>>>> 2. Annotate the arguments: >>>>>>> e.g. >>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>> >>>>>>> >>>>>>> Which option do you like more and how should the annotation be named? >>>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>>> Where would you put the annotation? I think it should NOT be in the >>>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>>> >>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>>> by javax.inject) >>>>>> >>>>>> Tom From richard.bair at oracle.com Wed Oct 16 08:45:28 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 16 Oct 2013 08:45:28 -0700 Subject: Constructor annotation In-Reply-To: <525EB3B8.8030705@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> <525EAFB0.9080500@bestsolution.at> <525EB3B8.8030705@oracle.com> Message-ID: Ya that works too. > On Oct 16, 2013, at 8:41 AM, Eva Krejcirova wrote: > > Good point! > In FX sources, we already use the @Default annotation which was used by annotation processor when generating the builders. Because of this, it has source retention policy, so it cannot be used by FXMLLoader. I was thinking about promoting this to runtime annotation but maybe your solution is better. > > We should solve this for FX8 otherwise the FXMLLoader will behave differently from how the generated builders behaved. > > Eva > >> On 16.10.2013 17:24, Tom Schindl wrote: >> One thing that just came to my mind is that maybe also need a way to >> define the default value to be used, with a builder I could e.g. define >> that the default for fields are different from their real native default. >> >> class MyBuilder { >> private boolean a = true; >> private int x = -1; >> private Insets i = new Insets(10); >> } >> >> If we want to have a full replacement for builders the annotation must >> have the possibility define this (in future). >> >> public @interface NamedArgument { >> String value(); >> String defaultValue(); >> Class converterClass(); >> } >> >> If no converterClass is given we'd have to do our best to auto-convert >> the String. I don't want to say that we should implement the default >> value definition in FX8 but it would feel more natural with an >> annotation per argument. >> >> Tom >> >>> On 16.10.13 17:12, Tom Schindl wrote: >>> To me the JavaBean solution with one annotation looks error prone, does >>> anybody know why they did not use an annotation per field? >>> >>> Tom >>> >>>> On 16.10.13 16:58, Stephen F Northover wrote: >>>> +1 for base. Should we not follow closely what Java Beans is doing for >>>> consistency? I realize that we can't have the reference. >>>> >>>> Steve >>>> >>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>>> Not to mention Tom's point that it can't be in the fxml module without >>>>> created unwanted (and circular) module dependencies. Seems like it >>>>> needs to be in the "base" module then, right? >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Richard Bair wrote: >>>>>> +1 this is my preference. It is useful for things other than FXML, >>>>>> and should be considered part of our javafx.beans API. >>>>>> >>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>>> wrote: >>>>>>> >>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>>>> have a way to create classes without default constructors. Back >>>>>>>> then we >>>>>>>> decided to use an annotation for this but never actually got to >>>>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>>>> annotation will look like and I could use some help with this. >>>>>>>> >>>>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>>>> it's java.beans package and we don't want to create to dependency on >>>>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>>>> >>>>>>>> We have two options: >>>>>>>> >>>>>>>> 1. Annotate the whole constructor: >>>>>>>> e.g. >>>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>>> >>>>>>>> 2. Annotate the arguments: >>>>>>>> e.g. >>>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>>> >>>>>>>> >>>>>>>> Which option do you like more and how should the annotation be named? >>>>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>>>> Where would you put the annotation? I think it should NOT be in the >>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>>>> >>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>>>> by javax.inject) >>>>>>> >>>>>>> Tom > From steve.x.northover at oracle.com Wed Oct 16 10:02:22 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 16 Oct 2013 13:02:22 -0400 Subject: Constructor annotation In-Reply-To: References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> <525EAFB0.9080500@bestsolution.at> <525EB3B8.8030705@oracle.com> Message-ID: <525EC69E.2070308@oracle.com> It seems we are settling on @NamedArgument ... anybody disagree strongly? Steve On 2013-10-16 11:45 AM, Richard Bair wrote: > Ya that works too. > >> On Oct 16, 2013, at 8:41 AM, Eva Krejcirova wrote: >> >> Good point! >> In FX sources, we already use the @Default annotation which was used by annotation processor when generating the builders. Because of this, it has source retention policy, so it cannot be used by FXMLLoader. I was thinking about promoting this to runtime annotation but maybe your solution is better. >> >> We should solve this for FX8 otherwise the FXMLLoader will behave differently from how the generated builders behaved. >> >> Eva >> >>> On 16.10.2013 17:24, Tom Schindl wrote: >>> One thing that just came to my mind is that maybe also need a way to >>> define the default value to be used, with a builder I could e.g. define >>> that the default for fields are different from their real native default. >>> >>> class MyBuilder { >>> private boolean a = true; >>> private int x = -1; >>> private Insets i = new Insets(10); >>> } >>> >>> If we want to have a full replacement for builders the annotation must >>> have the possibility define this (in future). >>> >>> public @interface NamedArgument { >>> String value(); >>> String defaultValue(); >>> Class converterClass(); >>> } >>> >>> If no converterClass is given we'd have to do our best to auto-convert >>> the String. I don't want to say that we should implement the default >>> value definition in FX8 but it would feel more natural with an >>> annotation per argument. >>> >>> Tom >>> >>>> On 16.10.13 17:12, Tom Schindl wrote: >>>> To me the JavaBean solution with one annotation looks error prone, does >>>> anybody know why they did not use an annotation per field? >>>> >>>> Tom >>>> >>>>> On 16.10.13 16:58, Stephen F Northover wrote: >>>>> +1 for base. Should we not follow closely what Java Beans is doing for >>>>> consistency? I realize that we can't have the reference. >>>>> >>>>> Steve >>>>> >>>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>>>> Not to mention Tom's point that it can't be in the fxml module without >>>>>> created unwanted (and circular) module dependencies. Seems like it >>>>>> needs to be in the "base" module then, right? >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Richard Bair wrote: >>>>>>> +1 this is my preference. It is useful for things other than FXML, >>>>>>> and should be considered part of our javafx.beans API. >>>>>>> >>>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>>>>> have a way to create classes without default constructors. Back >>>>>>>>> then we >>>>>>>>> decided to use an annotation for this but never actually got to >>>>>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>>>>> annotation will look like and I could use some help with this. >>>>>>>>> >>>>>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>>>>> it's java.beans package and we don't want to create to dependency on >>>>>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>>>>> >>>>>>>>> We have two options: >>>>>>>>> >>>>>>>>> 1. Annotate the whole constructor: >>>>>>>>> e.g. >>>>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>>>> >>>>>>>>> 2. Annotate the arguments: >>>>>>>>> e.g. >>>>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>>>> >>>>>>>>> >>>>>>>>> Which option do you like more and how should the annotation be named? >>>>>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>>>>> Where would you put the annotation? I think it should NOT be in the >>>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>>>>> >>>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>>>>> by javax.inject) >>>>>>>> >>>>>>>> Tom From hang.vo at oracle.com Wed Oct 16 09:18:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 16:18:08 +0000 Subject: hg: openjfx/8/graphics/rt: RT-29922 Ensemble8: remove builders (partial) Message-ID: <20131016161919.A67996246A@hg.openjdk.java.net> Changeset: e4573094ccc6 Author: dmasada Date: 2013-10-16 09:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e4573094ccc6 RT-29922 Ensemble8: remove builders (partial) ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/menu/MenuApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/text/insettext/InsetTextApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/text/searchbox/SearchBoxApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/toolbar/styledtoolbar/StyledToolBarApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/displayshelf/PerspectiveImage.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/cube/Cube.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/cubesystem/Cube.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/cubesystem/CubeSystemApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/xylophone/Cube.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics3d/xylophone/XylophoneApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/media/advancedmedia/AdvancedMediaApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/media/advancedmedia/MediaControl.java From richard.bair at oracle.com Wed Oct 16 10:25:36 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 16 Oct 2013 10:25:36 -0700 Subject: Constructor annotation In-Reply-To: <525EC69E.2070308@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> <525EAFB0.9080500@bestsolution.at> <525EB3B8.8030705@oracle.com> <525EC69E.2070308@oracle.com> Message-ID: <58550C9D-F385-4CA6-B0F4-49A85C4270EC@oracle.com> Looks good to me. > On Oct 16, 2013, at 10:02 AM, Stephen F Northover wrote: > > It seems we are settling on @NamedArgument ... anybody disagree strongly? > > Steve > >> On 2013-10-16 11:45 AM, Richard Bair wrote: >> Ya that works too. >> >>> On Oct 16, 2013, at 8:41 AM, Eva Krejcirova wrote: >>> >>> Good point! >>> In FX sources, we already use the @Default annotation which was used by annotation processor when generating the builders. Because of this, it has source retention policy, so it cannot be used by FXMLLoader. I was thinking about promoting this to runtime annotation but maybe your solution is better. >>> >>> We should solve this for FX8 otherwise the FXMLLoader will behave differently from how the generated builders behaved. >>> >>> Eva >>> >>>> On 16.10.2013 17:24, Tom Schindl wrote: >>>> One thing that just came to my mind is that maybe also need a way to >>>> define the default value to be used, with a builder I could e.g. define >>>> that the default for fields are different from their real native default. >>>> >>>> class MyBuilder { >>>> private boolean a = true; >>>> private int x = -1; >>>> private Insets i = new Insets(10); >>>> } >>>> >>>> If we want to have a full replacement for builders the annotation must >>>> have the possibility define this (in future). >>>> >>>> public @interface NamedArgument { >>>> String value(); >>>> String defaultValue(); >>>> Class converterClass(); >>>> } >>>> >>>> If no converterClass is given we'd have to do our best to auto-convert >>>> the String. I don't want to say that we should implement the default >>>> value definition in FX8 but it would feel more natural with an >>>> annotation per argument. >>>> >>>> Tom >>>> >>>>> On 16.10.13 17:12, Tom Schindl wrote: >>>>> To me the JavaBean solution with one annotation looks error prone, does >>>>> anybody know why they did not use an annotation per field? >>>>> >>>>> Tom >>>>> >>>>>> On 16.10.13 16:58, Stephen F Northover wrote: >>>>>> +1 for base. Should we not follow closely what Java Beans is doing for >>>>>> consistency? I realize that we can't have the reference. >>>>>> >>>>>> Steve >>>>>> >>>>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>>>>> Not to mention Tom's point that it can't be in the fxml module without >>>>>>> created unwanted (and circular) module dependencies. Seems like it >>>>>>> needs to be in the "base" module then, right? >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Richard Bair wrote: >>>>>>>> +1 this is my preference. It is useful for things other than FXML, >>>>>>>> and should be considered part of our javafx.beans API. >>>>>>>> >>>>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>>>>>> have a way to create classes without default constructors. Back >>>>>>>>>> then we >>>>>>>>>> decided to use an annotation for this but never actually got to >>>>>>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>>>>>> annotation will look like and I could use some help with this. >>>>>>>>>> >>>>>>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>>>>>> it's java.beans package and we don't want to create to dependency on >>>>>>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>>>>>> >>>>>>>>>> We have two options: >>>>>>>>>> >>>>>>>>>> 1. Annotate the whole constructor: >>>>>>>>>> e.g. >>>>>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>>>>> >>>>>>>>>> 2. Annotate the arguments: >>>>>>>>>> e.g. >>>>>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Which option do you like more and how should the annotation be named? >>>>>>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>>>>>> Where would you put the annotation? I think it should NOT be in the >>>>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>>>>>> >>>>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>>>>>> by javax.inject) >>>>>>>>> >>>>>>>>> Tom > From steve.x.northover at oracle.com Wed Oct 16 10:27:50 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 16 Oct 2013 13:27:50 -0400 Subject: Constructor annotation In-Reply-To: <58550C9D-F385-4CA6-B0F4-49A85C4270EC@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> <525EAFB0.9080500@bestsolution.at> <525EB3B8.8030705@oracle.com> <525EC69E.2070308@oracle.com> <58550C9D-F385-4CA6-B0F4-49A85C4270EC@oracle.com> Message-ID: <525ECC96.8010805@oracle.com> Eva, Perhaps @NamedArg is shorter and makes the code more readable? If you don't have a JIRA already, please create one and paste in this discussion. Interested parties can add themselves to the watchers list. Steve On 2013-10-16 1:25 PM, Richard Bair wrote: > Looks good to me. > >> On Oct 16, 2013, at 10:02 AM, Stephen F Northover wrote: >> >> It seems we are settling on @NamedArgument ... anybody disagree strongly? >> >> Steve >> >>> On 2013-10-16 11:45 AM, Richard Bair wrote: >>> Ya that works too. >>> >>>> On Oct 16, 2013, at 8:41 AM, Eva Krejcirova wrote: >>>> >>>> Good point! >>>> In FX sources, we already use the @Default annotation which was used by annotation processor when generating the builders. Because of this, it has source retention policy, so it cannot be used by FXMLLoader. I was thinking about promoting this to runtime annotation but maybe your solution is better. >>>> >>>> We should solve this for FX8 otherwise the FXMLLoader will behave differently from how the generated builders behaved. >>>> >>>> Eva >>>> >>>>> On 16.10.2013 17:24, Tom Schindl wrote: >>>>> One thing that just came to my mind is that maybe also need a way to >>>>> define the default value to be used, with a builder I could e.g. define >>>>> that the default for fields are different from their real native default. >>>>> >>>>> class MyBuilder { >>>>> private boolean a = true; >>>>> private int x = -1; >>>>> private Insets i = new Insets(10); >>>>> } >>>>> >>>>> If we want to have a full replacement for builders the annotation must >>>>> have the possibility define this (in future). >>>>> >>>>> public @interface NamedArgument { >>>>> String value(); >>>>> String defaultValue(); >>>>> Class converterClass(); >>>>> } >>>>> >>>>> If no converterClass is given we'd have to do our best to auto-convert >>>>> the String. I don't want to say that we should implement the default >>>>> value definition in FX8 but it would feel more natural with an >>>>> annotation per argument. >>>>> >>>>> Tom >>>>> >>>>>> On 16.10.13 17:12, Tom Schindl wrote: >>>>>> To me the JavaBean solution with one annotation looks error prone, does >>>>>> anybody know why they did not use an annotation per field? >>>>>> >>>>>> Tom >>>>>> >>>>>>> On 16.10.13 16:58, Stephen F Northover wrote: >>>>>>> +1 for base. Should we not follow closely what Java Beans is doing for >>>>>>> consistency? I realize that we can't have the reference. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>>>>>> Not to mention Tom's point that it can't be in the fxml module without >>>>>>>> created unwanted (and circular) module dependencies. Seems like it >>>>>>>> needs to be in the "base" module then, right? >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Richard Bair wrote: >>>>>>>>> +1 this is my preference. It is useful for things other than FXML, >>>>>>>>> and should be considered part of our javafx.beans API. >>>>>>>>> >>>>>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>>>>>>> have a way to create classes without default constructors. Back >>>>>>>>>>> then we >>>>>>>>>>> decided to use an annotation for this but never actually got to >>>>>>>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>>>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>>>>>>> annotation will look like and I could use some help with this. >>>>>>>>>>> >>>>>>>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>>>>>>> it's java.beans package and we don't want to create to dependency on >>>>>>>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>>>>>>> >>>>>>>>>>> We have two options: >>>>>>>>>>> >>>>>>>>>>> 1. Annotate the whole constructor: >>>>>>>>>>> e.g. >>>>>>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>>>>>> >>>>>>>>>>> 2. Annotate the arguments: >>>>>>>>>>> e.g. >>>>>>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Which option do you like more and how should the annotation be named? >>>>>>>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>>>>>>> Where would you put the annotation? I think it should NOT be in the >>>>>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>>>>>>> >>>>>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>>>>>>> by javax.inject) >>>>>>>>>> >>>>>>>>>> Tom From richard.bair at oracle.com Wed Oct 16 10:29:06 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 16 Oct 2013 10:29:06 -0700 Subject: Constructor annotation In-Reply-To: <525ECC96.8010805@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> <525EAFB0.9080500@bestsolution.at> <525EB3B8.8030705@oracle.com> <525EC69E.2070308@oracle.com> <58550C9D-F385-4CA6-B0F4-49A85C4270EC@oracle.com> <525ECC96.8010805@oracle.com> Message-ID: NamedArg, like a pirate :-) > On Oct 16, 2013, at 10:27 AM, Stephen F Northover wrote: > > Eva, > > Perhaps @NamedArg is shorter and makes the code more readable? > > If you don't have a JIRA already, please create one and paste in this discussion. Interested parties can add themselves to the watchers list. > > Steve > >> On 2013-10-16 1:25 PM, Richard Bair wrote: >> Looks good to me. >> >>> On Oct 16, 2013, at 10:02 AM, Stephen F Northover wrote: >>> >>> It seems we are settling on @NamedArgument ... anybody disagree strongly? >>> >>> Steve >>> >>>> On 2013-10-16 11:45 AM, Richard Bair wrote: >>>> Ya that works too. >>>> >>>>> On Oct 16, 2013, at 8:41 AM, Eva Krejcirova wrote: >>>>> >>>>> Good point! >>>>> In FX sources, we already use the @Default annotation which was used by annotation processor when generating the builders. Because of this, it has source retention policy, so it cannot be used by FXMLLoader. I was thinking about promoting this to runtime annotation but maybe your solution is better. >>>>> >>>>> We should solve this for FX8 otherwise the FXMLLoader will behave differently from how the generated builders behaved. >>>>> >>>>> Eva >>>>> >>>>>> On 16.10.2013 17:24, Tom Schindl wrote: >>>>>> One thing that just came to my mind is that maybe also need a way to >>>>>> define the default value to be used, with a builder I could e.g. define >>>>>> that the default for fields are different from their real native default. >>>>>> >>>>>> class MyBuilder { >>>>>> private boolean a = true; >>>>>> private int x = -1; >>>>>> private Insets i = new Insets(10); >>>>>> } >>>>>> >>>>>> If we want to have a full replacement for builders the annotation must >>>>>> have the possibility define this (in future). >>>>>> >>>>>> public @interface NamedArgument { >>>>>> String value(); >>>>>> String defaultValue(); >>>>>> Class converterClass(); >>>>>> } >>>>>> >>>>>> If no converterClass is given we'd have to do our best to auto-convert >>>>>> the String. I don't want to say that we should implement the default >>>>>> value definition in FX8 but it would feel more natural with an >>>>>> annotation per argument. >>>>>> >>>>>> Tom >>>>>> >>>>>>> On 16.10.13 17:12, Tom Schindl wrote: >>>>>>> To me the JavaBean solution with one annotation looks error prone, does >>>>>>> anybody know why they did not use an annotation per field? >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>>> On 16.10.13 16:58, Stephen F Northover wrote: >>>>>>>> +1 for base. Should we not follow closely what Java Beans is doing for >>>>>>>> consistency? I realize that we can't have the reference. >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>>>>>>> Not to mention Tom's point that it can't be in the fxml module without >>>>>>>>> created unwanted (and circular) module dependencies. Seems like it >>>>>>>>> needs to be in the "base" module then, right? >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Richard Bair wrote: >>>>>>>>>> +1 this is my preference. It is useful for things other than FXML, >>>>>>>>>> and should be considered part of our javafx.beans API. >>>>>>>>>> >>>>>>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>>>>>>>> have a way to create classes without default constructors. Back >>>>>>>>>>>> then we >>>>>>>>>>>> decided to use an annotation for this but never actually got to >>>>>>>>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>>>>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>>>>>>>> annotation will look like and I could use some help with this. >>>>>>>>>>>> >>>>>>>>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>>>>>>>> it's java.beans package and we don't want to create to dependency on >>>>>>>>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>>>>>>>> >>>>>>>>>>>> We have two options: >>>>>>>>>>>> >>>>>>>>>>>> 1. Annotate the whole constructor: >>>>>>>>>>>> e.g. >>>>>>>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>>>>>>> >>>>>>>>>>>> 2. Annotate the arguments: >>>>>>>>>>>> e.g. >>>>>>>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Which option do you like more and how should the annotation be named? >>>>>>>>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>>>>>>>> Where would you put the annotation? I think it should NOT be in the >>>>>>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>>>>>>>> >>>>>>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>>>>>>>> by javax.inject) >>>>>>>>>>> >>>>>>>>>>> Tom > From Claus.Luethje at osys.ch Wed Oct 16 10:29:17 2013 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Wed, 16 Oct 2013 17:29:17 +0000 Subject: Constructor annotation In-Reply-To: <58550C9D-F385-4CA6-B0F4-49A85C4270EC@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> <525EAFB0.9080500@bestsolution.at> <525EB3B8.8030705@oracle.com> <525EC69E.2070308@oracle.com>, <58550C9D-F385-4CA6-B0F4-49A85C4270EC@oracle.com> Message-ID: +1 > Am 16.10.2013 um 19:28 schrieb "Richard Bair" : > > Looks good to me. > >> On Oct 16, 2013, at 10:02 AM, Stephen F Northover wrote: >> >> It seems we are settling on @NamedArgument ... anybody disagree strongly? >> >> Steve >> >>> On 2013-10-16 11:45 AM, Richard Bair wrote: >>> Ya that works too. >>> >>>> On Oct 16, 2013, at 8:41 AM, Eva Krejcirova wrote: >>>> >>>> Good point! >>>> In FX sources, we already use the @Default annotation which was used by annotation processor when generating the builders. Because of this, it has source retention policy, so it cannot be used by FXMLLoader. I was thinking about promoting this to runtime annotation but maybe your solution is better. >>>> >>>> We should solve this for FX8 otherwise the FXMLLoader will behave differently from how the generated builders behaved. >>>> >>>> Eva >>>> >>>>> On 16.10.2013 17:24, Tom Schindl wrote: >>>>> One thing that just came to my mind is that maybe also need a way to >>>>> define the default value to be used, with a builder I could e.g. define >>>>> that the default for fields are different from their real native default. >>>>> >>>>> class MyBuilder { >>>>> private boolean a = true; >>>>> private int x = -1; >>>>> private Insets i = new Insets(10); >>>>> } >>>>> >>>>> If we want to have a full replacement for builders the annotation must >>>>> have the possibility define this (in future). >>>>> >>>>> public @interface NamedArgument { >>>>> String value(); >>>>> String defaultValue(); >>>>> Class converterClass(); >>>>> } >>>>> >>>>> If no converterClass is given we'd have to do our best to auto-convert >>>>> the String. I don't want to say that we should implement the default >>>>> value definition in FX8 but it would feel more natural with an >>>>> annotation per argument. >>>>> >>>>> Tom >>>>> >>>>>> On 16.10.13 17:12, Tom Schindl wrote: >>>>>> To me the JavaBean solution with one annotation looks error prone, does >>>>>> anybody know why they did not use an annotation per field? >>>>>> >>>>>> Tom >>>>>> >>>>>>> On 16.10.13 16:58, Stephen F Northover wrote: >>>>>>> +1 for base. Should we not follow closely what Java Beans is doing for >>>>>>> consistency? I realize that we can't have the reference. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>>>>>> Not to mention Tom's point that it can't be in the fxml module without >>>>>>>> created unwanted (and circular) module dependencies. Seems like it >>>>>>>> needs to be in the "base" module then, right? >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Richard Bair wrote: >>>>>>>>> +1 this is my preference. It is useful for things other than FXML, >>>>>>>>> and should be considered part of our javafx.beans API. >>>>>>>>> >>>>>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> when we retired builders, we caused a problem for FXML which doesn't >>>>>>>>>>> have a way to create classes without default constructors. Back >>>>>>>>>>> then we >>>>>>>>>>> decided to use an annotation for this but never actually got to >>>>>>>>>>> implement it and we need to fix this for FX8. I am in the process of >>>>>>>>>>> adding this functionality to FXMLLoader but we need to decide how the >>>>>>>>>>> annotation will look like and I could use some help with this. >>>>>>>>>>> >>>>>>>>>>> We cannot use already existing ConstructorProperties for this, because >>>>>>>>>>> it's java.beans package and we don't want to create to dependency on >>>>>>>>>>> this package in JavaFX, so we need to introduce a new annotation. >>>>>>>>>>> >>>>>>>>>>> We have two options: >>>>>>>>>>> >>>>>>>>>>> 1. Annotate the whole constructor: >>>>>>>>>>> e.g. >>>>>>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>>>>>> >>>>>>>>>>> 2. Annotate the arguments: >>>>>>>>>>> e.g. >>>>>>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Which option do you like more and how should the annotation be named? >>>>>>>>>> Option 2, but does it really have to hold FXML in the annotation name? >>>>>>>>>> Where would you put the annotation? I think it should NOT be in the >>>>>>>>>> FXML-Package-Namespace because the core should NOT depend on FXML! >>>>>>>>>> >>>>>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is already used >>>>>>>>>> by javax.inject) >>>>>>>>>> >>>>>>>>>> Tom >> From hang.vo at oracle.com Wed Oct 16 10:48:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 17:48:58 +0000 Subject: hg: openjfx/8/graphics/rt: [CLEANUP-ONLY] remove unused obsolete/ directory (old "ant-based" build files) Message-ID: <20131016175000.D314062470@hg.openjdk.java.net> Changeset: 659159f239a9 Author: kcr Date: 2013-10-16 10:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/659159f239a9 [CLEANUP-ONLY] remove unused obsolete/ directory (old "ant-based" build files) Reviewed-by: snorthov - obsolete/apps/build-defs.xml - obsolete/apps/build-tasks.xml - obsolete/apps/build.xml - obsolete/apps/experiments/3DViewer/3D Viewer.iml - obsolete/apps/experiments/3DViewer/build.xml - obsolete/apps/experiments/3DViewer/session.properties - obsolete/apps/experiments/ConferenceScheduleApp/build.xml - obsolete/apps/experiments/Modena/Modena.iml - obsolete/apps/experiments/Modena/build.xml - obsolete/apps/experiments/ModenaTest/build.xml - obsolete/apps/experiments/build.xml - obsolete/apps/samples/Ensemble8/Ensemble8.iml - obsolete/apps/samples/Ensemble8/build.xml - obsolete/apps/samples/build.xml - obsolete/base.properties - obsolete/build-decora.xml - obsolete/build-defs.xml - obsolete/build.xml - obsolete/common.properties - obsolete/decora-compiler/build-closed.xml - obsolete/decora-compiler/build-common.xml - obsolete/decora-compiler/build.xml - obsolete/decora-compiler/nbproject/project.xml - obsolete/decora-compiler/project.properties - obsolete/decora-d3d/build-closed.xml - obsolete/decora-d3d/build-common.xml - obsolete/decora-d3d/build.xml - obsolete/decora-d3d/decora-d3d.iml - obsolete/decora-d3d/nbproject/project.xml - obsolete/decora-d3d/project.properties - obsolete/decora-es2/build-closed.xml - obsolete/decora-es2/build-common.xml - obsolete/decora-es2/build.xml - obsolete/decora-es2/decora-es2.iml - obsolete/decora-es2/nbproject/project.xml - obsolete/decora-es2/project.properties - obsolete/decora-jsw/build-closed.xml - obsolete/decora-jsw/build-common.xml - obsolete/decora-jsw/build.xml - obsolete/decora-jsw/decora-jsw.iml - obsolete/decora-jsw/nbproject/project.xml - obsolete/decora-jsw/project.properties - obsolete/decora-prism-ps/build-closed.xml - obsolete/decora-prism-ps/build-common.xml - obsolete/decora-prism-ps/build.xml - obsolete/decora-prism-ps/decora-prism-ps.iml - obsolete/decora-prism-ps/nbproject/project.xml - obsolete/decora-prism-ps/project.properties - obsolete/decora-prism-sw/build-closed.xml - obsolete/decora-prism-sw/build-common.xml - obsolete/decora-prism-sw/build.xml - obsolete/decora-prism-sw/decora-prism-sw.iml - obsolete/decora-prism-sw/nbproject/project.xml - obsolete/decora-prism-sw/project.properties - obsolete/decora-prism/build-closed.xml - obsolete/decora-prism/build-common.xml - obsolete/decora-prism/build.xml - obsolete/decora-prism/decora-prism.iml - obsolete/decora-prism/nbproject/project.xml - obsolete/decora-prism/project.properties - obsolete/decora-runtime/build-closed.xml - obsolete/decora-runtime/build-common.xml - obsolete/decora-runtime/build.xml - obsolete/decora-runtime/decora-runtime.iml - obsolete/decora-runtime/nbproject/project.xml - obsolete/decora-runtime/project.properties - obsolete/decora-sse-native/Makefile - obsolete/decora-sse-native/nbproject/Makefile-Debug.mk - obsolete/decora-sse-native/nbproject/Makefile-Release.mk - obsolete/decora-sse-native/nbproject/Makefile-impl.mk - obsolete/decora-sse-native/nbproject/configurations.xml - obsolete/decora-sse-native/nbproject/project.xml - obsolete/decora-sse/build-closed.xml - obsolete/decora-sse/build-common.xml - obsolete/decora-sse/build-macosx.xml - obsolete/decora-sse/build-windows.xml - obsolete/decora-sse/build.xml - obsolete/decora-sse/decora-sse.iml - obsolete/decora-sse/nbproject/project.xml - obsolete/decora-sse/project.properties - obsolete/deploy/build.xml - obsolete/deploy/javafx-launcher/build.xml - obsolete/deploy/javafx-launcher/manifest.mf - obsolete/deploy/javafx-launcher/nbproject/build-impl.xml - obsolete/deploy/javafx-launcher/nbproject/genfiles.properties - obsolete/deploy/javafx-launcher/nbproject/project.properties - obsolete/deploy/javafx-launcher/nbproject/project.xml - obsolete/deploy/man/build.xml - obsolete/deploy/packager/build.xml - obsolete/deploy/packager/manifest.mf - obsolete/deploy/packager/native/windows/IconSwap.vcxproj - obsolete/deploy/packager/native/windows/WinLauncher.vcxproj - obsolete/deploy/packager/nbproject/build-impl.xml - obsolete/deploy/packager/nbproject/genfiles.properties - obsolete/deploy/packager/nbproject/project.properties - obsolete/deploy/packager/nbproject/project.xml - obsolete/deploy/packager/winlauncher/Makefile - obsolete/deploy/packager/winlauncher/nbproject/Makefile-Release.mk - obsolete/deploy/packager/winlauncher/nbproject/Makefile-impl.mk - obsolete/deploy/packager/winlauncher/nbproject/configurations.xml - obsolete/deploy/packager/winlauncher/nbproject/project.properties - obsolete/deploy/packager/winlauncher/nbproject/project.xml - obsolete/generator.gradle - obsolete/glass/Glass.iml - obsolete/glass/build-closed.xml - obsolete/glass/build-common.xml - obsolete/glass/build.xml - obsolete/glass/glass-lib-gtk/Makefile - obsolete/glass/glass-lib-gtk/build.xml - obsolete/glass/glass-lib-ios/Makefile - obsolete/glass/glass-lib-ios/build.xml - obsolete/glass/glass-lib-ios/glass.xcodeproj/project.pbxproj - obsolete/glass/glass-lib-lens/Android.mk - obsolete/glass/glass-lib-lens/AndroidManifest.xml - obsolete/glass/glass-lib-lens/Makefile - obsolete/glass/glass-lib-lens/build-android.xml - obsolete/glass/glass-lib-lens/build.xml - obsolete/glass/glass-lib-macosx/Makefile - obsolete/glass/glass-lib-macosx/build.xml - obsolete/glass/glass-lib-windows/Depend.mak - obsolete/glass/glass-lib-windows/Makefile - obsolete/glass/glass-lib-windows/build.xml - obsolete/glass/glass/build.xml - obsolete/glass/glass/nbproject/project.xml - obsolete/javafx-accessible/build-closed.xml - obsolete/javafx-accessible/build.xml - obsolete/javafx-accessible/nbproject/project.xml - obsolete/javafx-accessible/project.properties - obsolete/javafx-android/activity/AndroidManifest.xml - obsolete/javafx-android/activity/ant.properties - obsolete/javafx-android/activity/build.xml - obsolete/javafx-android/activity/nbandroid/private.properties - obsolete/javafx-android/activity/project.properties - obsolete/javafx-android/build-closed.xml - obsolete/javafx-android/build-common.xml - obsolete/javafx-android/build.xml - obsolete/javafx-android/vmlauncher/AndroidManifest.xml - obsolete/javafx-android/vmlauncher/build.xml - obsolete/javafx-android/vmlauncher/jni/Android.mk - obsolete/javafx-android/vmlauncher/project.properties - obsolete/javafx-android/vmlauncher/vmlauncher-jni/nbproject/configurations.xml - obsolete/javafx-android/vmlauncher/vmlauncher-jni/nbproject/project.xml - obsolete/javafx-anim/build-closed.xml - obsolete/javafx-anim/build-common.xml - obsolete/javafx-anim/build.xml - obsolete/javafx-anim/javafx-anim.iml - obsolete/javafx-anim/nbproject/project.xml - obsolete/javafx-anim/project.properties - obsolete/javafx-beans-dt/build-closed.xml - obsolete/javafx-beans-dt/build-common.xml - obsolete/javafx-beans-dt/build.xml - obsolete/javafx-beans-dt/jar.jardesc - obsolete/javafx-beans-dt/javafx-beans-dt.iml - obsolete/javafx-beans-dt/nbproject/project.xml - obsolete/javafx-beans-dt/pom.xml - obsolete/javafx-beans-dt/project.properties - obsolete/javafx-beans/build-closed.xml - obsolete/javafx-beans/build-common.xml - obsolete/javafx-beans/build.xml - obsolete/javafx-beans/jar.jardesc - obsolete/javafx-beans/javafx-beans.iml - obsolete/javafx-beans/nbproject/project.xml - obsolete/javafx-beans/project.properties - obsolete/javafx-builders/build-closed.xml - obsolete/javafx-builders/build-common.xml - obsolete/javafx-builders/build.xml - obsolete/javafx-builders/nbproject/project.xml - obsolete/javafx-builders/project.properties - obsolete/javafx-common/build-closed.xml - obsolete/javafx-common/build-common.xml - obsolete/javafx-common/build.xml - obsolete/javafx-common/javafx-common.iml - obsolete/javafx-common/nbproject/project.xml - obsolete/javafx-common/project.properties - obsolete/javafx-concurrent/build-closed.xml - obsolete/javafx-concurrent/build-common.xml - obsolete/javafx-concurrent/build.xml - obsolete/javafx-concurrent/javafx-concurrent.iml - obsolete/javafx-concurrent/nbproject/project.xml - obsolete/javafx-concurrent/pom.xml - obsolete/javafx-concurrent/project.properties - obsolete/javafx-designtime/build-closed.xml - obsolete/javafx-designtime/build-common.xml - obsolete/javafx-designtime/build.xml - obsolete/javafx-designtime/jar.jardesc - obsolete/javafx-designtime/javafx-designtime.iml - obsolete/javafx-designtime/nbproject/project.xml - obsolete/javafx-designtime/pom.xml - obsolete/javafx-designtime/project.properties - obsolete/javafx-embed-swing/build-closed.xml - obsolete/javafx-embed-swing/build-common.xml - obsolete/javafx-embed-swing/build.xml - obsolete/javafx-embed-swing/javafx-embed-swing.iml - obsolete/javafx-embed-swing/nbproject/project.xml - obsolete/javafx-embed-swing/project.properties - obsolete/javafx-embed-swt/build-closed.xml - obsolete/javafx-embed-swt/build-common.xml - obsolete/javafx-embed-swt/build.xml - obsolete/javafx-embed-swt/javafx-embed-swt.iml - obsolete/javafx-embed-swt/nbproject/project.xml - obsolete/javafx-embed-swt/project.properties - obsolete/javafx-font-native/Android.mk - obsolete/javafx-font-native/Makefile - obsolete/javafx-font-native/nbproject/Makefile-Debug.mk - obsolete/javafx-font-native/nbproject/Makefile-Release.mk - obsolete/javafx-font-native/nbproject/Makefile-impl.mk - obsolete/javafx-font-native/nbproject/Package-Debug.bash - obsolete/javafx-font-native/nbproject/Package-Release.bash - obsolete/javafx-font-native/nbproject/configurations.xml - obsolete/javafx-font-native/nbproject/project.xml - obsolete/javafx-font/build-android.xml - obsolete/javafx-font/build-closed.xml - obsolete/javafx-font/build-common.xml - obsolete/javafx-font/build-ios.xml - obsolete/javafx-font/build-linux.xml - obsolete/javafx-font/build-macosx.xml - obsolete/javafx-font/build-solaris.xml - obsolete/javafx-font/build-windows.xml - obsolete/javafx-font/build.xml - obsolete/javafx-font/javafx-font.iml - obsolete/javafx-font/nbproject/project.xml - obsolete/javafx-font/project.properties - obsolete/javafx-fxml/build-closed.xml - obsolete/javafx-fxml/build-common.xml - obsolete/javafx-fxml/build.xml - obsolete/javafx-fxml/nbproject/ide-file-targets.xml - obsolete/javafx-fxml/nbproject/project.xml - obsolete/javafx-fxml/project.properties - obsolete/javafx-geom/build-closed.xml - obsolete/javafx-geom/build-common.xml - obsolete/javafx-geom/build.xml - obsolete/javafx-geom/javafx-geom.iml - obsolete/javafx-geom/nbproject/project.xml - obsolete/javafx-geom/project.properties - obsolete/javafx-iio-native/Android.mk - obsolete/javafx-iio-native/Makefile - obsolete/javafx-iio-native/nbproject/Makefile-Debug.mk - obsolete/javafx-iio-native/nbproject/Makefile-Release.mk - obsolete/javafx-iio-native/nbproject/Makefile-impl.mk - obsolete/javafx-iio-native/nbproject/Package-Debug.bash - obsolete/javafx-iio-native/nbproject/Package-Release.bash - obsolete/javafx-iio-native/nbproject/configurations.xml - obsolete/javafx-iio-native/nbproject/project.xml - obsolete/javafx-iio/build-android.xml - obsolete/javafx-iio/build-closed.xml - obsolete/javafx-iio/build-common.xml - obsolete/javafx-iio/build-ios.xml - obsolete/javafx-iio/build-linux.xml - obsolete/javafx-iio/build-macosx.xml - obsolete/javafx-iio/build-solaris.xml - obsolete/javafx-iio/build-windows.xml - obsolete/javafx-iio/build.xml - obsolete/javafx-iio/javafx-iio.iml - obsolete/javafx-iio/nbproject/project.xml - obsolete/javafx-iio/project.properties - obsolete/javafx-logging/build-before-profiler.xml - obsolete/javafx-logging/build-closed.xml - obsolete/javafx-logging/build-common.xml - obsolete/javafx-logging/build.xml - obsolete/javafx-logging/javafx-logging.iml - obsolete/javafx-logging/nbproject/build-impl.xml - obsolete/javafx-logging/nbproject/genfiles.properties - obsolete/javafx-logging/nbproject/profiler-build-impl.xml - obsolete/javafx-logging/nbproject/project.properties - obsolete/javafx-logging/nbproject/project.xml - obsolete/javafx-sg-common/build-closed.xml - obsolete/javafx-sg-common/build-common.xml - obsolete/javafx-sg-common/build.xml - obsolete/javafx-sg-common/javafx-sg-common.iml - obsolete/javafx-sg-common/nbproject/project.xml - obsolete/javafx-sg-common/project.properties - obsolete/javafx-sg-prism/build-closed.xml - obsolete/javafx-sg-prism/build-common.xml - obsolete/javafx-sg-prism/build.xml - obsolete/javafx-sg-prism/javafx-sg-prism.iml - obsolete/javafx-sg-prism/nbproject/project.xml - obsolete/javafx-sg-prism/project.properties - obsolete/javafx-ueber-jar/pom.xml - obsolete/javafx-ui-charts/build-closed.xml - obsolete/javafx-ui-charts/build-common.xml - obsolete/javafx-ui-charts/build.xml - obsolete/javafx-ui-charts/javafx-ui-charts.iml - obsolete/javafx-ui-charts/nbproject/project.xml - obsolete/javafx-ui-charts/project.properties - obsolete/javafx-ui-common/.externalToolBuilders/CSS_Builder.launch - obsolete/javafx-ui-common/.settings/org.eclipse.jdt.core.prefs - obsolete/javafx-ui-common/build-closed.xml - obsolete/javafx-ui-common/build-common.xml - obsolete/javafx-ui-common/build.xml - obsolete/javafx-ui-common/javafx-ui-common.iml - obsolete/javafx-ui-common/nbproject/project.xml - obsolete/javafx-ui-common/pom.xml - obsolete/javafx-ui-common/project.properties - obsolete/javafx-ui-controls/build-closed.xml - obsolete/javafx-ui-controls/build-common.xml - obsolete/javafx-ui-controls/build.xml - obsolete/javafx-ui-controls/javafx-ui-controls.iml - obsolete/javafx-ui-controls/nbproject/project.xml - obsolete/javafx-ui-controls/pom.xml - obsolete/javafx-ui-controls/project.properties - obsolete/javafx-ui-quantum/build-closed.xml - obsolete/javafx-ui-quantum/build-common.xml - obsolete/javafx-ui-quantum/build.xml - obsolete/javafx-ui-quantum/javafx-ui-quantum.iml - obsolete/javafx-ui-quantum/nbproject/project.xml - obsolete/javafx-ui-quantum/project.properties - obsolete/javafx-util-converter/build-closed.xml - obsolete/javafx-util-converter/build-common.xml - obsolete/javafx-util-converter/build.xml - obsolete/javafx-util-converter/javafx-util-converter.iml - obsolete/javafx-util-converter/nbproject/project.xml - obsolete/javafx-util-converter/project.properties - obsolete/nbactions-javafx.xml - obsolete/pisces/build-closed.xml - obsolete/pisces/build-common.xml - obsolete/pisces/build.xml - obsolete/pisces/nbproject/project.xml - obsolete/pisces/pisces.iml - obsolete/pisces/project.properties - obsolete/pom.xml - obsolete/prism-common-native/Android.mk - obsolete/prism-common-native/Makefile - obsolete/prism-common-native/nbproject/Makefile-Debug.mk - obsolete/prism-common-native/nbproject/Makefile-Release.mk - obsolete/prism-common-native/nbproject/Makefile-impl.mk - obsolete/prism-common-native/nbproject/Makefile-variables.mk - obsolete/prism-common-native/nbproject/Package-Debug.bash - obsolete/prism-common-native/nbproject/configurations.xml - obsolete/prism-common-native/nbproject/project.xml - obsolete/prism-common/build-android.xml - obsolete/prism-common/build-closed.xml - obsolete/prism-common/build-common.xml - obsolete/prism-common/build-ios.xml - obsolete/prism-common/build-linux.xml - obsolete/prism-common/build-macosx.xml - obsolete/prism-common/build-solaris.xml - obsolete/prism-common/build-windows.xml - obsolete/prism-common/build.xml - obsolete/prism-common/nbproject/project.xml - obsolete/prism-common/prism-common.iml - obsolete/prism-common/project.properties - obsolete/prism-d3d-native/Makefile - obsolete/prism-d3d-native/nbproject/Makefile-Debug.mk - obsolete/prism-d3d-native/nbproject/Makefile-Release.mk - obsolete/prism-d3d-native/nbproject/Makefile-impl.mk - obsolete/prism-d3d-native/nbproject/Package-Debug.bash - obsolete/prism-d3d-native/nbproject/Package-Release.bash - obsolete/prism-d3d-native/nbproject/configurations.xml - obsolete/prism-d3d-native/nbproject/project.xml - obsolete/prism-d3d/build-closed.xml - obsolete/prism-d3d/build-common.xml - obsolete/prism-d3d/build.xml - obsolete/prism-d3d/nbproject/project.xml - obsolete/prism-d3d/prism-d3d.iml - obsolete/prism-d3d/project.properties - obsolete/prism-es2-eglfb/Prism-es2-eglfb.iml - obsolete/prism-es2-eglfb/build-closed.xml - obsolete/prism-es2-eglfb/build-common.xml - obsolete/prism-es2-eglfb/build.xml - obsolete/prism-es2-eglfb/manifest.mf - obsolete/prism-es2-eglfb/nbproject/build-impl.xml - obsolete/prism-es2-eglfb/nbproject/genfiles.properties - obsolete/prism-es2-eglfb/nbproject/project.properties - obsolete/prism-es2-eglfb/nbproject/project.xml - obsolete/prism-es2-eglfb/project.properties - obsolete/prism-es2-eglx11/build-closed.xml - obsolete/prism-es2-eglx11/build-common.xml - obsolete/prism-es2-eglx11/build.xml - obsolete/prism-es2-eglx11/manifest.mf - obsolete/prism-es2-eglx11/nbproject/build-impl.xml - obsolete/prism-es2-eglx11/nbproject/genfiles.properties - obsolete/prism-es2-eglx11/nbproject/project.properties - obsolete/prism-es2-eglx11/nbproject/project.xml - obsolete/prism-es2-eglx11/project.properties - obsolete/prism-es2-ios/build-closed.xml - obsolete/prism-es2-ios/build-common.xml - obsolete/prism-es2-ios/build.xml - obsolete/prism-es2-ios/nbproject/project.xml - obsolete/prism-es2-ios/project.properties - obsolete/prism-es2-mac/build-closed.xml - obsolete/prism-es2-mac/build-common.xml - obsolete/prism-es2-mac/build.xml - obsolete/prism-es2-mac/nbproject/project.xml - obsolete/prism-es2-mac/project.properties - obsolete/prism-es2-native/Android.mk - obsolete/prism-es2-native/Makefile - obsolete/prism-es2-native/nbproject/Makefile-Debug.mk - obsolete/prism-es2-native/nbproject/Makefile-Release.mk - obsolete/prism-es2-native/nbproject/Makefile-impl.mk - obsolete/prism-es2-native/nbproject/Makefile-variables.mk - obsolete/prism-es2-native/nbproject/configurations.xml - obsolete/prism-es2-native/nbproject/project.xml - obsolete/prism-es2-native/prism-es2-native.iml - obsolete/prism-es2-win/build-closed.xml - obsolete/prism-es2-win/build-common.xml - obsolete/prism-es2-win/build.xml - obsolete/prism-es2-win/nbproject/project.xml - obsolete/prism-es2-win/project.properties - obsolete/prism-es2-x11/build-closed.xml - obsolete/prism-es2-x11/build-common.xml - obsolete/prism-es2-x11/build.xml - obsolete/prism-es2-x11/nbproject/project.xml - obsolete/prism-es2-x11/project.properties - obsolete/prism-es2/build-android.xml - obsolete/prism-es2/build-closed.xml - obsolete/prism-es2/build-common.xml - obsolete/prism-es2/build-ios.xml - obsolete/prism-es2/build-linux.xml - obsolete/prism-es2/build-macosx.xml - obsolete/prism-es2/build-solaris.xml - obsolete/prism-es2/build-windows.xml - obsolete/prism-es2/build.xml - obsolete/prism-es2/nbproject/project.xml - obsolete/prism-es2/project.properties - obsolete/prism-j2d/build-closed.xml - obsolete/prism-j2d/build-common.xml - obsolete/prism-j2d/build.xml - obsolete/prism-j2d/nbproject/project.xml - obsolete/prism-j2d/prism-j2d.iml - obsolete/prism-j2d/project.properties - obsolete/prism-null/build-closed.xml - obsolete/prism-null/build-common.xml - obsolete/prism-null/build.xml - obsolete/prism-null/nbproject/project.xml - obsolete/prism-null/prism-null.iml - obsolete/prism-null/project.properties - obsolete/prism-ps/build-closed.xml - obsolete/prism-ps/build-common.xml - obsolete/prism-ps/build.xml - obsolete/prism-ps/nbproject/project.xml - obsolete/prism-ps/prism-ps.iml - obsolete/prism-ps/project.properties - obsolete/prism-sw-native/Makefile - obsolete/prism-sw-native/nbproject/Makefile-Debug.mk - obsolete/prism-sw-native/nbproject/Makefile-Release.mk - obsolete/prism-sw-native/nbproject/Makefile-impl.mk - obsolete/prism-sw-native/nbproject/Package-Debug.bash - obsolete/prism-sw-native/nbproject/Package-Release.bash - obsolete/prism-sw-native/nbproject/configurations.xml - obsolete/prism-sw-native/nbproject/project.xml - obsolete/prism-sw/build-closed.xml - obsolete/prism-sw/build-common.xml - obsolete/prism-sw/build-linux.xml - obsolete/prism-sw/build-macosx.xml - obsolete/prism-sw/build-solaris.xml - obsolete/prism-sw/build-windows.xml - obsolete/prism-sw/build.xml - obsolete/prism-sw/nbproject/project.xml - obsolete/prism-sw/prism-sw.iml - obsolete/prism-sw/project.properties - obsolete/prism-util/build-closed.xml - obsolete/prism-util/build-common.xml - obsolete/prism-util/build.xml - obsolete/prism-util/nbproject/project.xml - obsolete/test-stub-toolkit/build-closed.xml - obsolete/test-stub-toolkit/build.xml - obsolete/test-stub-toolkit/nbproject/project.xml - obsolete/test-stub-toolkit/pom.xml - obsolete/test-stub-toolkit/project.properties - obsolete/test-stub-toolkit/test-stub-toolkit.iml - obsolete/webview/build.xml - obsolete/webview/nbproject/project.xml - obsolete/webview/project.properties From hang.vo at oracle.com Wed Oct 16 11:03:32 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 16 Oct 2013 18:03:32 +0000 Subject: hg: openjfx/8/graphics/rt: ECLIPSE_ONLY: Work around Eclipse jdk8 compiler bug Message-ID: <20131016180400.6ACA562471@hg.openjdk.java.net> Changeset: 06bc50e76e8b Author: snorthov Date: 2013-10-16 13:52 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/06bc50e76e8b ECLIPSE_ONLY: Work around Eclipse jdk8 compiler bug ! modules/base/src/main/java/javafx/collections/transformation/SortedList.java From steve.x.northover at oracle.com Wed Oct 16 11:10:01 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 16 Oct 2013 14:10:01 -0400 Subject: Half-baked API (Camera position) In-Reply-To: <525EAF18.4080303@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> <525EAF18.4080303@oracle.com> Message-ID: <525ED679.70107@oracle.com> I took a quick look through JavaFX to find how this exception is used. It is mostly used to indicate impossible situation. Is that the situation we have here? Personally, for me, if we throw the exception, then we will generally just leave it that way forever. Steve On 2013-10-16 11:22 AM, Pavel Safrata wrote: > On 16.10.2013 17:03, Stephen F Northover wrote: >> Could do something useful with what was there now? We can always fix >> this in future by adding another API to govern the interpretation of >> the value. > > Not much useful. Anyway, any such stuff can be quite easily done by > reading the intersectedPoint's Z coordinate. > >> >> Throwing the exception indicates that the call is unsupported, but >> application code can be written to catch the exception and when we >> implement the API, it can break (I realize that this is unlikely). > > The exception can tell by the message that the operation will be > supported in the future. > > Pavel > >> >> Steve >> >> On 2013-10-16 10:46 AM, Richard Bair wrote: >>> My quick vote would be throwing the exception, but is like to hear >>> from Steve and Kevin. >>> >>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata >>>> wrote: >>>> >>>> Hello, >>>> it looks like we can't help releasing a not-fully-baked piece of >>>> API with FX8. We've added bunch of new APIs for 3D and did our best >>>> to make them work well. Unfortunately, there's been not enough >>>> time&priority to fine-tune their behavior in 2D world. Right now >>>> I'm concerned about camera position in scene. It is inherent in the >>>> 3D perspective camera that it has its specific position in world, >>>> but the 2D parallel camera as we have it projects everything to the >>>> XY plane basically by ignoring the Z coordinate, so the camera >>>> position doesn't matter all that much. However, some of the newly >>>> added APIs depend on it: >>>> >>>> 1. Near/far clip on camera. This obviously cannot work without >>>> knowing where the camera is. Right now the parallel camera does no >>>> clipping though, so I guess we are OK to go with it as a "known >>>> limitation". >>>> >>>> 2. PickResult on events which reports "intersectedDistance" between >>>> the camera and the picked point. This is worse because we can't >>>> just "not support" it - there will be some value and once somebody >>>> uses it we'll have a backward compatibility issue. The state right >>>> now is that the camera is (tentatively, by my arbitrary decision) >>>> at [0, 0, -1] and reports distances from there (note that as the >>>> camera renders everything, for nodes "in front of Z=-1" it reports >>>> negative distances). This may change when the camera position is >>>> properly discussed and specified. >>>> >>>> Note that this post is *not* meant to discuss the camera position. >>>> Even if we could find the answer quickly (which I doubt), it's most >>>> probably too late to apply the change for FX8. >>>> >>>> So finally here is my question: do you think it's OK to solve this >>>> by keeping the current behavior and documenting the >>>> "intersectedDistance" in a way that for parallel camera the numbers >>>> are unspecified and subject to change in future versions? Or would >>>> you prefer something more drastic like throwing an >>>> UnsupportedOperationException (losing the possibility to compare >>>> the distances)? >>>> >>>> Thanks, >>>> Pavel >> > From eva.krejcirova at oracle.com Wed Oct 16 12:07:13 2013 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 16 Oct 2013 21:07:13 +0200 Subject: Constructor annotation In-Reply-To: <525ECC96.8010805@oracle.com> References: <525E5ACC.1030103@oracle.com> <525E7674.9040108@bestsolution.at> <1E415F99-9EBD-47ED-A6A6-6509F0E48681@oracle.com> <525EA86B.2090208@oracle.com> <525EA99D.4090605@oracle.com> <525EACF6.6030607@bestsolution.at> <525EAFB0.9080500@bestsolution.at> <525EB3B8.8030705@oracle.com> <525EC69E.2070308@oracle.com> <58550C9D-F385-4CA6-B0F4-49A85C4270EC@oracle.com> <525ECC96.8010805@oracle.com> Message-ID: <525EE3E1.4080802@oracle.com> We already have RT-32860 (Add constructor annotations) for this. I've copied this discussion to the JIRA issue. Eva On 16.10.2013 19:27, Stephen F Northover wrote: > Eva, > > Perhaps @NamedArg is shorter and makes the code more readable? > > If you don't have a JIRA already, please create one and paste in this > discussion. Interested parties can add themselves to the watchers list. > > Steve > > On 2013-10-16 1:25 PM, Richard Bair wrote: >> Looks good to me. >> >>> On Oct 16, 2013, at 10:02 AM, Stephen F Northover >>> wrote: >>> >>> It seems we are settling on @NamedArgument ... anybody disagree >>> strongly? >>> >>> Steve >>> >>>> On 2013-10-16 11:45 AM, Richard Bair wrote: >>>> Ya that works too. >>>> >>>>> On Oct 16, 2013, at 8:41 AM, Eva Krejcirova >>>>> wrote: >>>>> >>>>> Good point! >>>>> In FX sources, we already use the @Default annotation which was >>>>> used by annotation processor when generating the builders. Because >>>>> of this, it has source retention policy, so it cannot be used by >>>>> FXMLLoader. I was thinking about promoting this to runtime >>>>> annotation but maybe your solution is better. >>>>> >>>>> We should solve this for FX8 otherwise the FXMLLoader will behave >>>>> differently from how the generated builders behaved. >>>>> >>>>> Eva >>>>> >>>>>> On 16.10.2013 17:24, Tom Schindl wrote: >>>>>> One thing that just came to my mind is that maybe also need a way to >>>>>> define the default value to be used, with a builder I could e.g. >>>>>> define >>>>>> that the default for fields are different from their real native >>>>>> default. >>>>>> >>>>>> class MyBuilder { >>>>>> private boolean a = true; >>>>>> private int x = -1; >>>>>> private Insets i = new Insets(10); >>>>>> } >>>>>> >>>>>> If we want to have a full replacement for builders the annotation >>>>>> must >>>>>> have the possibility define this (in future). >>>>>> >>>>>> public @interface NamedArgument { >>>>>> String value(); >>>>>> String defaultValue(); >>>>>> Class converterClass(); >>>>>> } >>>>>> >>>>>> If no converterClass is given we'd have to do our best to >>>>>> auto-convert >>>>>> the String. I don't want to say that we should implement the default >>>>>> value definition in FX8 but it would feel more natural with an >>>>>> annotation per argument. >>>>>> >>>>>> Tom >>>>>> >>>>>>> On 16.10.13 17:12, Tom Schindl wrote: >>>>>>> To me the JavaBean solution with one annotation looks error >>>>>>> prone, does >>>>>>> anybody know why they did not use an annotation per field? >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>>> On 16.10.13 16:58, Stephen F Northover wrote: >>>>>>>> +1 for base. Should we not follow closely what Java Beans is >>>>>>>> doing for >>>>>>>> consistency? I realize that we can't have the reference. >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>>> On 2013-10-16 10:53 AM, Kevin Rushforth wrote: >>>>>>>>> Not to mention Tom's point that it can't be in the fxml module >>>>>>>>> without >>>>>>>>> created unwanted (and circular) module dependencies. Seems >>>>>>>>> like it >>>>>>>>> needs to be in the "base" module then, right? >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Richard Bair wrote: >>>>>>>>>> +1 this is my preference. It is useful for things other than >>>>>>>>>> FXML, >>>>>>>>>> and should be considered part of our javafx.beans API. >>>>>>>>>> >>>>>>>>>>> On Oct 16, 2013, at 4:20 AM, Tom Schindl >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 16.10.13 11:22, Eva Krejcirova wrote: >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> when we retired builders, we caused a problem for FXML >>>>>>>>>>>> which doesn't >>>>>>>>>>>> have a way to create classes without default constructors. >>>>>>>>>>>> Back >>>>>>>>>>>> then we >>>>>>>>>>>> decided to use an annotation for this but never actually >>>>>>>>>>>> got to >>>>>>>>>>>> implement it and we need to fix this for FX8. I am in the >>>>>>>>>>>> process of >>>>>>>>>>>> adding this functionality to FXMLLoader but we need to >>>>>>>>>>>> decide how the >>>>>>>>>>>> annotation will look like and I could use some help with this. >>>>>>>>>>>> >>>>>>>>>>>> We cannot use already existing ConstructorProperties for >>>>>>>>>>>> this, because >>>>>>>>>>>> it's java.beans package and we don't want to create to >>>>>>>>>>>> dependency on >>>>>>>>>>>> this package in JavaFX, so we need to introduce a new >>>>>>>>>>>> annotation. >>>>>>>>>>>> >>>>>>>>>>>> We have two options: >>>>>>>>>>>> >>>>>>>>>>>> 1. Annotate the whole constructor: >>>>>>>>>>>> e.g. >>>>>>>>>>>> @ConstructorArguments({"a", "b", "list"}) >>>>>>>>>>>> public ImmutableClass(int a, int b, Integer... list) >>>>>>>>>>>> >>>>>>>>>>>> 2. Annotate the arguments: >>>>>>>>>>>> e.g. >>>>>>>>>>>> public ImmutableClass(@FXMLArgument("a") int a, >>>>>>>>>>>> @FXMLArgument("b")int b, @FXMLArgument("list")Integer... list) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Which option do you like more and how should the annotation >>>>>>>>>>>> be named? >>>>>>>>>>> Option 2, but does it really have to hold FXML in the >>>>>>>>>>> annotation name? >>>>>>>>>>> Where would you put the annotation? I think it should NOT be >>>>>>>>>>> in the >>>>>>>>>>> FXML-Package-Namespace because the core should NOT depend on >>>>>>>>>>> FXML! >>>>>>>>>>> >>>>>>>>>>> I'd go with @Argument or simply @NamedArgument (@Named is >>>>>>>>>>> already used >>>>>>>>>>> by javax.inject) >>>>>>>>>>> >>>>>>>>>>> Tom > From pavel.safrata at oracle.com Wed Oct 16 12:37:07 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 16 Oct 2013 21:37:07 +0200 Subject: Half-baked API (Camera position) In-Reply-To: <525ED679.70107@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> <525EAF18.4080303@oracle.com> <525ED679.70107@oracle.com> Message-ID: <525EEAE3.30700@oracle.com> As I've said, we intend to fix it in the future, so the situation should not be impossible. It is mostly used that way in the existing code, but there definitely are precedents for throwing it just temporarily. For instance: nodeOrientationProperty().getCssMetaData: throw new UnsupportedOperationException("Not supported yet."); or MeshView.impl_computeContains(): throw new UnsupportedOperationException("Not supported yet."); (internal but directly accessible to users via contains()) Pavel On 16.10.2013 20:10, Stephen F Northover wrote: > I took a quick look through JavaFX to find how this exception is used. > It is mostly used to indicate impossible situation. Is that the > situation we have here? > > Personally, for me, if we throw the exception, then we will generally > just leave it that way forever. > > Steve > > On 2013-10-16 11:22 AM, Pavel Safrata wrote: >> On 16.10.2013 17:03, Stephen F Northover wrote: >>> Could do something useful with what was there now? We can always >>> fix this in future by adding another API to govern the >>> interpretation of the value. >> >> Not much useful. Anyway, any such stuff can be quite easily done by >> reading the intersectedPoint's Z coordinate. >> >>> >>> Throwing the exception indicates that the call is unsupported, but >>> application code can be written to catch the exception and when we >>> implement the API, it can break (I realize that this is unlikely). >> >> The exception can tell by the message that the operation will be >> supported in the future. >> >> Pavel >> >>> >>> Steve >>> >>> On 2013-10-16 10:46 AM, Richard Bair wrote: >>>> My quick vote would be throwing the exception, but is like to hear >>>> from Steve and Kevin. >>>> >>>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata >>>>> wrote: >>>>> >>>>> Hello, >>>>> it looks like we can't help releasing a not-fully-baked piece of >>>>> API with FX8. We've added bunch of new APIs for 3D and did our >>>>> best to make them work well. Unfortunately, there's been not >>>>> enough time&priority to fine-tune their behavior in 2D world. >>>>> Right now I'm concerned about camera position in scene. It is >>>>> inherent in the 3D perspective camera that it has its specific >>>>> position in world, but the 2D parallel camera as we have it >>>>> projects everything to the XY plane basically by ignoring the Z >>>>> coordinate, so the camera position doesn't matter all that much. >>>>> However, some of the newly added APIs depend on it: >>>>> >>>>> 1. Near/far clip on camera. This obviously cannot work without >>>>> knowing where the camera is. Right now the parallel camera does no >>>>> clipping though, so I guess we are OK to go with it as a "known >>>>> limitation". >>>>> >>>>> 2. PickResult on events which reports "intersectedDistance" >>>>> between the camera and the picked point. This is worse because we >>>>> can't just "not support" it - there will be some value and once >>>>> somebody uses it we'll have a backward compatibility issue. The >>>>> state right now is that the camera is (tentatively, by my >>>>> arbitrary decision) at [0, 0, -1] and reports distances from there >>>>> (note that as the camera renders everything, for nodes "in front >>>>> of Z=-1" it reports negative distances). This may change when the >>>>> camera position is properly discussed and specified. >>>>> >>>>> Note that this post is *not* meant to discuss the camera position. >>>>> Even if we could find the answer quickly (which I doubt), it's >>>>> most probably too late to apply the change for FX8. >>>>> >>>>> So finally here is my question: do you think it's OK to solve this >>>>> by keeping the current behavior and documenting the >>>>> "intersectedDistance" in a way that for parallel camera the >>>>> numbers are unspecified and subject to change in future versions? >>>>> Or would you prefer something more drastic like throwing an >>>>> UnsupportedOperationException (losing the possibility to compare >>>>> the distances)? >>>>> >>>>> Thanks, >>>>> Pavel >>> >> > From steve.x.northover at oracle.com Wed Oct 16 13:06:09 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 16 Oct 2013 16:06:09 -0400 Subject: Half-baked API (Camera position) In-Reply-To: <525EEAE3.30700@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> <525EAF18.4080303@oracle.com> <525ED679.70107@oracle.com> <525EEAE3.30700@oracle.com> Message-ID: <525EF1B1.2070401@oracle.com> The problem is this: How is anyone supposed to ever do anything with this? I suppose they call the thing by mistake, get an exception and then never call it again. Then, later on, we come along and fix it. If the original people ever catch the exception and do something, then when we stop throwing the exception, they will be broken. Exceptions are API. I suppose the odds of people catching and exception like this and doing something are low but it is a possibility. I would rather do something sensible with it now as best we can and document it. In the future, if this turns out not to be a good thing, we add a new API that gives a better result (ie. intersectedDistance3D() or whatever). Steve On 2013-10-16 3:37 PM, Pavel Safrata wrote: > As I've said, we intend to fix it in the future, so the situation > should not be impossible. It is mostly used that way in the existing > code, but there definitely are precedents for throwing it just > temporarily. For instance: > > nodeOrientationProperty().getCssMetaData: > throw new UnsupportedOperationException("Not supported yet."); > > or > > MeshView.impl_computeContains(): > throw new UnsupportedOperationException("Not supported yet."); > (internal but directly accessible to users via contains()) > > Pavel > > On 16.10.2013 20:10, Stephen F Northover wrote: >> I took a quick look through JavaFX to find how this exception is >> used. It is mostly used to indicate impossible situation. Is that >> the situation we have here? >> >> Personally, for me, if we throw the exception, then we will generally >> just leave it that way forever. >> >> Steve >> >> On 2013-10-16 11:22 AM, Pavel Safrata wrote: >>> On 16.10.2013 17:03, Stephen F Northover wrote: >>>> Could do something useful with what was there now? We can always >>>> fix this in future by adding another API to govern the >>>> interpretation of the value. >>> >>> Not much useful. Anyway, any such stuff can be quite easily done by >>> reading the intersectedPoint's Z coordinate. >>> >>>> >>>> Throwing the exception indicates that the call is unsupported, but >>>> application code can be written to catch the exception and when we >>>> implement the API, it can break (I realize that this is unlikely). >>> >>> The exception can tell by the message that the operation will be >>> supported in the future. >>> >>> Pavel >>> >>>> >>>> Steve >>>> >>>> On 2013-10-16 10:46 AM, Richard Bair wrote: >>>>> My quick vote would be throwing the exception, but is like to hear >>>>> from Steve and Kevin. >>>>> >>>>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> it looks like we can't help releasing a not-fully-baked piece of >>>>>> API with FX8. We've added bunch of new APIs for 3D and did our >>>>>> best to make them work well. Unfortunately, there's been not >>>>>> enough time&priority to fine-tune their behavior in 2D world. >>>>>> Right now I'm concerned about camera position in scene. It is >>>>>> inherent in the 3D perspective camera that it has its specific >>>>>> position in world, but the 2D parallel camera as we have it >>>>>> projects everything to the XY plane basically by ignoring the Z >>>>>> coordinate, so the camera position doesn't matter all that much. >>>>>> However, some of the newly added APIs depend on it: >>>>>> >>>>>> 1. Near/far clip on camera. This obviously cannot work without >>>>>> knowing where the camera is. Right now the parallel camera does >>>>>> no clipping though, so I guess we are OK to go with it as a >>>>>> "known limitation". >>>>>> >>>>>> 2. PickResult on events which reports "intersectedDistance" >>>>>> between the camera and the picked point. This is worse because we >>>>>> can't just "not support" it - there will be some value and once >>>>>> somebody uses it we'll have a backward compatibility issue. The >>>>>> state right now is that the camera is (tentatively, by my >>>>>> arbitrary decision) at [0, 0, -1] and reports distances from >>>>>> there (note that as the camera renders everything, for nodes "in >>>>>> front of Z=-1" it reports negative distances). This may change >>>>>> when the camera position is properly discussed and specified. >>>>>> >>>>>> Note that this post is *not* meant to discuss the camera >>>>>> position. Even if we could find the answer quickly (which I >>>>>> doubt), it's most probably too late to apply the change for FX8. >>>>>> >>>>>> So finally here is my question: do you think it's OK to solve >>>>>> this by keeping the current behavior and documenting the >>>>>> "intersectedDistance" in a way that for parallel camera the >>>>>> numbers are unspecified and subject to change in future versions? >>>>>> Or would you prefer something more drastic like throwing an >>>>>> UnsupportedOperationException (losing the possibility to compare >>>>>> the distances)? >>>>>> >>>>>> Thanks, >>>>>> Pavel >>>> >>> >> > From kevin.rushforth at oracle.com Wed Oct 16 14:09:24 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Oct 2013 14:09:24 -0700 Subject: Half-baked API (Camera position) In-Reply-To: <525EEAE3.30700@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> <525EAF18.4080303@oracle.com> <525ED679.70107@oracle.com> <525EEAE3.30700@oracle.com> Message-ID: <525F0084.4030408@oracle.com> Would IllegalStateException be better here? Usually UOE is for operations that are simply not supported by the class in question. In this case, the operation is only unsupported if the camera on the scene (i.e., the state of an object) is of a certain type which can change at runtime. I'm OK either way, just want it to be a deliberate decision. -- Kevin Pavel Safrata wrote: > As I've said, we intend to fix it in the future, so the situation > should not be impossible. It is mostly used that way in the existing > code, but there definitely are precedents for throwing it just > temporarily. For instance: > > nodeOrientationProperty().getCssMetaData: > throw new UnsupportedOperationException("Not supported yet."); > > or > > MeshView.impl_computeContains(): > throw new UnsupportedOperationException("Not supported yet."); > (internal but directly accessible to users via contains()) > > Pavel > > On 16.10.2013 20:10, Stephen F Northover wrote: >> I took a quick look through JavaFX to find how this exception is >> used. It is mostly used to indicate impossible situation. Is that >> the situation we have here? >> >> Personally, for me, if we throw the exception, then we will generally >> just leave it that way forever. >> >> Steve >> >> On 2013-10-16 11:22 AM, Pavel Safrata wrote: >>> On 16.10.2013 17:03, Stephen F Northover wrote: >>>> Could do something useful with what was there now? We can always >>>> fix this in future by adding another API to govern the >>>> interpretation of the value. >>> >>> Not much useful. Anyway, any such stuff can be quite easily done by >>> reading the intersectedPoint's Z coordinate. >>> >>>> >>>> Throwing the exception indicates that the call is unsupported, but >>>> application code can be written to catch the exception and when we >>>> implement the API, it can break (I realize that this is unlikely). >>> >>> The exception can tell by the message that the operation will be >>> supported in the future. >>> >>> Pavel >>> >>>> >>>> Steve >>>> >>>> On 2013-10-16 10:46 AM, Richard Bair wrote: >>>>> My quick vote would be throwing the exception, but is like to hear >>>>> from Steve and Kevin. >>>>> >>>>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> it looks like we can't help releasing a not-fully-baked piece of >>>>>> API with FX8. We've added bunch of new APIs for 3D and did our >>>>>> best to make them work well. Unfortunately, there's been not >>>>>> enough time&priority to fine-tune their behavior in 2D world. >>>>>> Right now I'm concerned about camera position in scene. It is >>>>>> inherent in the 3D perspective camera that it has its specific >>>>>> position in world, but the 2D parallel camera as we have it >>>>>> projects everything to the XY plane basically by ignoring the Z >>>>>> coordinate, so the camera position doesn't matter all that much. >>>>>> However, some of the newly added APIs depend on it: >>>>>> >>>>>> 1. Near/far clip on camera. This obviously cannot work without >>>>>> knowing where the camera is. Right now the parallel camera does >>>>>> no clipping though, so I guess we are OK to go with it as a >>>>>> "known limitation". >>>>>> >>>>>> 2. PickResult on events which reports "intersectedDistance" >>>>>> between the camera and the picked point. This is worse because we >>>>>> can't just "not support" it - there will be some value and once >>>>>> somebody uses it we'll have a backward compatibility issue. The >>>>>> state right now is that the camera is (tentatively, by my >>>>>> arbitrary decision) at [0, 0, -1] and reports distances from >>>>>> there (note that as the camera renders everything, for nodes "in >>>>>> front of Z=-1" it reports negative distances). This may change >>>>>> when the camera position is properly discussed and specified. >>>>>> >>>>>> Note that this post is *not* meant to discuss the camera >>>>>> position. Even if we could find the answer quickly (which I >>>>>> doubt), it's most probably too late to apply the change for FX8. >>>>>> >>>>>> So finally here is my question: do you think it's OK to solve >>>>>> this by keeping the current behavior and documenting the >>>>>> "intersectedDistance" in a way that for parallel camera the >>>>>> numbers are unspecified and subject to change in future versions? >>>>>> Or would you prefer something more drastic like throwing an >>>>>> UnsupportedOperationException (losing the possibility to compare >>>>>> the distances)? >>>>>> >>>>>> Thanks, >>>>>> Pavel >>>> >>> >> > From kevin.rushforth at oracle.com Wed Oct 16 14:23:32 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Oct 2013 14:23:32 -0700 Subject: Half-baked API (Camera position) In-Reply-To: <525F0084.4030408@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> <525EAF18.4080303@oracle.com> <525ED679.70107@oracle.com> <525EEAE3.30700@oracle.com> <525F0084.4030408@oracle.com> Message-ID: <525F03D4.6070205@oracle.com> Steve: if Pavel throws IllegalStateException("not yet supported for parallel camera") or similar, do you think that would be OK or do you not want to see any exception? -- Kevin Kevin Rushforth wrote: > Would IllegalStateException be better here? Usually UOE is for > operations that are simply not supported by the class in question. In > this case, the operation is only unsupported if the camera on the > scene (i.e., the state of an object) is of a certain type which can > change at runtime. > > I'm OK either way, just want it to be a deliberate decision. > > -- Kevin > > > Pavel Safrata wrote: >> As I've said, we intend to fix it in the future, so the situation >> should not be impossible. It is mostly used that way in the existing >> code, but there definitely are precedents for throwing it just >> temporarily. For instance: >> >> nodeOrientationProperty().getCssMetaData: >> throw new UnsupportedOperationException("Not supported yet."); >> >> or >> >> MeshView.impl_computeContains(): >> throw new UnsupportedOperationException("Not supported yet."); >> (internal but directly accessible to users via contains()) >> >> Pavel >> >> On 16.10.2013 20:10, Stephen F Northover wrote: >>> I took a quick look through JavaFX to find how this exception is >>> used. It is mostly used to indicate impossible situation. Is that >>> the situation we have here? >>> >>> Personally, for me, if we throw the exception, then we will >>> generally just leave it that way forever. >>> >>> Steve >>> >>> On 2013-10-16 11:22 AM, Pavel Safrata wrote: >>>> On 16.10.2013 17:03, Stephen F Northover wrote: >>>>> Could do something useful with what was there now? We can always >>>>> fix this in future by adding another API to govern the >>>>> interpretation of the value. >>>> >>>> Not much useful. Anyway, any such stuff can be quite easily done by >>>> reading the intersectedPoint's Z coordinate. >>>> >>>>> >>>>> Throwing the exception indicates that the call is unsupported, but >>>>> application code can be written to catch the exception and when we >>>>> implement the API, it can break (I realize that this is unlikely). >>>> >>>> The exception can tell by the message that the operation will be >>>> supported in the future. >>>> >>>> Pavel >>>> >>>>> >>>>> Steve >>>>> >>>>> On 2013-10-16 10:46 AM, Richard Bair wrote: >>>>>> My quick vote would be throwing the exception, but is like to >>>>>> hear from Steve and Kevin. >>>>>> >>>>>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata >>>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> it looks like we can't help releasing a not-fully-baked piece of >>>>>>> API with FX8. We've added bunch of new APIs for 3D and did our >>>>>>> best to make them work well. Unfortunately, there's been not >>>>>>> enough time&priority to fine-tune their behavior in 2D world. >>>>>>> Right now I'm concerned about camera position in scene. It is >>>>>>> inherent in the 3D perspective camera that it has its specific >>>>>>> position in world, but the 2D parallel camera as we have it >>>>>>> projects everything to the XY plane basically by ignoring the Z >>>>>>> coordinate, so the camera position doesn't matter all that much. >>>>>>> However, some of the newly added APIs depend on it: >>>>>>> >>>>>>> 1. Near/far clip on camera. This obviously cannot work without >>>>>>> knowing where the camera is. Right now the parallel camera does >>>>>>> no clipping though, so I guess we are OK to go with it as a >>>>>>> "known limitation". >>>>>>> >>>>>>> 2. PickResult on events which reports "intersectedDistance" >>>>>>> between the camera and the picked point. This is worse because >>>>>>> we can't just "not support" it - there will be some value and >>>>>>> once somebody uses it we'll have a backward compatibility issue. >>>>>>> The state right now is that the camera is (tentatively, by my >>>>>>> arbitrary decision) at [0, 0, -1] and reports distances from >>>>>>> there (note that as the camera renders everything, for nodes "in >>>>>>> front of Z=-1" it reports negative distances). This may change >>>>>>> when the camera position is properly discussed and specified. >>>>>>> >>>>>>> Note that this post is *not* meant to discuss the camera >>>>>>> position. Even if we could find the answer quickly (which I >>>>>>> doubt), it's most probably too late to apply the change for FX8. >>>>>>> >>>>>>> So finally here is my question: do you think it's OK to solve >>>>>>> this by keeping the current behavior and documenting the >>>>>>> "intersectedDistance" in a way that for parallel camera the >>>>>>> numbers are unspecified and subject to change in future >>>>>>> versions? Or would you prefer something more drastic like >>>>>>> throwing an UnsupportedOperationException (losing the >>>>>>> possibility to compare the distances)? >>>>>>> >>>>>>> Thanks, >>>>>>> Pavel >>>>> >>>> >>> >> From steve.x.northover at oracle.com Wed Oct 16 14:44:49 2013 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Wed, 16 Oct 2013 17:44:49 -0400 Subject: Half-baked API (Camera position) In-Reply-To: <525F03D4.6070205@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> <525EAF18.4080303@oracle.com> <525ED679.70107@oracle.com> <525EEAE3.30700@oracle.com> <525F0084.4030408@oracle.com> <525F03D4.6070205@oracle.com> Message-ID: <525F08D1.9010809@oracle.com> Initial position: I don't really want to see any exception. Throwing an exception is unexpected and should really be reserved for when something bad happens, not when we can't decide how an API works. If the exception goes in, it's API and it stays forever. Steve On 2013-10-16 5:23 PM, Kevin Rushforth wrote: > Steve: if Pavel throws IllegalStateException("not yet supported for > parallel camera") or similar, do you think that would be OK or do you > not want to see any exception? > > -- Kevin > > > Kevin Rushforth wrote: >> Would IllegalStateException be better here? Usually UOE is for >> operations that are simply not supported by the class in question. In >> this case, the operation is only unsupported if the camera on the >> scene (i.e., the state of an object) is of a certain type which can >> change at runtime. >> >> I'm OK either way, just want it to be a deliberate decision. >> >> -- Kevin >> >> >> Pavel Safrata wrote: >>> As I've said, we intend to fix it in the future, so the situation >>> should not be impossible. It is mostly used that way in the existing >>> code, but there definitely are precedents for throwing it just >>> temporarily. For instance: >>> >>> nodeOrientationProperty().getCssMetaData: >>> throw new UnsupportedOperationException("Not supported yet."); >>> >>> or >>> >>> MeshView.impl_computeContains(): >>> throw new UnsupportedOperationException("Not supported yet."); >>> (internal but directly accessible to users via contains()) >>> >>> Pavel >>> >>> On 16.10.2013 20:10, Stephen F Northover wrote: >>>> I took a quick look through JavaFX to find how this exception is >>>> used. It is mostly used to indicate impossible situation. Is that >>>> the situation we have here? >>>> >>>> Personally, for me, if we throw the exception, then we will >>>> generally just leave it that way forever. >>>> >>>> Steve >>>> >>>> On 2013-10-16 11:22 AM, Pavel Safrata wrote: >>>>> On 16.10.2013 17:03, Stephen F Northover wrote: >>>>>> Could do something useful with what was there now? We can always >>>>>> fix this in future by adding another API to govern the >>>>>> interpretation of the value. >>>>> >>>>> Not much useful. Anyway, any such stuff can be quite easily done >>>>> by reading the intersectedPoint's Z coordinate. >>>>> >>>>>> >>>>>> Throwing the exception indicates that the call is unsupported, >>>>>> but application code can be written to catch the exception and >>>>>> when we implement the API, it can break (I realize that this is >>>>>> unlikely). >>>>> >>>>> The exception can tell by the message that the operation will be >>>>> supported in the future. >>>>> >>>>> Pavel >>>>> >>>>>> >>>>>> Steve >>>>>> >>>>>> On 2013-10-16 10:46 AM, Richard Bair wrote: >>>>>>> My quick vote would be throwing the exception, but is like to >>>>>>> hear from Steve and Kevin. >>>>>>> >>>>>>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> it looks like we can't help releasing a not-fully-baked piece >>>>>>>> of API with FX8. We've added bunch of new APIs for 3D and did >>>>>>>> our best to make them work well. Unfortunately, there's been >>>>>>>> not enough time&priority to fine-tune their behavior in 2D >>>>>>>> world. Right now I'm concerned about camera position in scene. >>>>>>>> It is inherent in the 3D perspective camera that it has its >>>>>>>> specific position in world, but the 2D parallel camera as we >>>>>>>> have it projects everything to the XY plane basically by >>>>>>>> ignoring the Z coordinate, so the camera position doesn't >>>>>>>> matter all that much. However, some of the newly added APIs >>>>>>>> depend on it: >>>>>>>> >>>>>>>> 1. Near/far clip on camera. This obviously cannot work without >>>>>>>> knowing where the camera is. Right now the parallel camera does >>>>>>>> no clipping though, so I guess we are OK to go with it as a >>>>>>>> "known limitation". >>>>>>>> >>>>>>>> 2. PickResult on events which reports "intersectedDistance" >>>>>>>> between the camera and the picked point. This is worse because >>>>>>>> we can't just "not support" it - there will be some value and >>>>>>>> once somebody uses it we'll have a backward compatibility >>>>>>>> issue. The state right now is that the camera is (tentatively, >>>>>>>> by my arbitrary decision) at [0, 0, -1] and reports distances >>>>>>>> from there (note that as the camera renders everything, for >>>>>>>> nodes "in front of Z=-1" it reports negative distances). This >>>>>>>> may change when the camera position is properly discussed and >>>>>>>> specified. >>>>>>>> >>>>>>>> Note that this post is *not* meant to discuss the camera >>>>>>>> position. Even if we could find the answer quickly (which I >>>>>>>> doubt), it's most probably too late to apply the change for FX8. >>>>>>>> >>>>>>>> So finally here is my question: do you think it's OK to solve >>>>>>>> this by keeping the current behavior and documenting the >>>>>>>> "intersectedDistance" in a way that for parallel camera the >>>>>>>> numbers are unspecified and subject to change in future >>>>>>>> versions? Or would you prefer something more drastic like >>>>>>>> throwing an UnsupportedOperationException (losing the >>>>>>>> possibility to compare the distances)? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Pavel >>>>>> >>>>> >>>> >>> From chien.yang at oracle.com Wed Oct 16 15:30:02 2013 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 16 Oct 2013 15:30:02 -0700 Subject: [API-REVIEW] RT-33211 - Fix TriangleMesh API to support a range of vertex format in the future Message-ID: <525F136A.40102@oracle.com> Hi all, We realized the existing TriangleMesh API is too restrictive to support additional vertex formats in the future, for examples, user specified normal and multi-texture units. We will need to make at least 2 changes to allow TriangleMesh be used for a range of vertex formats in the future: 1) The faces of TriangleMesh needs to be a new class that extends ObservableIntegerArray. We can then add methods (in the future) to provide views to the different components of the faces. 2) The following constants in TriangleMesh need to turn into instance methods: public static final int NUM_COMPONENTS_PER_POINT = 3; public static final int NUM_COMPONENTS_PER_TEXCOORD = 2; public static final int NUM_COMPONENTS_PER_FACE = 6; Changes made to TriangleMesh: - public static final int NUM_COMPONENTS_PER_POINT = 3; - public static final int NUM_COMPONENTS_PER_TEXCOORD = 2; - public static final int NUM_COMPONENTS_PER_FACE = 6; - public final ObservableIntegerArray getFaces() + public final ObservableFaceArray getFaces() Methods added to TriangleMesh: /** * Returns the number of elements that represents a Point. * * @return number of elements */ public final int getPointElementSize() /** * Returns the number of elements that represents a TexCoord. * * @return number of elements */ public final int getTexCoordElementSize() /** * Returns the number of elements that represents a Face. * * @return number of elements */ public final int getFaceElementSize() New Class: public interface ObservableFaceArray extends ObservableIntegerArray Note: This class adds no new methods or fields in JavaFX 8. Thanks, - Chien From kevin.rushforth at oracle.com Wed Oct 16 15:46:34 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Oct 2013 15:46:34 -0700 Subject: Half-baked API (Camera position) In-Reply-To: <525F08D1.9010809@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> <525EAF18.4080303@oracle.com> <525ED679.70107@oracle.com> <525EEAE3.30700@oracle.com> <525F0084.4030408@oracle.com> <525F03D4.6070205@oracle.com> <525F08D1.9010809@oracle.com> Message-ID: <525F174A.6080900@oracle.com> I can see your point. There are cases where it can make sense to have a restriction now and relax it later, but this isn't exactly that case. It's really more of a case of not being currently implemented correctly in some modes. I guess the other option (which Pavel also mentioned) is to continue to return something plausible, but not really correct, and file it as a bug against FX 8. -- Kevin Stephen F Northover wrote: > Initial position: > > I don't really want to see any exception. Throwing an exception is > unexpected and should really be reserved for when something bad > happens, not when we can't decide how an API works. If the exception > goes in, it's API and it stays forever. > > Steve > > On 2013-10-16 5:23 PM, Kevin Rushforth wrote: >> Steve: if Pavel throws IllegalStateException("not yet supported for >> parallel camera") or similar, do you think that would be OK or do you >> not want to see any exception? >> >> -- Kevin >> >> >> Kevin Rushforth wrote: >>> Would IllegalStateException be better here? Usually UOE is for >>> operations that are simply not supported by the class in question. >>> In this case, the operation is only unsupported if the camera on the >>> scene (i.e., the state of an object) is of a certain type which can >>> change at runtime. >>> >>> I'm OK either way, just want it to be a deliberate decision. >>> >>> -- Kevin >>> >>> >>> Pavel Safrata wrote: >>>> As I've said, we intend to fix it in the future, so the situation >>>> should not be impossible. It is mostly used that way in the >>>> existing code, but there definitely are precedents for throwing it >>>> just temporarily. For instance: >>>> >>>> nodeOrientationProperty().getCssMetaData: >>>> throw new UnsupportedOperationException("Not supported yet."); >>>> >>>> or >>>> >>>> MeshView.impl_computeContains(): >>>> throw new UnsupportedOperationException("Not supported yet."); >>>> (internal but directly accessible to users via contains()) >>>> >>>> Pavel >>>> >>>> On 16.10.2013 20:10, Stephen F Northover wrote: >>>>> I took a quick look through JavaFX to find how this exception is >>>>> used. It is mostly used to indicate impossible situation. Is that >>>>> the situation we have here? >>>>> >>>>> Personally, for me, if we throw the exception, then we will >>>>> generally just leave it that way forever. >>>>> >>>>> Steve >>>>> >>>>> On 2013-10-16 11:22 AM, Pavel Safrata wrote: >>>>>> On 16.10.2013 17:03, Stephen F Northover wrote: >>>>>>> Could do something useful with what was there now? We can >>>>>>> always fix this in future by adding another API to govern the >>>>>>> interpretation of the value. >>>>>> >>>>>> Not much useful. Anyway, any such stuff can be quite easily done >>>>>> by reading the intersectedPoint's Z coordinate. >>>>>> >>>>>>> >>>>>>> Throwing the exception indicates that the call is unsupported, >>>>>>> but application code can be written to catch the exception and >>>>>>> when we implement the API, it can break (I realize that this is >>>>>>> unlikely). >>>>>> >>>>>> The exception can tell by the message that the operation will be >>>>>> supported in the future. >>>>>> >>>>>> Pavel >>>>>> >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 2013-10-16 10:46 AM, Richard Bair wrote: >>>>>>>> My quick vote would be throwing the exception, but is like to >>>>>>>> hear from Steve and Kevin. >>>>>>>> >>>>>>>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> it looks like we can't help releasing a not-fully-baked piece >>>>>>>>> of API with FX8. We've added bunch of new APIs for 3D and did >>>>>>>>> our best to make them work well. Unfortunately, there's been >>>>>>>>> not enough time&priority to fine-tune their behavior in 2D >>>>>>>>> world. Right now I'm concerned about camera position in scene. >>>>>>>>> It is inherent in the 3D perspective camera that it has its >>>>>>>>> specific position in world, but the 2D parallel camera as we >>>>>>>>> have it projects everything to the XY plane basically by >>>>>>>>> ignoring the Z coordinate, so the camera position doesn't >>>>>>>>> matter all that much. However, some of the newly added APIs >>>>>>>>> depend on it: >>>>>>>>> >>>>>>>>> 1. Near/far clip on camera. This obviously cannot work without >>>>>>>>> knowing where the camera is. Right now the parallel camera >>>>>>>>> does no clipping though, so I guess we are OK to go with it as >>>>>>>>> a "known limitation". >>>>>>>>> >>>>>>>>> 2. PickResult on events which reports "intersectedDistance" >>>>>>>>> between the camera and the picked point. This is worse because >>>>>>>>> we can't just "not support" it - there will be some value and >>>>>>>>> once somebody uses it we'll have a backward compatibility >>>>>>>>> issue. The state right now is that the camera is (tentatively, >>>>>>>>> by my arbitrary decision) at [0, 0, -1] and reports distances >>>>>>>>> from there (note that as the camera renders everything, for >>>>>>>>> nodes "in front of Z=-1" it reports negative distances). This >>>>>>>>> may change when the camera position is properly discussed and >>>>>>>>> specified. >>>>>>>>> >>>>>>>>> Note that this post is *not* meant to discuss the camera >>>>>>>>> position. Even if we could find the answer quickly (which I >>>>>>>>> doubt), it's most probably too late to apply the change for FX8. >>>>>>>>> >>>>>>>>> So finally here is my question: do you think it's OK to solve >>>>>>>>> this by keeping the current behavior and documenting the >>>>>>>>> "intersectedDistance" in a way that for parallel camera the >>>>>>>>> numbers are unspecified and subject to change in future >>>>>>>>> versions? Or would you prefer something more drastic like >>>>>>>>> throwing an UnsupportedOperationException (losing the >>>>>>>>> possibility to compare the distances)? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Pavel >>>>>>> >>>>>> >>>>> >>>> > From richard.bair at oracle.com Wed Oct 16 17:21:28 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 16 Oct 2013 17:21:28 -0700 Subject: Half-baked API (Camera position) In-Reply-To: <525F174A.6080900@oracle.com> References: <525E488B.40105@oracle.com> <525EAAD5.3050808@oracle.com> <525EAF18.4080303@oracle.com> <525ED679.70107@oracle.com> <525EEAE3.30700@oracle.com> <525F0084.4030408@oracle.com> <525F03D4.6070205@oracle.com> <525F08D1.9010809@oracle.com> <525F174A.6080900@oracle.com> Message-ID: <631B5788-C2CB-4BD5-ABC6-BF339DFEE830@oracle.com> I don't see how returning something wrong is any different than throwing an exception from a compatibility perspective. Bugs are bugs. On Oct 16, 2013, at 3:46 PM, Kevin Rushforth wrote: > I can see your point. There are cases where it can make sense to have a restriction now and relax it later, but this isn't exactly that case. It's really more of a case of not being currently implemented correctly in some modes. > > I guess the other option (which Pavel also mentioned) is to continue to return something plausible, but not really correct, and file it as a bug against FX 8. > > -- Kevin > > > Stephen F Northover wrote: >> Initial position: >> >> I don't really want to see any exception. Throwing an exception is unexpected and should really be reserved for when something bad happens, not when we can't decide how an API works. If the exception goes in, it's API and it stays forever. >> >> Steve >> >> On 2013-10-16 5:23 PM, Kevin Rushforth wrote: >>> Steve: if Pavel throws IllegalStateException("not yet supported for parallel camera") or similar, do you think that would be OK or do you not want to see any exception? >>> >>> -- Kevin >>> >>> >>> Kevin Rushforth wrote: >>>> Would IllegalStateException be better here? Usually UOE is for operations that are simply not supported by the class in question. In this case, the operation is only unsupported if the camera on the scene (i.e., the state of an object) is of a certain type which can change at runtime. >>>> >>>> I'm OK either way, just want it to be a deliberate decision. >>>> >>>> -- Kevin >>>> >>>> >>>> Pavel Safrata wrote: >>>>> As I've said, we intend to fix it in the future, so the situation should not be impossible. It is mostly used that way in the existing code, but there definitely are precedents for throwing it just temporarily. For instance: >>>>> >>>>> nodeOrientationProperty().getCssMetaData: >>>>> throw new UnsupportedOperationException("Not supported yet."); >>>>> >>>>> or >>>>> >>>>> MeshView.impl_computeContains(): >>>>> throw new UnsupportedOperationException("Not supported yet."); >>>>> (internal but directly accessible to users via contains()) >>>>> >>>>> Pavel >>>>> >>>>> On 16.10.2013 20:10, Stephen F Northover wrote: >>>>>> I took a quick look through JavaFX to find how this exception is used. It is mostly used to indicate impossible situation. Is that the situation we have here? >>>>>> >>>>>> Personally, for me, if we throw the exception, then we will generally just leave it that way forever. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 2013-10-16 11:22 AM, Pavel Safrata wrote: >>>>>>> On 16.10.2013 17:03, Stephen F Northover wrote: >>>>>>>> Could do something useful with what was there now? We can always fix this in future by adding another API to govern the interpretation of the value. >>>>>>> >>>>>>> Not much useful. Anyway, any such stuff can be quite easily done by reading the intersectedPoint's Z coordinate. >>>>>>> >>>>>>>> >>>>>>>> Throwing the exception indicates that the call is unsupported, but application code can be written to catch the exception and when we implement the API, it can break (I realize that this is unlikely). >>>>>>> >>>>>>> The exception can tell by the message that the operation will be supported in the future. >>>>>>> >>>>>>> Pavel >>>>>>> >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> On 2013-10-16 10:46 AM, Richard Bair wrote: >>>>>>>>> My quick vote would be throwing the exception, but is like to hear from Steve and Kevin. >>>>>>>>> >>>>>>>>>> On Oct 16, 2013, at 1:04 AM, Pavel Safrata wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> it looks like we can't help releasing a not-fully-baked piece of API with FX8. We've added bunch of new APIs for 3D and did our best to make them work well. Unfortunately, there's been not enough time&priority to fine-tune their behavior in 2D world. Right now I'm concerned about camera position in scene. It is inherent in the 3D perspective camera that it has its specific position in world, but the 2D parallel camera as we have it projects everything to the XY plane basically by ignoring the Z coordinate, so the camera position doesn't matter all that much. However, some of the newly added APIs depend on it: >>>>>>>>>> >>>>>>>>>> 1. Near/far clip on camera. This obviously cannot work without knowing where the camera is. Right now the parallel camera does no clipping though, so I guess we are OK to go with it as a "known limitation". >>>>>>>>>> >>>>>>>>>> 2. PickResult on events which reports "intersectedDistance" between the camera and the picked point. This is worse because we can't just "not support" it - there will be some value and once somebody uses it we'll have a backward compatibility issue. The state right now is that the camera is (tentatively, by my arbitrary decision) at [0, 0, -1] and reports distances from there (note that as the camera renders everything, for nodes "in front of Z=-1" it reports negative distances). This may change when the camera position is properly discussed and specified. >>>>>>>>>> >>>>>>>>>> Note that this post is *not* meant to discuss the camera position. Even if we could find the answer quickly (which I doubt), it's most probably too late to apply the change for FX8. >>>>>>>>>> >>>>>>>>>> So finally here is my question: do you think it's OK to solve this by keeping the current behavior and documenting the "intersectedDistance" in a way that for parallel camera the numbers are unspecified and subject to change in future versions? Or would you prefer something more drastic like throwing an UnsupportedOperationException (losing the possibility to compare the distances)? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Pavel >>>>>>>> >>>>>>> >>>>>> >>>>> >> From tobi at ultramixer.com Thu Oct 17 01:17:21 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Thu, 17 Oct 2013 10:17:21 +0200 Subject: GlassScene: setSecurityContext() Message-ID: <9CC7DE3E-401D-4328-97BA-5307B17CBF27@ultramixer.com> Hi, why do you introduced the security concept in GlassScene and GlassStage? setSecurityContext() What is the goal? The problem is the used class sun.misc.SharedSecrets is not available in the android class library. Altough I have added it to the robovm compat lib I?m getting a security error and are not able to start the app on iOS. Tobi From haenel at ultramixer.com Thu Oct 17 01:41:26 2013 From: haenel at ultramixer.com (=?windows-1252?Q?Matthias_H=E4nel?=) Date: Thu, 17 Oct 2013 10:41:26 +0200 Subject: GlassScene: setSecurityContext() In-Reply-To: <9CC7DE3E-401D-4328-97BA-5307B17CBF27@ultramixer.com> References: <9CC7DE3E-401D-4328-97BA-5307B17CBF27@ultramixer.com> Message-ID: <0DA8AB4D-0269-42A5-9848-437709B249FA@ultramixer.com> Hey Tobi, yes, I faced the same on the Android port. After uncommenting the new security stuff in GlassStage and GlassScene it's working again. This is just a preliminary solution. @Oracle is there a legal way that we can use parts of the jdk8 rt.jar? regards Matthias Am 17.10.2013 um 10:17 schrieb Tobias Bley : > Hi, > > why do you introduced the security concept in GlassScene and GlassStage? setSecurityContext() > > What is the goal? > > The problem is the used class sun.misc.SharedSecrets is not available in the android class library. Altough I have added it to the robovm compat lib I?m getting a security error and are not able to start the app on iOS. > > Tobi > From hang.vo at oracle.com Thu Oct 17 06:18:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 17 Oct 2013 13:18:03 +0000 Subject: hg: openjfx/8/graphics/rt: RT-33455: Exception in layout pass locks up Toolkit pulsing. Message-ID: <20131017131932.AC157624AF@hg.openjdk.java.net> Changeset: 4b61c659d696 Author: art Date: 2013-10-17 17:06 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4b61c659d696 RT-33455: Exception in layout pass locks up Toolkit pulsing. Reviewed-by: alexz, kcr ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java From haenel at ultramixer.com Thu Oct 17 08:01:45 2013 From: haenel at ultramixer.com (=?iso-8859-1?Q?Matthias_H=E4nel?=) Date: Thu, 17 Oct 2013 17:01:45 +0200 Subject: JAVAFX on ANDROID In-Reply-To: <72E7A9DA-1D60-49BD-B04E-2DD8067BB5EB@ultramixer.com> References: <8A57C188-7C0E-4F5D-96EA-93F6A11642DF@ultramixer.com> <52570796.8050506@oracle.com> <52571A7F.5010309@bestsolution.at> <525783F6.4090309@oracle.com> <83C51C14-BECA-40B5-8E85-AAC3010B3B3C@ultramixer.com> <525825B0.604@bestsolution.at> <52593AEA.8070800@oracle.com> <8651A91C-A0F1-4DC7-8C7A-48CFD5EC216F@ultramixer.com> <525BE40D.6090808@oracle.com> <72E7A9DA-1D60-49BD-B04E-2DD8067BB5EB@ultramixer.com> Message-ID: <228EAB64-F405-4525-9E62-C89DDA002554@ultramixer.com> Hi, I found the reason for the touch crashes on Android. It's a JNI threading error in the current implementation. We have to enqueue the touch events into the javafx dispatch thread. There is a workaround for this attached in the java source file at dispatchTouchEvent and dispatchKeyEvent. What is the best way to propose changes in the future? regards Matthias -------------- next part -------------- Am 15.10.2013 um 13:50 schrieb Matthias H?nel : > Hey Tomas, > > > I've seen a check-in for RT-32802. This seems to be your fix. There are a lot of interface changes. > Could you explain the changes a bit, so I can merge it by hand into my jfx678 code? Today, I merged > from Stefans b111 JFX78 but it will take a while to get your changes through this way ;) > > > regards > Matthias > > > > Am 14.10.2013 um 14:31 schrieb tomas.brandalik : > >> Hi Matthias, >> cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA8888 in emulator. But that could have changed overtime. >> Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. >> In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. >> >> good luck >> -Tomas >> >> On 10/14/2013 01:45 PM, Matthias H?nel wrote: >>> Hi Tomas, >>> >>> >>> never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. >>> >>> So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. >>> >>> There are two things missing: >>> 1. fonts - here we probably need to get pango working for Android right? >>> 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative >>> This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. >>> >>> After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. >>> >>> >>> kind regards >>> Matthias >>> >>> >>> >>> Am 14.10.2013 um 12:17 schrieb Matthias H?nel : >>> >>>> Hi Tomas, >>>> >>>> >>>> since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. >>>> We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. >>>> >>>> 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin >>>> 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. >>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>> 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) >>>> 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API >>>> 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) >>>> 10-14 06:06:49.599: ERROR/libEGL(1546): c