From james.graham at oracle.com Thu Aug 1 00:03:22 2013 From: james.graham at oracle.com (Jim Graham) Date: Thu, 01 Aug 2013 00:03:22 -0700 Subject: API Change Proposal - Re: MSAA and Scene anti aliasing In-Reply-To: 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> <4693F16F-E56B-46B1-826B-70CC24F7F3E8@oracle.com> <51F05022.1080207@oracle.com> <51F9753D.9040201@oracle.com> <51F98DF3.6040604@oracle.com> <51F99F65.1020609@oracle.com> Message-ID: <51FA083A.8060801@oracle.com> +1 Constants good enough for now. First pass doesn't really need subclasses since the 4 constants we start with are virtual and somewhat opaque, but we could put them in for grins if we want. But, when we start making the different AA types selectable and parameterized then I think we want to have subclasses at that point. The concepts of "where are the subsamples taken" (both in respect to the positioning of the N sub-samples that determine coverage and also which of them, if any, are used to execute the shader) in MSAA have no bearing on FSAA, for example. Trying to mix and match disparate descriptive parameters in a single class gets awkward... ...jim On 7/31/13 5:09 PM, Richard Bair wrote: > Sorry let me be clear. Having a class vs an enum was my preferred approach and I'm glad with Jim's nudge it looks like we'll go there. Having just the few predefined constants as a starting point I think is good, and we can add sub-types and more goodness in the future. > > Richard > > On Jul 31, 2013, at 4:47 PM, Richard Bair wrote: > >> I'm pretty confident we'll want different sub-types as we go along (CSAA, MSAA, FXAA -- there are a lot of different ways to do full-scene anti-aliasing and I bet that they will have different parameters for controlling their various algorithms), but we can cross that bridge later. >> >> Richard >> >> On Jul 31, 2013, at 4:36 PM, Chien Yang wrote: >> >>> I agree, however I would prefer a single class over subclasses if possible. I have added Jim's proposal to the JIRA for consideration. >>> >>> https://javafx-jira.kenai.com/browse/RT-31878 >>> >>> Thanks, >>> - Chien >>> >>> >>> >>> On 7/31/2013 3:21 PM, Kevin Rushforth wrote: >>>> This seems cleaner in terms of extensibility. I think we can wait on adding anything other than the public static finals for this release, but plan to extend it using something like what Jim suggests. >>>> >>>> -- Kevin >>>> >>>> >>>> Richard Bair wrote: >>>>> Personally I liked this approach. It was like an enum in ease of use but much more extensible in the future when we add more anti-aliasing types and twiddles. >>>>> >>>>> Richard >>>>> >>>>> On Jul 31, 2013, at 1:36 PM, Jim Graham wrote: >>>>> >>>>>> D'oh! I knew I should have been checking this list a bit. I hope this isn't too late to have any impact... >>>>>> >>>>>> As an intermediate solution this is fine, but when we want to get into providing settings for MSAA and FSAA and other algorithms I think classes are more flexible than enums. How about this solution: >>>>>> >>>>>> package javafx.? >>>>>> >>>>>> public class SceneAntialiasing { >>>>>> public static final SceneAntialiasing DISABLED; >>>>>> public static final SceneAntialiasing BALANCED; >>>>>> public static final SceneAntialiasing FASTEST; >>>>>> public static final SceneAntialiasing NICEST; >>>>>> >>>>>> public static SceneAntialiasing[] getAvailableTechniques() { } >>>>>> >>>>>> SceneAntialiasing() { /* package private constructor! */ } >>>>>> } >>>>>> >>>>>> public class MsaaAntialiasing extends SceneAntialiasing { >>>>>> MSaaAntialiasing(int numsamp) { /* package private */ } >>>>>> public int getNumSamples(); >>>>>> } >>>>>> >>>>>> public class FsaaAntialiasing extends SceneAntialiasing { >>>>>> FsaaAntialiasing(int numsamp) { /* package private */ } >>>>>> public int getNumSamples(); >>>>>> } >>>>>> >>>>>> Note that there are ways for the system to construct these objects without providing public constructors so that these become statically defined by the system. >>>>>> >>>>>> What about Anisotropic filtering? Is that considered a form of AA, or an option on top of AA? >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 7/24/2013 3:07 PM, Chien Yang wrote: >>>>>>> Thanks for the help! I was of 2 minds about it; alphabetical or logical. >>>>>>> >>>>>>> public enum SceneAntiAliasing { >>>>>>> DISABLED, // disables anti-aliasing >>>>>>> BALANCED, // enables anti-aliasing using optimal 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 >>>>>>> } >>>>>>> >>>>>>> - Chien >>>>>>> >>>>>>> On 7/24/2013 2:49 PM, Richard Bair wrote: >>>>>>>> Just to be picky, I would put DISABLED first in the list. It seems more consistent to have the only OFF mode to be first and then all the rest of the options (which happen to then have ordinals > 0) will be some form of ON mode. >>>>>>>> >>>>>>>> Richard >>>>>>>> >>>>>>>> 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 tomas.brandalik at oracle.com Thu Aug 1 00:13:10 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Thu, 01 Aug 2013 09:13:10 +0200 Subject: current state of gradle script for Android? In-Reply-To: References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> Message-ID: <51FA0A86.3000003@oracle.com> Although I haven't has hardware to test it, I suppose it builds on mac, as well. It doesn't build on windows due to a problems in decora part of gradle build script. -Tomas On 07/31/2013 04:50 PM, Tobias Bley wrote: > Thanks Tomas, > > So currently it?s not possible to build OpenJFX for Android on Mac OS X, isn?t it? > > Tobi > > > Am 31.07.2013 um 16:42 schrieb tomas.brandalik : > >> Hi Tobi, >> it works on linux only right now. >> Set properties for cross build and android sdk/ndk. >> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >> Closed source parts web and font-t2k will be missing. >> >> -Tomas >> >> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>> Hi, >>> >>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>> >>> Best regards, >>> Tobi >>> From tom.schindl at bestsolution.at Thu Aug 1 01:39:06 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 01 Aug 2013 10:39:06 +0200 Subject: JavaFX and iOS - it will remain a dream In-Reply-To: References: <48A47A75-7C7A-429E-9833-2BF1C47B2CEE@ultramixer.com> <67FFC84C-EF91-4C29-B815-D8B804C9A231@bestsolution.at> Message-ID: <51FA1EAA.7010308@bestsolution.at> Hi, If you want to take a look at the sources, they are available at http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/tooling/org.eclipse.fx.ide.fxml.compiler. Code is written in xtend - don't judge the code yet, I simply want something going. The process of the conversion looks like this: FXML => Internal Memory Model => Java ^ ^ SaxParser Converter So I think your request to have different languages as output is possible by implementing e.g. a JavaScript converter. For you second request: Yes there's a helper class named ExtendedFXMLLoader which you feed a FXML-Path and which at first tries to load a compiled class and falling back to FXML if not found (see attached sample). The "biggest" problem I have with Controller-Fields and Methods who are NOT public or package private (depends on the location of the FXML relative to its controller) because there I still need to use reflection. Anyone a good idea to get around reflection in case I can't directly access them? For the initial version I'll simply immediately fallback to reflection and we could get smarter later on. I'll expect a first version which supports the most basic stuff to get out in the next few days. Attached you see my current state. You'll notice the most basic things already work: * Simple properties * Sub-Trees including default properties * Static properties * Properties who need to be created through Builders But naturally there's still a lot left to do ;-) Tom On 31.07.13 16:42, Danno Ferrin wrote: > Where is the code base for this converter? Done properly it can also be > written to spit out the generated stubs, as well as output in any > language the user may prefer. A top grade implementation could > integrate with FXMLLoader for a seamless experience ala .bss files. > > On Tuesday, July 30, 2013, Tom Schindl wrote: > > I don't think it is a good idea to use fxml on embedded and mobile, > we are working on a fxml => java converter so you can add it to your > build process. > > Tom > > Von meinem iPhone gesendet > > Am 31.07.2013 um 08:11 schrieb Niklas Therning >: > > >>>> after many days trying to really build iOS apps with JavaFX and > RoboVM > >> or > >>>> Avian I?m very frustrated because of the following things: > >>>> > >>>> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don?t > know > >> the > >>>> reason - maybe it?s the rendering model of JavaFX - maybe it?s the > >>>> currently unoptimized RoboVM > >>>> One big problem of RoboVM is it?s dependence of the Android > library, it > >>>> does not support the OpenJDK. That?s a big reason for many many > >> problems > >>>> when using JavaFX. So currently it?s not possible to use fxml files > >>>> (FXMLoader) because of the missing Stax xml parser and classes like > >>>> XMLInputFactory in the android library? > > > > There's now a compatibility library for the jfx78 backport which > includes > > the missing sun.* classes from OpenJDK [1]. So that will not be a > problem > > when running on RoboVM/Android. Daniel Zwolenski is working on > getting this > > into Maven which will make it nice and easy to develop with > RoboVM+OpenJFX. > > > > FXMLLoader relies an StAX and the Java Scripting API. Those can > both be > > made to work on RoboVM/Android. The POM of the compat project [1] > contains > > optional dependencies on the StAX API and JSR 223 API. For StAX > you'll also > > need a StAX provider [2][3]. For scripting you'll need a JSR 223 > > implementation of the scripting language you're using, like Rhino for > > JavaScript [4][5]. Please note that I haven't tested FXML but it > should > > work (in theory at least ;-) ). Please give it a go. It will be a > great > > blog story if you can make it work on iOS. > > > > As for the performance issues with RoboVM+OpenJFX: those WILL be > addressed! > > You can either wait for it to happen or you can help out. One way > to do > > that would be sample code that exercises the code paths that need > to be > > optimized (e.g. the button rendering you posted about earlier). > Preferably > > the sample should run repeatedly without user interaction. You > should then > > be able to run Apple's Instruments application to profile this > sample. This > > will help us determine what needs to be optimized. > > > > /Niklas > > > > [1] https://github.com/robovm/robovm-jfx78-compat > > [2] https://github.com/FasterXML/aalto-xml > > [3] http://woodstox.codehaus.org/ > > [4] https://developer.mozilla.org/en-US/docs/Rhino > > [5] > > > https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236 > -------------- next part -------------- package test; import java.io.IOException; import org.eclipse.fx.core.fxml.ExtendedFXMLLoader; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class CompiledTest extends Application { @Override public void start(Stage primaryStage) { ExtendedFXMLLoader l = new ExtendedFXMLLoader(); try { BorderPane p = l.load(getClass().getClassLoader(), "test/Sample.fxml"); Scene s = new Scene(p,300,300); primaryStage.setScene(s); primaryStage.show(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } public static void main(String[] args) { launch(args); } } -------------- next part -------------- package test; import org.eclipse.fx.core.fxml.FXMLDocument; import java.util.ResourceBundle; import java.lang.*; import javafx.geometry.Insets; import javafx.scene.control.Button; import javafx.scene.control.Label; import javafx.scene.layout.BorderPane; import javafx.scene.layout.GridPane; import javafx.scene.layout.HBox; import javafx.scene.layout.VBox; import javafx.geometry.InsetsBuilder; public class Sample extends FXMLDocument { public BorderPane load(ResourceBundle bundle) { BorderPane root = new BorderPane(); { Button e_1 = new Button(); e_1.setText("Hello World"); root.setCenter(e_1); } { HBox e_2 = new HBox(); { Label e_3 = new Label(); e_3.setText("Label 1"); e_3.setMinWidth(100); e_2.getChildren().add(e_3); HBox.setHgrow(e_3,javafx.scene.layout.Priority.ALWAYS); } { Label e_4 = new Label(); e_4.setText("Label 1"); e_2.getChildren().add(e_4); Insets e_5; InsetsBuilder e_5Builder = InsetsBuilder.create(); e_5Builder.bottom(5); e_5 = e_5Builder.build(); HBox.setMargin(e_4,e_5); } { VBox e_6 = new VBox(); { Label e_7 = new Label(); e_7.setText("Def 1"); e_6.getChildren().add(e_7); } { Label e_8 = new Label(); e_8.setText("Def 2"); e_6.getChildren().add(e_8); } e_2.getChildren().add(e_6); } { VBox e_9 = new VBox(); { Label e_10 = new Label(); e_10.setText("Label 1"); e_9.getChildren().add(e_10); VBox.setVgrow(e_10,javafx.scene.layout.Priority.SOMETIMES); } { GridPane e_11 = new GridPane(); { Label e_12 = new Label(); e_12.setText("In Grid 0/0"); e_11.getChildren().add(e_12); GridPane.setColumnIndex(e_12,0); GridPane.setRowIndex(e_12,0); } { Label e_13 = new Label(); e_13.setText("In Grid 0/1"); e_11.getChildren().add(e_13); GridPane.setColumnIndex(e_13,0); GridPane.setRowIndex(e_13,1); } e_9.getChildren().add(e_11); } e_2.getChildren().add(e_9); } root.setBottom(e_2); } return root; } } From hang.vo at oracle.com Thu Aug 1 02:18:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 09:18:08 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130801091901.2C221484EE@hg.openjdk.java.net> Changeset: 2ad0bb31c1bc Author: peterz Date: 2013-08-01 12:17 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2ad0bb31c1bc RT-32010 Gradle build fails with BINARY_STUB ! build.gradle ! buildSrc/linux.gradle Changeset: 49a2c50e80dc Author: Martin Sladecek Date: 2013-08-01 10:54 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/49a2c50e80dc RT-32001 SubScene is broken in recent code merge for 8.0-b99 ! 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/SubScene.java ! modules/graphics/src/stub/java/javafx/scene/SubSceneTest.java From javafx at olifanz.com Thu Aug 1 02:56:28 2013 From: javafx at olifanz.com (Gaja Sutra) Date: Thu, 01 Aug 2013 11:56:28 +0200 Subject: JavaFX and iOS - it will remain a dream In-Reply-To: <51FA1EAA.7010308@bestsolution.at> References: <48A47A75-7C7A-429E-9833-2BF1C47B2CEE@ultramixer.com> <67FFC84C-EF91-4C29-B815-D8B804C9A231@bestsolution.at> <51FA1EAA.7010308@bestsolution.at> Message-ID: <51FA30CC.7080905@olifanz.com> Depending of security requirements on the deployed code (like in an application not loading untrusted code), an hammer method can be useful: relaxing access rights on @FXML-annotated fields and methods to allow public access. It would need a preprocessing of application bytecode to change these access rights, before compiling FXML and integrating these supplementary classes. This can be implemented with a bytecode toolkit like ASM (largely used in OpenJDK): http://asm.ow2.org/ Gaja. > The "biggest" problem I have with Controller-Fields and Methods who are > NOT public or package private (depends on the location of the FXML > relative to its controller) because there I still need to use > reflection. Anyone a good idea to get around reflection in case I can't > directly access them? From toni.epple at eppleton.de Thu Aug 1 03:21:06 2013 From: toni.epple at eppleton.de (Anton Epple) Date: Thu, 1 Aug 2013 12:21:06 +0200 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> Message-ID: <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> Great idea, there's a site that does the same for NetBeans Platform Apps: https://platform.netbeans.org/screenshots.html I can tell from my own experience that it helps a lot in discussions with customers to show them that NASA, NATO, Boeing, UNO, US Army, and many others are building on top of NB Platform. From the maintainer of this site, I know there's a lot of work involved though, and you have to be very active in identifying users, and reaching out to them. It's definitely not sufficient to wait for users to submit their applications. Sometimes it can take a couple of years from first contact to a screenshot. That said it's absolutely worth it, and I would volunteer to help in any way I can. Toni -- Anton Epple Am 28.07.2013 um 02:38 schrieb Jonathan Giles : > This is something that Jasper actually brought up just this morning with Richard and I (wrt fxexperience hosting it). I suspect we may get something underway in the coming weeks. Of course, it depends on the community getting in touch with us and letting us talk about them - so much of the JavaFX world is behind corporate firewalls, where talking about your work is generally frowned upon. In any case, for those of you that can talk about your work, please email one of us off-list. > -- Jonathan > Sent from a touch device. Please excuse my brevity. > > "John C. Turnbull" wrote: >> +1 >> >> Such a site could be very useful. >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel >> Zwolenski >> Sent: Sunday, 28 July 2013 09:56 >> To: Pedro Duque Vieira >> Cc: OpenJFX Mailing List >> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) >> >> The idea of a JFX Sightings page (in the tradition of the Swing >> Sightings >> page) has been raised before and I think is a good one. >> >> It deserves it's own page though, that technet section isn't up to it >> in my >> opinion. >> >> Personally I think this would be great under the fxexperience site as >> it >> partners nicely with the links of the week? >> >> >> >> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira >> >> wrote: >> >>> I have an Swing/JavaFX app, the site is: http://modellus.co >>> >>> How can I get it to be on that real world usecases section? Or does >> it >>> not have the necessary requirements to be in it? >>> >>> Thanks, best regards, >>> >>> @John: On the JavaFx community site they have a section with >>> references to >>>> real world usecases. >>>> http://www.oracle.com/technetwork/java/javafx/community/index.html >>>> >>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull >>>> >>>> wrote: >>>>> Like Daniel said, none of what we say is in any way a criticism of >>>>> the JavaFX development team who, in my view and that of the entire >>>>> community, are doing an awesome job. >>>>> >>>>> >>>>> >>>>> For mine, all the shortcomings of JavaFX (perceived or actual) can >>>>> be >>>> blown >>>>> away if I could just demonstrate what JavaFX is really capable of. >>>>> >>>>> >>>>> >>>>> We have Ensemble from Oracle and also Ensemble from JFXtras (whose >>>>> demo incidentally doesn't run since Java 7 Update 21). With Oracle >> >>>>> Ensemble >>>> we >>>>> can see that JavaFX has quite a nice set of basic controls and that >> >>>>> it at least supports very simple animations. With JFXtras Ensemble >> >>>>> we can see that very nice controls are possible but unfortunately >>>>> many of these are >>>> of >>>>> a rather "whimsical" nature and not the kind of control you would >>>>> use in everyday business apps. >>>>> >>>>> >>>>> >>>>> What else is there? >>>>> >>>>> >>>>> >>>>> Of course we have rock stars like Gerrit Grunwald who frequently >>>>> post awesome controls and code snippets but we really need >> something >>>>> that >>>> brings >>>>> it altogether in a kick-arse showcase. Preferably a whole suite of >>>> killer >>>>> apps that highlights everything JavaFX is capable of. >>>>> >>>>> >>>>> >>>>> Yes, that would require a lot of effort but IMHO it is absolutely >>>>> worth >>>> it. >>>>> Without it, people like me really struggle to sell JavaFX or even >>>>> get a handle on its true potential. I can promise people that more >> >>>>> advanced things are "possible" but given that they write the >>>>> cheques, they need to see it for themselves. >>>>> >>>>> >>>>> >>>>> And how about a website of JavaFX reference sites? There must be >>>>> big companies out there using it right? >>>>> >>>>> >>>>> >>>>> In the end it doesn't matter if I personally see enormous potential >> >>>>> for JavaFX if I cannot convince others to see what I see. >>>>> >>>>> >>>>> >>>>> -jct >>>>> >>>>> >>>>> >>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] >>>>> Sent: Saturday, 27 July 2013 09:12 >>>>> To: John C. Turnbull >>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net >>>>> Subject: Re: Can JavaFX do CAD? >>>>> >>>>> >>>>> >>>>> +1 >>>>> >>>>> >>>>> >>>>> I've failed to convince multiple clients that they should use JFX >>>>> because of >>>>> >>>>> >>>>> a) lack of examples of what it can really do, and how to make it do >> >>>>> that (e.g. in enterprise space we have >>>>> http://static.springsource.org/docs/petclinic.html) >>>>> >>>>> b) lack of any big or notable players out there actually using it, >>>>> or at least publicly saying they are using it >>>>> >>>>> c) the deployment hassles vs the ease of html app deployment and >> the >>>>> true cross-platform-ness of html >>>>> >>>>> >>>>> >>>>> After actually getting one client to trust me on it and use it on a >> >>>>> real, commercial app (startup), I hit problems with performance >>>>> (broad interpretation of the term, not 'framerate'), crippling >>>>> deployment and >>>> auto >>>>> updating issues, missing basic features (e.g. maximise button, >>>>> coming in >>>>> 2014 I believe?), unpredictability of CSS styling, and a lack of >>>>> best practices for things like how to do CAD-like diagrams (not so >>>>> much render performance but zooming, panning, mouse input, >> layering, >> dragging, etc). >>>>> >>>>> >>>>> >>>>> Like John, I've been guilty of letting my frustration show in these >>>> forums. >>>>> Like John, it's because I want so badly for JavaFX to be the >>>>> platform I develop on, it has the potential to be awesome, but >>>>> things (that seem obvious and small to me) completely stop it from >>>>> being usable in a real world situation for me. >>>>> >>>>> >>>>> >>>>> It's not that we think the JFX team aren't slogging their guts out, >>>> clearly >>>>> you are. It's just that in some key areas, there are small-ish >>>>> blocks >>>> that >>>>> stop the whole rocket from launching. To then see a whole lot of >>>>> effort >>>> be >>>>> poured into things like binary CSS/FXML compilation, Pi platform >>>>> support (that's more important than iOS/Android, really?), web >>>>> deployment >>>> patches, >>>>> or even 3D (as cool as that is), just knocks me about. Obviously >>>>> your priorities are coming from somewhere different to ours, but >> the >>>>> way you prioritise is unfathomable to me and that definitely adds >> to >>>>> the frustration. >>>>> >>>>> >>>>> >>>>> At this stage, I am not suggesting my clients use JFX (I actively >>>>> discourage them from it, in their interest). Mobile is the area >> that >>>>> has the >>>> potential >>>>> to bring JFX back into usable for me as it can compete easier with >>>>> the current technologies (which are all crap). Maybe if that ends >> up >>>>> working >>>> (a >>>>> long, long road to go on that and very much an 'if') then it will >>>>> seep >>>> back >>>>> into the desktop for me, but at a minimum the desktop deployment >>>>> options will need to be improved before that's even a possibility. >>>>> >>>>> >>>>> I've come to accept that I am not in the primary target audience >> for >>>>> JavaFX, maybe a secondary target. I don't understand who the >> primary >>>>> target is though, and knowing/accepting doesn't make it any less >>>>> frustrating. I >>>> keep >>>>> involved in the hope that I might get a usable platform somewhere >>>>> along >>>> the >>>>> way but it's more of a hope than a belief. >>>>> >>>>> >>>>> >>>>> So nothing really new above, but just adding my voice to John's. >>>>> JavaFX >>>> is >>>>> definitely not production ready for me, my clients and the types of >> >>>>> apps >>>> I >>>>> build (e.g. consumer facing online systems, enterprise/backoffice >>>> systems, >>>>> form/data systems, diagramming systems). One day I hope it will be, >> >>>>> but it's moving extremely slowly or not at all in the areas that >>>>> would make it so for me. Meanwhile the competitors (primarily >>>>> JavaScript based solutions) are improving rapidly in the areas >> where >>>>> they have traditionally been weak. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < >>>> ozemale at ozemail.com.au >>>>> > wrote: >>>>> >>>>> Hi Richard, >>>>> >>>>> I have to stop posting late at night, that one came across as >> really >>>> ANGRY! >>>>> >>>>> It's not anger, it's passion... and frustration. >>>>> >>>>> I am frustrated because I spend much of my day trying to convince >> my >>>>> employer that we should be using JavaFX. They ask me questions >> like: >>>>> >>>>> "What happens if Oracle abandons JavaFX just like Sun did with JMF, >>>> Java3D, >>>>> JOGL etc. ?" >>>>> >>>>> I say: >>>>> >>>>> "This is Oracle, not Sun." >>>>> >>>>> They say: >>>>> >>>>> "Can you show me what JavaFX can do? There must be examples out >>>>> there right?" >>>>> >>>>> And I say: >>>>> >>>>> "Sure, here's Ensemble." >>>>> >>>>> They say: >>>>> >>>>> "OK, so it has a nice set of basic controls and can do simple >>>>> animations but what about more complex things like Flash?" >>>>> >>>>> ...hence the dancing cat reference. >>>>> >>>>> It's not that my employer *needs* dancing cats, it's just that they >> >>>>> need >>>> to >>>>> see that there is more to JavaFX than red circle transitions. I >>>>> can't >>>> even >>>>> prove to them that JavaFX is capable of dancing cats. They don't >>>>> have >>>> the >>>>> resources to fund me to develop something more sophisticated but >>>>> they >>>> tell >>>>> me that if JavaFX truly was a "mature" technology (like I tell >> them) >>>>> then where are all the examples? >>>>> >>>>> I am finding it difficult to convince them that JavaFX is >> production >>>> ready >>>>> and is not still in "experimental" mode because I am unable to >>>> demonstrate >>>>> its true capabilities or refer them to many examples of people (and >> >>>>> I >>>> mean >>>>> big companies) actually using it. >>>>> >>>>> The main concerns of my employer and I think many companies in a >>>>> similar situation is that JavaFX won't survive long term and that >> it >>>>> is only >>>> really >>>>> suitable for form based applications. Then of course there is the >>>>> whole >>>>> "HTML5 runs on all platforms" argument but that's another story... >>>>> >>>>> So this is why I think it's imperative that Oracle invests in >>>>> developing >>>> a >>>>> true showcase application for JavaFX. Something that non-technical >>>> people >>>>> (like managers who make decisions about where the money goes) can >>>>> look at it and go "wow!". >>>>> >>>>> I am just not getting my managers to go "wow" at what I can show >>>>> them >>>> with >>>>> JavaFX at the moment. >>>>> >>>>> Every comment or apparent criticism I post about JavaFX is from the >> >>>>> perspective that I am trying to deal with real-world problems and >>>>> people who require proof (such as demos, reference sites etc.) and >>>>> not because I myself think JavaFX is not up to scratch. >>>>> >>>>> It's quite the opposite actually. >>>>> >>>>> I am a very, very strong believer and supporter of JavaFX and have >>>>> many reasons both personal and professional as to why I want it to >>>>> be a >>>> massive >>>>> success. As I have said before, there are plenty of people who >>>>> praise JavaFX and tend to avoid the very real issues that are >>>>> restricting its adoption. I just think we have to face these >> issues >>>>> head on if we are to compete in what is a very cut-throat industry. >>>>> >>>>> -jct >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Richard Bair [mailto:richard.bair at oracle.com >>>>> ] >>>>> Sent: Saturday, 27 July 2013 01:40 >>>>> To: John C. Turnbull >>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net >>>>> >>>>> Subject: Re: Can JavaFX do CAD? >>>>> >>>>>> For Flash, there are literally millions of examples of >>>>>> fancy/complex/impressive graphics and animations out there that >> can >>>>>> be really impressive at times. I have not seen ONE such example >> in >>>> JavaFX! >>>>> >>>>> Point to one? >>>>> >>>>> Have you seen any of the JavaOne examples? The movie wall or movies >> >>>>> on a stack of 3D cubes was pretty good. But I guess you're not >>>>> interested in >>>> the >>>>> 3D aspect? What is it you are looking for exactly? Different people >> >>>>> (on this >>>>> list) have had different perceptions on both (a) what's important >>>>> and (b) what kind of graphics they're interested in. Most people >>>>> would deride the dancing cat as being totally irrelevant to the >>>>> types of applications they're trying to build (the basis for much >> of >>>>> flash animations is shape >>>> morphing, >>>>> you can find some code here >> https://gist.github.com/gontard/5029764). >>>>> >>>>> On the other hand, JavaFX is not a replacement for OpenGL. Drawing >>>>> 25 million lines is just not something we can do right now, >>>>> especially in a resource constrained environment. I've already >>>>> commented on the memory overhead (which would continue to be an >>>>> issue even if the drawing part of the problem were solved). >>>>> >>>>> I've pushed to graphics repo the StretchyGrid, which is about 300k >>>>> line nodes (the actual amount is variable, see the javadoc >>>>> comments). At 300k nodes the scene graph overhead is negligible on >>>>> the FX side, dirty opts >>>> is >>>>> taking a long time to run, and painting is really slow. >>>>> >>>>> PULSE: 347 [122ms:222ms] >>>>> T12 (8 +0ms): CSS Pass >>>>> T12 (8 +0ms): Layout Pass >>>>> T12 (47 +53ms): Waiting for previous rendering >>>>> T12 (100 +1ms): Copy state to render graph >>>>> T10 (101 +16ms): Dirty Opts Computed >>>>> T10 (117 +105ms): Painted >>>>> Counters: >>>>> Nodes rendered: 306565 >>>>> Nodes visited during render: 306565 >>>>> >>>>> If I were doing this by hand in open GL, I think the drawing would >>>>> be essentially free, if I used LINES with GL anti-aliasing, I could >> >>>>> send 'em all down to the card in a single shot (and if I had a >>>>> modern GL I could >>>> do >>>>> LINES + FXAA or one of the other per-pixel AA algorithms available >>>>> and it would turn out pretty nice). Because our shapes don't >>>>> implement the >>>> non-AA >>>>> path, and our AA involves software rasterization and uploading of >>>> pixels, I >>>>> expect that to be the main source of the 105ms time being spent >> here. >>>>> >>>>> Also I noticed (by turning on prism.showdirty=true) that the entire >> >>>>> grid >>>> is >>>>> being painted every time, even though visually it looks like only a >> >>>>> small subset actually needs to be changed. But that's really a >> minor >>>>> thing, as >>>> I >>>>> said, drawing this many lines should basically be free if I >>>>> configure "smooth" to false in the app. Except that right now it is >> >>>>> totally not implemented (in NGShape): >>>>> >>>>> public void setAntialiased(boolean aa) { >>>>> // We don't support aliased shapes at this time >>>>> } >>>>> >>>>> The point of stretchy grid is not to say "wow look at this amazing >> demo". >>>>> The point is to say "what happens if I put in 300K nodes. Where >> does >>>>> the system start to fall over?". >>>>> >>>>> Richard= >>>>> >>>>> >>>>> >>>>> >>> >>> >>> -- >>> Pedro Duque Vieira From herve.girod at gmail.com Thu Aug 1 03:35:57 2013 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Thu, 1 Aug 2013 12:35:57 +0200 Subject: Multiple JFXPanel? In-Reply-To: References: Message-ID: <289AF612-B13F-403C-BB88-7FFDCF484CE7@gmail.com> We use a MDI Apple with Swing tabs where each tab contain one JFXPanel with an embedded Scene. We don't have any problem with thousands of Nodes in each Scene, and we did not experience any particular performance problems, at least in our use case. Herv? Sent from my iPhone On 1 ao?t 2013, at 00:45, Pedro Duque Vieira wrote: > Hi, > > I have a doubt. I have a swing app with embed javafx scene. My app has kind > of a MDI style interface. Right now only one window has been converted to > JavaFX, basically it's a window with a JFXPanel in it. > My question is if I want to convert the other windows as well should I also > put a JFXPanel in them? I would than have 2 JFXPanels in my app, does that > mean I would have 2 JavaFX scenes? Is that the way to do it? Would that > seriously hurt performance? > > Thank you in advance, best regards, > > -- > Pedro Duque Vieira From hang.vo at oracle.com Thu Aug 1 04:19:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 11:19:45 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31920: Allow Application name to be set and queried and implement app data directory Message-ID: <20130801112019.6D287484F3@hg.openjdk.java.net> Changeset: 18ba5b7ba24c Author: snorthov Date: 2013-08-01 07:09 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/18ba5b7ba24c RT-31920: Allow Application name to be set and queried and implement app data directory ! modules/graphics/src/main/java/com/sun/glass/ui/Application.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/native-glass/mac/GlassApplication.m From hang.vo at oracle.com Thu Aug 1 04:35:28 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 11:35:28 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20130801113614.58E33484F5@hg.openjdk.java.net> Changeset: c8b408109a3a Author: tb115823 Date: 2013-08-01 13:18 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c8b408109a3a Android: webnode moved to opensource. Updated java and native projects. ! buildSrc/android.gradle + modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java.jfx78 + modules/web/src/android/java/com/sun/javafx/scene/web/Debugger.java + modules/web/src/android/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java + modules/web/src/android/java/com/sun/javafx/sg/prism/NGWebView.java + modules/web/src/android/java/com/sun/javafx/webkit/Accessor.java + modules/web/src/android/java/com/sun/javafx/webkit/prism/PrismInvoker.java + modules/web/src/android/java/com/sun/webkit/BackForwardList.java + modules/web/src/android/java/com/sun/webkit/Disposer.java + modules/web/src/android/java/com/sun/webkit/DisposerRecord.java + modules/web/src/android/java/com/sun/webkit/InspectorClient.java + modules/web/src/android/java/com/sun/webkit/Invoker.java + modules/web/src/android/java/com/sun/webkit/LoadListenerClient.java + modules/web/src/android/java/com/sun/webkit/NativeWebView.java + modules/web/src/android/java/com/sun/webkit/Timer.java + modules/web/src/android/java/com/sun/webkit/WebPage.java + modules/web/src/android/java/com/sun/webkit/event/WCChangeEvent.java + modules/web/src/android/java/com/sun/webkit/event/WCChangeListener.java + modules/web/src/android/java/com/sun/webkit/graphics/WCImage.java + modules/web/src/android/java/com/sun/webkit/network/URLs.java + modules/web/src/android/java/com/sun/webkit/network/Util.java + modules/web/src/android/java/javafx/scene/web/HTMLEditor.java + modules/web/src/android/java/javafx/scene/web/PopupFeatures.java + modules/web/src/android/java/javafx/scene/web/PromptData.java + modules/web/src/android/java/javafx/scene/web/WebEngine.java + modules/web/src/android/java/javafx/scene/web/WebEvent.java + modules/web/src/android/java/javafx/scene/web/WebHistory.java + modules/web/src/android/java/javafx/scene/web/WebView.java + modules/web/src/android/java/netscape/javascript/JSException.java + modules/web/src/android/java/netscape/javascript/JSObject.java + modules/web/src/android/native/android_log.h + modules/web/src/android/native/android_webview.c + modules/web/src/android/native/android_webview.h + modules/web/src/android/native/native_webview.c + modules/web/src/android/native/symbol.h + netbeans/android/native-webnode/Android.mk + netbeans/android/native-webnode/nbproject/configurations.xml + netbeans/android/native-webnode/nbproject/project.xml + netbeans/android/webnode/build.xml + netbeans/android/webnode/local.properties + netbeans/android/webnode/nbproject/project.xml Changeset: 675b95a2ac37 Author: tb115823 Date: 2013-08-01 13:23 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/675b95a2ac37 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: 812ccc5dcaf0 Author: snorthov Date: 2013-08-01 07:26 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/812ccc5dcaf0 ECLIPSE ONLY: fix .classpath compile error ! .classpath ! modules/web/.classpath From artem.ananiev at oracle.com Thu Aug 1 05:20:38 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 01 Aug 2013 16:20:38 +0400 Subject: A different way to handle pulse timing In-Reply-To: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> Message-ID: <51FA5296.2050009@oracle.com> Hi, Richard, as far as I can read it, your idea is to start preparing the next frame right after synchronization (scenegraph to render tree) is completed for the previous frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem with input events starvation. There will be no or very little window, when the events can be processed on the event thread, because the thread will always be either busy handling CSS, animations, etc., or blocked waiting for the render thread to finish rendering. See more comments/questions below. On 7/26/2013 9:22 AM, Richard Bair wrote: > Hi, > > I'm probably missing something obvious and you guys on Glass / Prism > / Quantum can help set me straight. I was thinking tonight of a > different way of initiating pulse events that would, I think, > completely smooth out the pulses such that we don't end up with > "drift" due to the timer being at a different rate than the GPU. > > Suppose we have two variables in the system (and for simplicity lets > talk about a single Scene, because one problem I think this idea has > is with multiple scenes and I want to discuss that separately after > the core mechanism is understood): > > - boolean pendingPulse > - int runningAnimationCounter We already have the latter. QuantumToolkit.animationRunnable is used to track if there are any live animations. When the last of them is finished, this runnable is set to null, this is my understanding. > Whenever an animation starts, the runningAnimationCounter is > incremented. When an animation ends, it is decremented (or it could > be a Set or whatever). The pendingPulse is simply false to > start with, and is checked before we submit another pulse. Whenever a > node in the scene graph becomes dirty, or the scene is resized, or > stylesheets are changed, or in any case something happens that > requires us to draw again, we check this flag and fire a new pulse if > one is not already pending. Scene graph is only changed on the event thread. So my guess is that "fire a new pulse" is just Platform.runLater(() -> pulse()) correct? > When a pulse occurs, we process animations first, then CSS, then > layout, then validate all the bounds, and *then we block* until the > rendering thread is available for synchronization. I believe this is > what we are doing today (it was a change Steve and I looked at with > Jasper a couple months ago IIRC). > > But now for the new part. Immediately after synchronization, we check > the runningAnimationCounter. If it is > 0, then we fire off a new > pulse and leave the pendingPulse flag set to true. If > runningAnimationCounter == 0, then we flip pendingPulse to false. > Other than the pick that always happens at the end of the pulse, we > do nothing else new and, if the pick didn't cause state to change, we > are now quiescent. > > Meanwhile, the render thread has run off doing its thing. The last > step of rendering is the present, where we will block until the thing > is presented, which, when we return, would put us *immediately* at > the start of the next 16.66ms cycle. Since the render thread has just > completed its duties, it goes back to waiting until the FX thread > comes around asking to sync up again. > > If there is an animation going on such that a new pulse had been > fired immediately after synchronization, then that new pulse would > have been handled while the previous frame was being rendered. Most > likely, by the time the render thread completes presenting and comes > back to check with the FX thread, it will find that the FX thread is > already waiting for it with the next frames data. It will synchronize > immediately and then carry on rendering another frame. Given that you propose to fire a new pulse() whenever anything is changed in scene graph, and also right after synchronization, there is no need to have an external timer (QuantumToolkit.pulseTimer()) any longer. > I think the way this would behave is that, when an animation is first > played, you will get two pulses close to each other. The first pulse > will do its business and then synchronize and then immediately fire > off another pulse. That next pulse will then also get processed and > then the FX thread will block until the previous frame finishes > rendering. During this time, additional events (either application > generated via runLater calls happening on background threads, or from > OS events) will get queued up. Between pulse #2 and pulse #3 then a > bunch of other events will get processed, essentially playing > catch-up. My guess is that this won't be a problem but you might see > a hiccup at the start of a new animation if the event queue is too > full and it can't process all that stuff in 16ms (because at this > point we're really multi-theaded between the FX and render threads > and have nearly 16ms for each thread to do their business, instead of > only 8ms which is what you'd have in a single threaded system). > > Another question I have is around resize events and how those work. > If they also come in to glass on the FX thread (but at a higher > priority than user events like a pulse or other input events?) then > what will happen is that we will get a resize event and process a > half-a-pulse (or maybe a whole pulse? animations+css+layout or just > css+layout?) and then render, pretty much just as fast as we can. > > As for multiple scenes, I'm actually curious how this happens today. > If I have 2 scenes, and we have just a single render thread servicing > both, then when I go to present, it blocks? Or is there a > non-blocking present method that we use instead? Because if we block, > then having 2 scenes would cut you down to 30fps maximum, wouldn't This is a very interesting question... Experiments show that we can have more than one window/scene running at 60 fps. Someone from the graphics team should comment on this. My only guess (at least, in case of D3D pipeline) that present() doesn't block, if it's called no more than once between vsyncs (but the frame is shown on the screen on vsync anyway). Thanks, Artem > it? If we are non-blocking today (is that possible?) then the only > way this proposed solution would work is if there was a different > render thread per stage (which actually is something I think we ought > to be doing anyway?). > > Thanks > Richard > > From dk at hp.com Thu Aug 1 02:59:46 2013 From: dk at hp.com (K, Dhevendran (MSDU)) Date: Thu, 1 Aug 2013 09:59:46 +0000 Subject: Is it possible to use OpenJDK to develop (and execute ) JAVA FX Application? Message-ID: <984693099B29AC4289F387DC2E100A47343FAF89@G4W3211.americas.hpqcorp.net> Hi I need some clarification on integrating JAVA FX application with OpenJDK 7. We have developed JAVA FX application using Oracle JDK (with help of Netbeans 7.3.1 IDE) . Now, We would like to use OpenJDK in place of Oracle JDK . Is it possible to use OpenJDK to develop (and execute ) JAVA FX Application? . As we have to use OpenJDK ( not OracleJDK) ,let me know whether this is possible in some other way. Thanks & Regards Dhevendran K From hang.vo at oracle.com Thu Aug 1 06:14:07 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 13:14:07 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130801131503.63CA648509@hg.openjdk.java.net> Changeset: 44f6ba54dcde Author: snorthov Date: 2013-08-01 08:11 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/44f6ba54dcde RT-31249: Mechanism to identify application [udpate SWT] ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java Changeset: 7b0d4ac76c35 Author: Artem Ananiev Date: 2013-08-01 16:22 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7b0d4ac76c35 RT-32012: Quantum cleanup: remove PopupScene and PopupStage Reviewed-by: Kevin Rushforth, Steve Northover ! modules/graphics/src/main/java/com/sun/javafx/tk/DummyToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupScene.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupStage.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java ! modules/graphics/src/main/java/javafx/stage/PopupWindow.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubToolkit.java From tobi at ultramixer.com Thu Aug 1 06:41:26 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Thu, 1 Aug 2013 15:41:26 +0200 Subject: current state of gradle script for Android? In-Reply-To: <51F92255.5040904@oracle.com> References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> Message-ID: <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? Thanks! Tobi Am 31.07.2013 um 16:42 schrieb tomas.brandalik : > Hi Tobi, > it works on linux only right now. > Set properties for cross build and android sdk/ndk. > -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true > Closed source parts web and font-t2k will be missing. > > -Tomas > > On 07/29/2013 11:22 PM, Tobias Bley wrote: >> Hi, >> >> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >> >> Best regards, >> Tobi >> > From tomas.brandalik at oracle.com Thu Aug 1 07:00:25 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Thu, 01 Aug 2013 16:00:25 +0200 Subject: current state of gradle script for Android? In-Reply-To: <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> Message-ID: <51FA69F9.1040402@oracle.com> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. http://developer.android.com/sdk/index.html http://developer.android.com/tools/sdk/ndk/index.html -Tomas On 08/01/2013 03:41 PM, Tobias Bley wrote: > Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? > > Thanks! > Tobi > > > Am 31.07.2013 um 16:42 schrieb tomas.brandalik : > >> Hi Tobi, >> it works on linux only right now. >> Set properties for cross build and android sdk/ndk. >> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >> Closed source parts web and font-t2k will be missing. >> >> -Tomas >> >> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>> Hi, >>> >>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>> >>> Best regards, >>> Tobi >>> From benjamin.john.evans at gmail.com Thu Aug 1 07:04:04 2013 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 1 Aug 2013 15:04:04 +0100 Subject: Build failures In-Reply-To: <1BDD8680-89D7-487A-B7AE-0BB94F48E9FA@oracle.com> References: <1BDD8680-89D7-487A-B7AE-0BB94F48E9FA@oracle.com> Message-ID: Hi Richard, Yes, I followed the instructions - that's what produced the above error report - and XCode is installed (needed for OpenJDK builds). By the way, can I suggest moving away from the forest hg extension - it's no longer supported & can't be made to work reliably on Mac. Thanks, Ben On Wed, Jul 31, 2013 at 6:48 PM, Richard Bair wrote: > Hi Ben, > > Have you seen > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX? Also > there is a blog post on FX + Nashorn > http://harmoniccode.blogspot.com/2013/05/taming-nashorn-first-impressions.html. > Both are shipped with each weekly promoted build so you can try this out > without having to build. > > Your particular build seems to be failing on the native build, I assume > you have Xcode installed? > > I think there is a problem building with OpenJDK right now (I was looking > at this with Mario a couple weeks ago but I haven't been able to get back > to it yet. > > Richard > > On Jul 31, 2013, at 10:16 AM, Ben Evans > wrote: > > > Hi, > > > > I'm attempting to get OpenJFX built & running against the tip of Nashorn. > > > > It's not immediately clear to me that I'm doing the right thing with my > > build. > > > > What I'm trying is: > > > > 1) Build the OpenJFX runtime. > > > > 2) Install a latest Nashorn binary. > > > > 3) Add jfxrt.jar to $JAVA_HOME/jre/lib/ in the Nashorn binary > > > > 4) Profit. > > > > First of all, is this a sane approach to trying to get OpenJFX playing > > nicely with an OpenJDK binary? I looked for a wiki but couldn't find > > anything. > > > > Assuming it is, it still isn't working. After a certain amount of > > yak-shaving (Gradle being useless, and having to hack around the forest > > extension gunk) the build is failing (details below). > > > > This is with Oracle JDK 8 b100 on Mac 10.8 - any ideas? > > > > Btw, I'm assuming that there's no way to bootstrap OpenJFX using an > OpenJDK > > binary at present? > > > > Not having to manage Oracle JDKs as well as OpenJDK binaries would be > > really nice. > > > > Thanks, > > > > Ben > > > > > > oldhost:rt boxcat$ gradle > > :buildSrc:generateGrammarSource UP-TO-DATE > > :buildSrc:compileJava > > :buildSrc:compileGroovy > > :buildSrc:processResources UP-TO-DATE > > :buildSrc:classes > > :buildSrc:jar > > :buildSrc:assemble > > :buildSrc:compileTestJava > > Note: > > > /Users/boxcat/projects/openjdk/master/rt/buildSrc/src/test/java/com/sun/scenario/effect/compiler/parser/FieldSelectTest.java > > uses or overrides a deprecated API. > > Note: Recompile with -Xlint:deprecation for details. > > :buildSrc:compileTestGroovy UP-TO-DATE > > :buildSrc:processTestResources UP-TO-DATE > > :buildSrc:testClasses > > :buildSrc:test > > :buildSrc:check > > :buildSrc:build > > OS_NAME: mac os x > > OS_ARCH: x86_64 > > JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/ > > JDK_HOME: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/ > > COMPILE_TARGETS: mac > > COMPILE_FLAGS_FILES: buildSrc/mac.gradle > > BINARY_STUB: > > > /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar > > HUDSON_JOB_NAME: not_hudson > > HUDSON_BUILD_NUMBER: 0000 > > PROMOTED_BUILD_NUMBER: 00 > > PRODUCT_NAME: OpenJFX > > RAW_VERSION: 8.0.0 > > RELEASE_NAME: 8.0 > > RELEASE_MILESTONE: ea > > UPDATE_STUB_CACHE: false > > The CompileOptions.useAnt property has been deprecated and is scheduled > to > > be removed in Gradle 2.0. There is no replacement for this property. > > :updateCacheIfNeeded UP-TO-DATE > > :base:processVersionInfo UP-TO-DATE > > :base:compileJava UP-TO-DATE > > :base:processResources UP-TO-DATE > > :base:classes UP-TO-DATE > > :base:jar UP-TO-DATE > > :graphics:compileJava > > [ant:javac] Note: Some input files use or override a deprecated API. > > [ant:javac] Note: Recompile with -Xlint:deprecation for details. > > [ant:javac] Note: Some input files use unchecked or unsafe operations. > > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > > :graphics:compilePrismCompilers > > :graphics:generatePrismShaders > > :graphics:compilePrismJavaShaders > > :graphics:compileDecoraCompilers > > :graphics:generateDecoraShaders > > :graphics:compileDecoraHLSLShaders SKIPPED > > :graphics:processDecoraShaders > > :graphics:compilePrismHLSLShaders SKIPPED > > :graphics:processPrismShaders > > :graphics:processResources > > :graphics:classes > > :graphics:jar > > :designTime:compileJava > > [ant:javac] Note: Some input files use unchecked or unsafe operations. > > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > > :designTime:processResources UP-TO-DATE > > :designTime:classes > > :designTime:jar > > :controls:compileJava > > [ant:javac] Note: Some input files use or override a deprecated API. > > [ant:javac] Note: Recompile with -Xlint:deprecation for details. > > [ant:javac] Note: Some input files use unchecked or unsafe operations. > > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > > :controls:processResources > > :controls:classes > > :controls:jar > > :swing:compileJava > > [ant:javac] Note: Some input files use or override a deprecated API. > > [ant:javac] Note: Recompile with -Xlint:deprecation for details. > > [ant:javac] Note: Some input files use unchecked or unsafe operations. > > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > > :swing:processResources UP-TO-DATE > > :swing:classes > > :swing:jar > > :swt:compileJava > > [ant:javac] Note: Some input files use unchecked or unsafe operations. > > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > > :swt:processResources UP-TO-DATE > > :swt:classes > > :swt:jar > > :fxml:compileJava > > [ant:javac] Note: > > > /Users/boxcat/projects/openjdk/master/rt/modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java > > uses unchecked or unsafe operations. > > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > > :fxml:processResources UP-TO-DATE > > :fxml:classes > > :web:compileJava SKIPPED > > :web:processResources > > :web:classes > > :javadoc SKIPPED > > :apps:compileJava UP-TO-DATE > > :apps:processResources UP-TO-DATE > > :apps:classes UP-TO-DATE > > :apps:jar > > :apps:assemble > > :base:assemble UP-TO-DATE > > :web:copyClassesFromBinaryStub > > :web:jar > > :builders:compileJava > > [ant:javac] Note: > > > /Users/boxcat/projects/openjdk/master/rt/modules/builders/src/main/java/javafx/scene/web/WebViewBuilder.java > > uses or overrides a deprecated API. > > [ant:javac] Note: Recompile with -Xlint:deprecation for details. > > [ant:javac] Note: Some input files use unchecked or unsafe operations. > > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > > :builders:processResources UP-TO-DATE > > :builders:classes > > :builders:jar > > :builders:assemble > > :controls:assemble > > :designTime:assemble > > :fxml:jar > > :fxml:assemble > > :fxpackager:buildJavaFXPackager > > Calling Task.setEnabled(boolean) after task execution has started has > been > > deprecated and is scheduled to be removed in Gradle 2.0. Check the > > configuration of task ':fxpackager:buildJavaFXPackager'. You may have > > misused '<<' at task declaration. > > :fxpackager:compileJava > > Download > > http://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.pom > > Download > > > http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.8.2/ant-parent-1.8.2.pom > > Download > > > http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.8.2/ant-launcher-1.8.2.pom > > Download > > http://repo1.maven.org/maven2/org/apache/ant/ant/1.8.2/ant-1.8.2.jar > > Download > > > http://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.8.2/ant-launcher-1.8.2.jar > > [ant:javac] Note: Some input files use unchecked or unsafe operations. > > [ant:javac] Note: Recompile with -Xlint:unchecked for details. > > :fxpackager:man > > :fxpackager:processResources > > :fxpackager:classes > > :fxpackager:compileLauncher > > In file included from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, > > from > > > /Users/boxcat/projects/openjdk/master/rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26: > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12:20: > > error: stdarg.h: No such file or directory > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:16:19: > > error: float.h: No such file or directory > > In file included from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:129, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:72, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, > > from > > > /Users/boxcat/projects/openjdk/master/rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26: > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:29:23: > > error: xmmintrin.h: No such file or directory > > In file included from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:129, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:72, > > from > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, > > from > > > /Users/boxcat/projects/openjdk/master/rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26: > > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MachineExceptions.h:216: > > error: expected specifier-qualifier-list before ?__m128? > > :fxpackager:compileLauncher FAILED > > > > FAILURE: Build failed with an exception. > > > > * What went wrong: > > Execution failed for task ':fxpackager:compileLauncher'. > >> org.gradle.process.internal.ExecException: Process 'command 'gcc'' > > finished with non-zero exit value 1 > > > > * Try: > > Run with --stacktrace option to get the stack trace. Run with --info or > > --debug option to get more log output. > > > > BUILD FAILED > > > > Total time: 3 mins 25.023 secs > > oldhost:rt boxcat$ > > From hang.vo at oracle.com Thu Aug 1 07:17:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 14:17:59 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130801141834.A94904850A@hg.openjdk.java.net> Changeset: b4a3b80a0783 Author: Martin Sladecek Date: 2013-08-01 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b4a3b80a0783 RT-31464 Custom node sample in Ensemble8 is broken ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/node/customnode/MyNode.java Changeset: fbaef718694c Author: Martin Sladecek Date: 2013-08-01 16:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fbaef718694c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt From hang.vo at oracle.com Thu Aug 1 07:17:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 14:17:59 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130801141845.D064C4850B@hg.openjdk.java.net> Changeset: 4d59d24f0d8b Author: mickf Date: 2013-08-01 14:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4d59d24f0d8b RT-30871 : indeterminate progress bar causes memory leak ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 3aadad7d5904 Author: mickf Date: 2013-08-01 14:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3aadad7d5904 RT-27791 :ProgressBar keeps animating when in ScrollPane and scrolled out of view ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java From diego.cirujano-cuesta at zeiss.com Thu Aug 1 08:47:12 2013 From: diego.cirujano-cuesta at zeiss.com (Diego Cirujano-Cuesta) Date: Thu, 1 Aug 2013 17:47:12 +0200 Subject: Missed "pulse"? In-Reply-To: References: Message-ID: I had problems when we were using column constraints with a fixed size. Something like this: ColumnConstraints cc = new ColumnConstraints(); cc.setMaxWidth(ColumnConstraints.CONSTRAIN_TO_PREF); cc.setPrefWidth(x); So there was a ScrollPane with a Gridpane inside and the size of the gridpane was defined by the with of all columns. The thing was that calling setPrefWidth wasn?t triggeing a pulse. This is what I found but during the optimization I found out that anothe pane was better for my case, so I don't use it anymore. Regards. From: Scott Palmer To: Diego Cirujano-Cuesta Cc: "openjfx-dev at openjdk.java.net" Date: 31.07.2013 16:42 Subject: Re: Missed "pulse"? Interesting. The problem outlined in RT-31025 does involve GridPane with ColumnConstraints. I will try to dig up the code. Scott On Wed, Jul 31, 2013 at 4:47 AM, Diego Cirujano-Cuesta < diego.cirujano-cuesta at zeiss.com> wrote: Hi Scott, I have a component quite similar to the one you described and I also had problems like the ones that you mentioned with the same workarounds. BUT I found out that the problem was of my understanding. One of the problems was, I was using invalidation listeners and I wasn't getting always the value and another problem was a gridPane with column constraints. I had a look deeply and I fix them, now they work perfect. I saw in Jira you sent your code to Eva. If you want, you can send me the problem also(with the isolated code) I can have a look or much better, Eva could publish the code in Jira. I am interested. Regards, Diego >(I'm talking JavaFX2.x, but this happens in 8 as well.) >In my application I occasionally see a situation where the rendering doesn't jive with what it should. For example I have implemented my own scroll pane (ironically enough I did this to workaround manifestations of a problem similar to what I am about to describe in the stock ScrollPane) using clipping and translations, but sometimes I see the clipped content at the wrong location. So my clipped content is offset from the edge of my pane, or rendered over top of things outside my pane, even though it is impossible for the clipping and translating to not be set together. If I mouse over the offending area it suddenly snaps to the way it should be (CSS rules on the content would have forced it to redraw). >In other situations, I may need to coax a proper rendering of certain layouts by nudging the size of something to force another layout. >Obviously things should just paint correctly the first time. In these situations, the variables appear to be set to the correct values, but somehow that didn't get to the screen. >I'm not certain, but I suspect I might be able to work around these issues if I could force a "pulse" or mark things as dirty some way to trigger one. The thing is, there doesn't seem to be a publicly accessible way to do this, presumably because it isn't supposed to be necessary in the first place. >Platform.runLater(... requestLayout ...) was one workaround that I started to use, in the cases where things were particularly bad, but it isn't the sort of things I want to have to scatter throughout my code.. >With recent testing on JavaFX 8 I had to remove some of my workarounds because they caused a stack overflow doing layout. In requestLayout, I would call requestLayout directly on some specific child nodes (without a runLater) that seemed to misbehave - somehow this got back to call requestLayout again in my class and a quick attempt to break the cycle didn't work. >I'm sure you can appreciate the frustration in trying to ship a professional quality application with this sort of instability in the rendering system. >Since I suspect these issues aren't going to be fixed before 7u40 ships, and 8 is a long way off, what is the best thing to do? I have already filed bugs for issues in a few specific cases. E.g. RT-31025 (In some cases from a long time ago I was unsure if I was doing something wrong so I may not have isolated things into a test case and reported a bug.) >Regards, >Scott ---------------------------------------- This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. ---------------------------------------- This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. From hang.vo at oracle.com Thu Aug 1 09:17:04 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 16:17:04 +0000 Subject: hg: openjfx/8/graphics/rt: Restored accidental change made in changeset #4514 Message-ID: <20130801161806.BCC0648511@hg.openjdk.java.net> Changeset: c14cc7cd7d5c Author: peterz Date: 2013-08-01 18:44 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c14cc7cd7d5c Restored accidental change made in changeset #4514 ! buildSrc/linux.gradle From hang.vo at oracle.com Thu Aug 1 09:17:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 16:17:56 +0000 Subject: hg: openjfx/8/controls/rt: RT-31661 : Docs : Missing description in ScrollBar API - in constructor Message-ID: <20130801161923.26BC948512@hg.openjdk.java.net> Changeset: 42157cdefd1a Author: mickf Date: 2013-08-01 16:35 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/42157cdefd1a RT-31661 : Docs : Missing description in ScrollBar API - in constructor ! modules/controls/src/main/java/javafx/scene/control/ScrollBar.java From hang.vo at oracle.com Thu Aug 1 09:22:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 16:22:44 +0000 Subject: hg: openjfx/8/controls/rt: Revert DefaultTreeCell name change to enable building Message-ID: <20130801162304.9ECD648513@hg.openjdk.java.net> Changeset: d9f804166732 Author: mickf Date: 2013-08-01 17:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d9f804166732 Revert DefaultTreeCell name change to enable building ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java From hang.vo at oracle.com Thu Aug 1 09:03:14 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 16:03:14 +0000 Subject: hg: openjfx/8/master/rt: 92 new changesets Message-ID: <20130801162828.B1F4748514@hg.openjdk.java.net> Changeset: 1124ff0356aa Author: mhowe Date: 2013-07-26 12:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1124ff0356aa updateing build.properties to minimum build 100 ! build.properties Changeset: 739aca15eda2 Author: mhowe Date: 2013-07-26 17:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/739aca15eda2 Merge Changeset: ed328ed4e278 Author: leifs Date: 2013-07-23 11:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ed328ed4e278 RT-31840: DatePicker test fails (when not on en_US locale). ! modules/controls/src/test/java/javafx/scene/control/DatePickerTest.java Changeset: 79c688dfa63d Author: jgiles Date: 2013-07-24 08:04 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/79c688dfa63d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! modules/controls/src/test/java/javafx/scene/control/DatePickerTest.java Changeset: 3510e505d2c9 Author: jgiles Date: 2013-07-24 08:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3510e505d2c9 Removing @Ignore from DatePickerTest now that it has been fixed. ! modules/controls/src/test/java/javafx/scene/control/DatePickerTest.java Changeset: bd84bc9ce27b Author: jgiles Date: 2013-07-24 08:09 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bd84bc9ce27b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 6d0b751603ce Author: leifs Date: 2013-07-24 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6d0b751603ce RT-31643: Um-al-qura calendar is not initialized properly when opened for the first time ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DateCellSkin.java Changeset: 2b35d89ffbcf Author: jgiles Date: 2013-07-24 14:04 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2b35d89ffbcf RT-31775: TableRowSkinBase : Make CheckState protected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkinBase.java Changeset: 9a417e464fdf Author: jgiles Date: 2013-07-24 15:27 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9a417e464fdf RT-31856: TreeTableView scrollToColumn accepts TableColumn type of argument ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java Changeset: 89c969858c63 Author: jgiles Date: 2013-07-24 16:02 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/89c969858c63 RT-29386: [ComboBox] remove mention of emptyText property from javadoc, because it was removed ! modules/controls/src/main/java/javafx/scene/control/ComboBox.java Changeset: 56799caa343d Author: jgiles Date: 2013-07-24 17:16 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/56799caa343d RT-31727: EditingCellProperty is not set to null ! modules/controls/src/main/java/javafx/scene/control/TableColumn.java ! modules/controls/src/main/java/javafx/scene/control/TableRow.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableColumn.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java Changeset: 3d6d9e487f34 Author: jgiles Date: 2013-07-25 10:41 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3d6d9e487f34 RT-31910: TreeTableView has duplicate editing API. ! modules/controls/src/main/java/javafx/scene/control/TreeTablePosition.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableRowTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java Changeset: 0b883a5c820f Author: jgiles Date: 2013-07-25 10:49 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0b883a5c820f RT-31907: Cleanup control code (part one: this is a fix for the imports) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleList.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/accessible/AccessibleListItem.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DatePickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehavior.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/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/CellSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/CheckBoxSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerHijrahContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVK.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.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/LabeledText.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/RadioButtonSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableHeaderRow.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.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/TreeTableViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java ! modules/controls/src/main/java/javafx/scene/chart/AreaChart.java ! modules/controls/src/main/java/javafx/scene/chart/BarChart.java ! modules/controls/src/main/java/javafx/scene/chart/StackedAreaChart.java ! modules/controls/src/main/java/javafx/scene/control/Accordion.java ! modules/controls/src/main/java/javafx/scene/control/Cell.java ! modules/controls/src/main/java/javafx/scene/control/CheckBoxTreeItem.java ! modules/controls/src/main/java/javafx/scene/control/DateCell.java ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java ! modules/controls/src/main/java/javafx/scene/control/Hyperlink.java ! modules/controls/src/main/java/javafx/scene/control/Label.java ! modules/controls/src/main/java/javafx/scene/control/ListView.java ! modules/controls/src/main/java/javafx/scene/control/MenuBar.java ! modules/controls/src/main/java/javafx/scene/control/Pagination.java ! modules/controls/src/main/java/javafx/scene/control/ProgressBar.java ! modules/controls/src/main/java/javafx/scene/control/ProgressIndicator.java ! modules/controls/src/main/java/javafx/scene/control/RadioButton.java ! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java ! modules/controls/src/main/java/javafx/scene/control/ScrollToEvent.java ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java ! modules/controls/src/main/java/javafx/scene/control/Slider.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TableColumnBase.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/ToggleButton.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableColumn.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeView.java Changeset: 4134a2b1bb27 Author: jgiles Date: 2013-07-25 10:55 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4134a2b1bb27 RT-31907: Cleanup control code (part two: generic fixes for ListView/ListCell and a few other small changes) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/EmbeddedTextContextMenuContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListCellSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java ! modules/controls/src/main/java/javafx/scene/control/Labeled.java ! modules/controls/src/main/java/javafx/scene/control/ListCell.java ! modules/controls/src/main/java/javafx/scene/control/ListView.java Changeset: 47c27d64e7c2 Author: jgiles Date: 2013-07-25 11:19 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/47c27d64e7c2 RT-31907: Cleanup control code (part three: generic fixes for more controls) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java Changeset: 063ee023631d Author: jgiles Date: 2013-07-25 11:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/063ee023631d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: d3d8305d165c Author: leifs Date: 2013-07-24 17:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d3d8305d165c RT-30903: DatePicker: one column separator is a bit thicker when setting showWeekNumbers. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerContent.java Changeset: bfafc21f18d2 Author: jgiles Date: 2013-07-25 15:40 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bfafc21f18d2 RT-31509: -fx-indent badly applied in TreeTableView ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableCellSkin.java Changeset: 3bc3e99f3e3e Author: jgiles Date: 2013-07-25 15:43 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3bc3e99f3e3e RT-31834: PopupControl.CSSBridge not properly documented ! modules/controls/src/main/java/javafx/scene/control/PopupControl.java Changeset: 84108e7351f3 Author: jgiles Date: 2013-07-25 16:38 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/84108e7351f3 RT-31252: Extra TableCells created when scrolling with MouseWheel RT-31286: TableCells display Spurious Values when Scrolling with Mousewheel ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: cd582dc16ee4 Author: jgiles Date: 2013-07-25 17:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cd582dc16ee4 RT-30850: Missing documentation in controls ! modules/controls/src/main/java/javafx/scene/control/Tab.java ! modules/controls/src/main/java/javafx/scene/control/TableColumn.java Changeset: 8cdd7bd93393 Author: jgiles Date: 2013-07-25 17:06 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8cdd7bd93393 Fix javadoc error in TableColumn ! modules/controls/src/main/java/javafx/scene/control/TableColumn.java Changeset: 4b2f8100c18f Author: jgiles Date: 2013-07-25 17:10 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4b2f8100c18f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: ff97242a4815 Author: jgiles Date: 2013-07-26 11:29 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ff97242a4815 RT-31907: Cleanup control code (part four: generic fixes for TableView) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TableView.java Changeset: f5760de6984f Author: jgiles Date: 2013-07-26 11:36 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f5760de6984f RT-31907: Cleanup control code (part five: Yet more generic fixes) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/CellSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerHijrahContent.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledImpl.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabeledText.java ! modules/controls/src/main/java/javafx/scene/control/TableCell.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeView.java Changeset: f70737a74988 Author: jgiles Date: 2013-07-26 11:38 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f70737a74988 RT-31907: Cleanup control code (part six: Yet more generic fixes and cleanups) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SliderSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkin.java Changeset: d575789123cc Author: jgiles Date: 2013-07-26 12:04 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d575789123cc Fix build failure. ! modules/controls/src/main/java/javafx/scene/control/TableCell.java Changeset: d2e66eac7422 Author: jgiles Date: 2013-07-26 15:14 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d2e66eac7422 RT-31692: VirtualFlow : GetAvailableCell protected RT-31570: Make some VirtualFlow method protected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/VirtualFlowTest.java Changeset: 23fb663832b6 Author: jgiles Date: 2013-07-29 09:53 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/23fb663832b6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 5a8cd1d2c0bd Author: Yao Wang Date: 2013-07-23 13:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5a8cd1d2c0bd RT-31880 SpiralText got EXCEPTION_ACCESS_VIOLATION: Race condition on dispose ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTFontFile.java Changeset: 2ac36adbe491 Author: Felipe Heidrich Date: 2013-07-23 14:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2ac36adbe491 RT-31752: Getting error message ': CGAffineTransformInvert: singular matrix.' ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyph.java Changeset: 8f404415e671 Author: Felipe Heidrich Date: 2013-07-23 20:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8f404415e671 RT-31399: Label misbehaves when TextAlignment is set to JUSTIFY ! modules/graphics/src/main/java/com/sun/javafx/text/TextRun.java Changeset: dd30604ab7d0 Author: Petr Pchelko Date: 2013-07-24 11:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dd30604ab7d0 RT-26702 Poor DisplacementMap effect performance on Mac Reviewed-by: anthony, art, snorthov ! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m Changeset: a22a79de9b10 Author: Martin Sladecek Date: 2013-07-24 09:35 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a22a79de9b10 Merged AnimationPathHelper and Position2D into PathTransition ! modules/graphics/src/main/java/com/sun/javafx/TempState.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/AnimationPathHelper.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/Position2D.java ! modules/graphics/src/main/java/javafx/animation/PathTransition.java ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: 7e07bb2d6202 Author: Martin Soch Date: 2013-07-24 12:46 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7e07bb2d6202 SW pipeline: using new subPixel text API (RT-31289) ! modules/graphics/src/main/java/com/sun/pisces/PiscesRenderer.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/main/native-prism-sw/JPiscesRenderer.c ! modules/graphics/src/main/native-prism-sw/PiscesBlit.c ! modules/graphics/src/main/native-prism-sw/PiscesRenderer.h ! modules/graphics/src/main/native-prism-sw/PiscesRenderer.inl Changeset: 5eab61f82635 Author: Martin Sladecek Date: 2013-07-24 13:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5eab61f82635 Forgot to trigger pulse on requestLayout after RT-31644. ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/stub/java/javafx/scene/ParentTest.java Changeset: da8e6e3cc25c Author: Martin Sladecek Date: 2013-07-24 13:31 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/da8e6e3cc25c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt Changeset: eb0a6b4fece3 Author: Daniel Blaukopf Date: 2013-07-24 17:31 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/eb0a6b4fece3 RT-31830 GTK port of Glass not built for embedded Linux targets ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/x86egl.gradle Changeset: 7b249ef11bf7 Author: Daniel Blaukopf Date: 2013-07-24 17:39 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7b249ef11bf7 RT-27616 Set correct system font size on Embedded ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java Changeset: f2481964fc5a Author: Lisa.Selle at oracle.com Date: 2013-07-24 13:35 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f2481964fc5a Fix for rt-31220 - Virtual keyboard popup flickers when a textField gets input. ! modules/graphics/src/main/native-glass/lens/wm/LensWindowManager.c Changeset: e11609953c6b Author: Lisa.Selle at oracle.com Date: 2013-07-24 13:37 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e11609953c6b Merge Changeset: 051ec7d12a9f Author: Felipe Heidrich Date: 2013-07-24 11:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/051ec7d12a9f RT-31458: Font fallback returned by DirectWrite might not be available to JFX ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/IDWriteFont.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/OS.java ! modules/graphics/src/main/native-font/directwrite.cpp Changeset: f1be89b0bf87 Author: Felipe Heidrich Date: 2013-07-24 11:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f1be89b0bf87 RT-31476: Exception when font size is set to 0 ! 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/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/PangoGlyphLayout.java Changeset: edeb3bc0ecbc Author: rbair Date: 2013-07-24 13:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/edeb3bc0ecbc Added HelloWebView to toys ! apps/toys/Hello/src/main/java/hello/HelloRectangle3D.java + apps/toys/Hello/src/main/java/hello/HelloWebView.java Changeset: 3d5588fa9814 Author: rbair Date: 2013-07-24 14:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3d5588fa9814 RT-31906: Remove unused methods from NGShape ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape.java Changeset: 22ce97df3e10 Author: rbair Date: 2013-07-24 14:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/22ce97df3e10 Added missing import ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape.java Changeset: 517ebe5062a9 Author: rbair Date: 2013-07-24 15:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/517ebe5062a9 RT-31748: Collapse NGNode related classes with only one implementation - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseCacheFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseEffectFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseNodeEffectInput.java + modules/graphics/src/main/java/com/sun/javafx/sg/prism/CacheFilter.java + modules/graphics/src/main/java/com/sun/javafx/sg/prism/EffectFilter.java ! 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/main/java/com/sun/javafx/sg/prism/NodeEffectInput.java Changeset: aedde4d42307 Author: rbair Date: 2013-07-24 15:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/aedde4d42307 RT-31911: Fix minor issues in CacheFilter discovered via static code analysis ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/CacheFilter.java Changeset: 4e2b23d4b62e Author: rbair Date: 2013-07-24 16:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4e2b23d4b62e RT-31912: Remove unused methods from Graphics and tighten type safety ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGSubScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java ! modules/graphics/src/main/java/com/sun/prism/Graphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/null3d/DummyGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/scene/SubScene.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubScene.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/TestGraphics.java Changeset: 87026f18f632 Author: rbair Date: 2013-07-24 16:16 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/87026f18f632 RT-31913: Merge PrismCameraImpl and associated classes into NGCamera and sub classes ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGCamera.java + modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGDefaultCamera.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGParallelCamera.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGPerspectiveCamera.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGSubScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/AbstractPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/prism/Graphics.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismCameraImpl.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismDefaultCamera.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismParallelCameraImpl.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismPerspectiveCameraImpl.java ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DContext.java ! modules/graphics/src/main/java/com/sun/prism/es2/ES2Context.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseContext.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderContext.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/PaintHelper.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/null3d/DummyContext.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/PrEffectHelper.java ! modules/graphics/src/stub/java/javafx/scene/SceneTest.java ! modules/graphics/src/stub/java/javafx/scene/SubSceneTest.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/TestGraphics.java Changeset: 805cc6277790 Author: Petr Pchelko Date: 2013-07-25 11:51 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/805cc6277790 RT-31879: IllegalStateException in SwingInterop Reviewed-by: anthony, art ! modules/graphics/src/main/java/com/sun/glass/ui/Pixels.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java Changeset: 733a214814e5 Author: Artem Ananiev Date: 2013-07-25 12:20 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/733a214814e5 RT-30021: Quantum cleanup: make EmbeddedScene.host private field Reviewed-by: Anton Tarasov, Steve Northover ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedState.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/SceneState.java Changeset: f59963bc589b Author: Daniel Blaukopf Date: 2013-07-25 15:11 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f59963bc589b RT-31764 Provide a way to override DPI detected for display ! modules/graphics/src/main/java/com/sun/glass/ui/Screen.java Changeset: e6c244b0362b Author: Petr Pchelko Date: 2013-07-25 16:19 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e6c244b0362b RT-31398: Mac: Tooltips crash the JVM when hidden or closed Reviewed-by: anthony, art ! modules/graphics/src/main/native-glass/mac/GlassWindow.m Changeset: 88aa49b29342 Author: Petr Pchelko Date: 2013-07-25 16:30 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/88aa49b29342 RT-31449: Mac: Drag and drop works differently on MacOS Reviewed-by: anthony, art ! modules/graphics/src/main/native-glass/mac/GlassDragSource.h ! modules/graphics/src/main/native-glass/mac/GlassDragSource.m ! modules/graphics/src/main/native-glass/mac/GlassPasteboard.m ! modules/graphics/src/main/native-glass/mac/GlassViewDelegate.m Changeset: 911f44441269 Author: David Pulkrabek Date: 2013-07-25 15:19 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/911f44441269 iOS closed build: copying webnode resource files to dest folder ! buildSrc/ios.gradle Changeset: 1362976b7edb Author: Felipe Heidrich Date: 2013-07-25 10:29 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1362976b7edb fix for RT-31660 ! modules/graphics/src/main/native-font/directwrite.cpp Changeset: 6a87954a02d3 Author: rbair Date: 2013-07-25 11:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6a87954a02d3 Added manual region tests + .idea/RegionTests.iml ! .idea/modules.xml + 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: 2cf8414df80b Author: dmasada Date: 2013-07-25 12:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2cf8414df80b Ensemble8: DisplayShelf misses pagination bar ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/displayshelf/DisplayShelf.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/displayshelf/DisplayShelfApp.java + apps/samples/Ensemble8/src/samples/resources/ensemble/samples/graphics/displayshelf/DisplayShelf.css Changeset: 281a9fdae8bb Author: rbair Date: 2013-07-25 17:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/281a9fdae8bb RT-31945: Flatten Painter hierarchy - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/AbstractPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassAppletWindow.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassWindowEventHandler.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/OverlayWarning.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PaintCollector.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumRenderer.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/javafx/tk/quantum/ViewPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java Changeset: 70604761e83f Author: Eva Krejcirova Date: 2013-07-26 09:08 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/70604761e83f RT-31883: EffectUtils should be merged into Effect as package private API - modules/graphics/src/main/java/com/sun/javafx/effect/EffectUtils.java ! modules/graphics/src/main/java/javafx/scene/effect/Blend.java ! modules/graphics/src/main/java/javafx/scene/effect/Bloom.java ! modules/graphics/src/main/java/javafx/scene/effect/BoxBlur.java ! modules/graphics/src/main/java/javafx/scene/effect/ColorAdjust.java ! modules/graphics/src/main/java/javafx/scene/effect/ColorInput.java ! modules/graphics/src/main/java/javafx/scene/effect/DisplacementMap.java ! modules/graphics/src/main/java/javafx/scene/effect/DropShadow.java ! modules/graphics/src/main/java/javafx/scene/effect/Effect.java ! modules/graphics/src/main/java/javafx/scene/effect/GaussianBlur.java ! modules/graphics/src/main/java/javafx/scene/effect/Glow.java ! modules/graphics/src/main/java/javafx/scene/effect/ImageInput.java ! modules/graphics/src/main/java/javafx/scene/effect/InnerShadow.java ! modules/graphics/src/main/java/javafx/scene/effect/Lighting.java ! modules/graphics/src/main/java/javafx/scene/effect/MotionBlur.java ! modules/graphics/src/main/java/javafx/scene/effect/Reflection.java ! modules/graphics/src/main/java/javafx/scene/effect/SepiaTone.java ! modules/graphics/src/main/java/javafx/scene/effect/Shadow.java Changeset: 15a2bcadb625 Author: Alexander Zvegintsev Date: 2013-07-26 14:21 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/15a2bcadb625 RT-28289 Unable to determine the selected ExtensionFilter when a FileChooser closes ! modules/graphics/src/main/java/com/sun/javafx/tk/DummyToolkit.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/stage/FileChooser.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubToolkit.java ! modules/graphics/src/stub/java/javafx/stage/CommonDialogsTest.java Changeset: c29f58da1514 Author: peterz Date: 2013-07-26 14:32 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c29f58da1514 RT-31876 WebNode fails with UnsatisfiedLinkError on BeagleBoard Fixed ARM cross build ! build.gradle ! buildSrc/armv6sf.gradle Changeset: 29893e4b9ceb Author: Vasiliy Baranov Date: 2013-07-26 17:33 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/29893e4b9ceb RT-31824: fast/js/large-expressions.html is crashing again ! modules/web/src/main/native/Source/WTF/wtf/StackBounds.cpp Changeset: 74153cae7697 Author: rbair Date: 2013-07-26 08:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/74153cae7697 Added StretchyGrid toy (from days of yore!) + .idea/StretchyGrid.iml ! .idea/modules.xml + apps/toys/StretchyGrid/src/main/java/stretchygrid/StretchyGrid.java Changeset: 3f5c247aa268 Author: Pavel Safrata Date: 2013-07-26 16:38 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3f5c247aa268 RT-31713: MouseExited delivered to a node before it is removed from scene. ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/stub/java/javafx/scene/MouseTest.java Changeset: 58503961f1cb Author: rbair Date: 2013-07-26 10:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/58503961f1cb Minor typo fixes ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGGroup.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java Changeset: 21668dae41d7 Author: Chien Yang Date: 2013-07-26 12:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/21668dae41d7 Fix to RT-31949: Incorrect Javadoc for property cullFace of Shape3D class for JavaFX 8 ! modules/graphics/src/main/java/javafx/scene/shape/Shape3D.java Changeset: 074b23ebf5f1 Author: Alexander Kouznetsov Date: 2013-07-26 17:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/074b23ebf5f1 3DViewer: Added task to install 3DViewer into local maven repository. ! apps/experiments/3DViewer/build.xml Changeset: f5ba480a3e28 Author: tb115823 Date: 2013-07-29 10:59 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f5ba480a3e28 Fix RT-31510 How to use addNative for specific compile target only. List of compile targets passed as a parameter to addNative. ! build.gradle ! buildSrc/android.gradle Changeset: ff1219a1e652 Author: Martin Sladecek Date: 2013-07-29 13:33 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ff1219a1e652 RT-31919 ColorPicker, ArrayIndexOutOfBoundsException when saving custom color. ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/stub/java/javafx/scene/ParentTest.java Changeset: 26c2d5f52a6a Author: Martin Sladecek Date: 2013-07-29 13:34 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/26c2d5f52a6a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt Changeset: 5da653e8513d Author: Felipe Heidrich Date: 2013-07-29 09:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5da653e8513d RT-31324: Mac OS X 10.8, NPE is thrown when rendering complex text and bidi with some of installed fonts. ! modules/graphics/src/main/java/com/sun/javafx/font/FallbackResource.java ! modules/graphics/src/main/java/com/sun/javafx/font/LogicalFont.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/javafx/font/pango/PangoGlyphLayout.java ! modules/graphics/src/main/native-font/coretext.c Changeset: 3063916c3e1f Author: rbair Date: 2013-07-29 11:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3063916c3e1f RT-31946: ViewPainter cleanup ! modules/graphics/src/main/java/com/sun/javafx/geom/DirtyRegionPool.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PaintCollector.java ! 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/SceneState.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java ! modules/graphics/src/main/java/com/sun/prism/PresentableState.java ! modules/web/src/main/java/com/sun/javafx/webkit/prism/PrismInvoker.java Changeset: f3b79bb4e8e4 Author: rbair Date: 2013-07-29 13:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f3b79bb4e8e4 Remove bogus capital U ! modules/graphics/src/main/java/com/sun/javafx/geom/DirtyRegionPool.java Changeset: 45c7064fe74a Author: rbair Date: 2013-07-29 13:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/45c7064fe74a Removed accidental System.err call ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PaintCollector.java Changeset: e0f5a4a349d2 Author: Yao Wang Date: 2013-07-29 14:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e0f5a4a349d2 RT-31973 Text Visual Bounds need update when type changes ! modules/graphics/src/main/java/javafx/scene/text/Text.java Changeset: e1a00405bac8 Author: peterz Date: 2013-07-30 07:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e1a00405bac8 RT-31972 Webview fails with dll exception on b100 ! build.gradle Changeset: 529fa84db8a4 Author: tb115823 Date: 2013-07-30 09:14 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/529fa84db8a4 Android: Do not copy webkit native libs to artifacts. ! build.gradle Changeset: 25942f9a381e Author: tb115823 Date: 2013-07-30 09:18 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/25942f9a381e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt-closed ! build.gradle Changeset: bff33963b607 Author: Elina Kleyman Date: 2013-07-30 13:18 +0300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bff33963b607 RT-31664: Memory leak in BrickBreakerApp (Ensemble8) ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/brickbreaker/BrickBreakerApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/brickbreaker/Config.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/graphics/brickbreaker/Level.java Changeset: 32c35e8d4d54 Author: Martin Sladecek Date: 2013-07-30 14:18 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/32c35e8d4d54 RT-31965 VBox children list update not detected ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/stub/java/javafx/scene/ParentTest.java Changeset: b3056dcaa38b Author: tb115823 Date: 2013-07-30 16:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b3056dcaa38b Android: Add netbeans project for dalvik-bridge. + netbeans/android/dalvik-bridge/build.xml + netbeans/android/dalvik-bridge/local.properties + netbeans/android/dalvik-bridge/nbproject/project.xml Changeset: 749235b00a7b Author: tb115823 Date: 2013-07-30 16:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/749235b00a7b Android: Add native-glass project for Android. + netbeans/android/glass-lib-lens/Android.mk + netbeans/android/glass-lib-lens/nbproject/configurations.xml + netbeans/android/glass-lib-lens/nbproject/project.xml Changeset: 63f72d47a787 Author: Rafi Tayar Date: 2013-07-30 18:03 +0300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/63f72d47a787 RT-31762 EGLFB: VM crashed SIGSEGV when tested on R.pi hard float ! modules/graphics/src/main/native-glass/lens/LensCommon.h ! modules/graphics/src/main/native-glass/lens/LensWindow.c ! modules/graphics/src/main/native-glass/lens/wm/LensWindowManager.c Changeset: 816494a50895 Author: Rafi Tayar Date: 2013-07-30 18:03 +0300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/816494a50895 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: 78705e5c680e Author: tb115823 Date: 2013-07-30 17:17 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/78705e5c680e Android: Change includes in netbeans project native-glass. ! netbeans/android/glass-lib-lens/nbproject/configurations.xml Changeset: b1e972330e24 Author: tb115823 Date: 2013-07-30 17:18 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b1e972330e24 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: f9a6b2568deb Author: kcr Date: 2013-07-30 09:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f9a6b2568deb RT-31986: Gradle: build should fail with meaningful error message if Java version is below minimum ! build.gradle ! build.properties Changeset: e0673b2f8351 Author: jgodinez Date: 2013-07-30 09:38 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e0673b2f8351 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! build.properties - modules/graphics/src/main/java/com/sun/javafx/animation/transition/AnimationPathHelper.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/Position2D.java - modules/graphics/src/main/java/com/sun/javafx/effect/EffectUtils.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseCacheFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseEffectFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseNodeEffectInput.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/AbstractPainter.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismCameraImpl.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismDefaultCamera.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismParallelCameraImpl.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismPerspectiveCameraImpl.java Changeset: fe19fc3820f3 Author: kcr Date: 2013-07-30 12:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fe19fc3820f3 [TEST-ONLY] disable failing unit test until RT-31990 is fixed ! modules/web/src/test/java/javafx/scene/web/LoadTest.java Changeset: 5a2bdb89b8a1 Author: hudson Date: 2013-08-01 08:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5a2bdb89b8a1 Added tag 8.0-b101 for changeset fe19fc3820f3 ! .hgtags From swpalmer at gmail.com Thu Aug 1 10:07:21 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 1 Aug 2013 13:07:21 -0400 Subject: Missed "pulse"? In-Reply-To: References: Message-ID: That wouldn't apply to me because I am setting all the constraints before adding the node to the scene graph. Scott On Thu, Aug 1, 2013 at 11:47 AM, Diego Cirujano-Cuesta < diego.cirujano-cuesta at zeiss.com> wrote: > I had problems when we were using column constraints with a fixed size. > Something like this: > > ColumnConstraints cc = new ColumnConstraints(); > cc.setMaxWidth(ColumnConstraints.CONSTRAIN_TO_PREF); > cc.setPrefWidth(x); > > So there was a ScrollPane with a Gridpane inside and the size of the > gridpane was defined by the with of all columns. The thing was that calling > setPrefWidth wasn?t triggeing a pulse. > > This is what I found but during the optimization I found out that anothe > pane was better for my case, so I don't use it anymore. > > Regards. > > > > > From: Scott Palmer > To: Diego Cirujano-Cuesta > Cc: "openjfx-dev at openjdk.java.net" > Date: 31.07.2013 16:42 > > Subject: Re: Missed "pulse"? > ------------------------------ > > > > Interesting. The problem outlined in RT-31025 does involve GridPane with > ColumnConstraints. I will try to dig up the code. > > Scott > > > > On Wed, Jul 31, 2013 at 4:47 AM, Diego Cirujano-Cuesta <* > diego.cirujano-cuesta at zeiss.com* > wrote: > Hi Scott, > > I have a component quite similar to the one you described and I also had > problems like the ones that you mentioned with the same workarounds. BUT I > found out that the problem was of my understanding. One of the problems > was, I was using invalidation listeners and I wasn't getting always the > value and another problem was a gridPane with column constraints. > > I had a look deeply and I fix them, now they work perfect. > > I saw in Jira you sent your code to Eva. If you want, you can send me the > problem also(with the isolated code) I can have a look or much better, Eva > could publish the code in Jira. I am interested. > > Regards, > > Diego > > >(I'm talking JavaFX2.x, but this happens in 8 as well.) > > >In my application I occasionally see a situation where the rendering > doesn't jive with what it should. For example I have implemented my own > scroll pane (ironically enough I did this to workaround manifestations of a > problem similar to what I am about to describe in the stock ScrollPane) > using clipping and translations, but sometimes I see the clipped content at > the wrong location. So my clipped content is offset from the edge of my > pane, or rendered over top of things outside my pane, even though it is > impossible for the clipping and translating to not be set together. If I > mouse over the offending area it suddenly snaps to the way it should be > (CSS rules on the content would have forced it to redraw). > > >In other situations, I may need to coax a proper rendering of certain > layouts by nudging the size of something to force another layout. > > >Obviously things should just paint correctly the first time. In these > situations, the variables appear to be set to the correct values, but > somehow that didn't get to the screen. > > >I'm not certain, but I suspect I might be able to work around these issues > if I could force a "pulse" or mark things as dirty some way to trigger one. > The thing is, there doesn't seem to be a publicly accessible way to do > this, presumably because it isn't supposed to be necessary in the first > place. > >Platform.runLater(... requestLayout ...) was one workaround that I started > to use, in the cases where things were particularly bad, but it isn't the > sort of things I want to have to scatter throughout my code.. > > >With recent testing on JavaFX 8 I had to remove some of my workarounds > because they caused a stack overflow doing layout. In requestLayout, I > would call requestLayout directly on some specific child nodes (without a > runLater) that seemed to misbehave - somehow this got back to call > requestLayout again in my class and a quick attempt to break the cycle > didn't work. > > >I'm sure you can appreciate the frustration in trying to ship a > professional quality application with this sort of instability in the > rendering system. > > >Since I suspect these issues aren't going to be fixed before 7u40 ships, > and 8 is a long way off, what is the best thing to do? I have already > filed bugs for issues in a few specific cases. E.g. > RT-31025<*https://javafx-jira.kenai.com/browse/RT-31025*> > (In > > some cases from a long time ago I was unsure if I was doing something wrong > so I may not have isolated things into a test case and reported a bug.) > > > >Regards, > > >Scott > > > ---------------------------------------- > This message is intended for a particular addressee only and may contain > business or company secrets. If you have received this email in error, > please contact the sender and delete the message immediately. Any use of > this email, including saving, publishing, copying, replication or > forwarding of the message or the contents is not permitted. > > > > > ---------------------------------------- > This message is intended for a particular addressee only and may contain > business or company secrets. If you have received this email in error, > please contact the sender and delete the message immediately. Any use of > this email, including saving, publishing, copying, replication or > forwarding of the message or the contents is not permitted. > > From hang.vo at oracle.com Thu Aug 1 11:48:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 18:48:55 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130801184944.F0BCA4853D@hg.openjdk.java.net> Changeset: dff7ba8f08ec Author: Yao Wang Date: 2013-08-01 10:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dff7ba8f08ec RT-26111 Use glyph bounding boxes to get visual bounds ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java ! modules/graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java ! modules/graphics/src/main/java/javafx/scene/text/Text.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubTextLayout.java Changeset: 350038269859 Author: Felipe Heidrich Date: 2013-08-01 11:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/350038269859 minor fix for StubTextLayout caused by RT-26111 ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubTextLayout.java From richard.bair at oracle.com Thu Aug 1 12:11:00 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Aug 2013 12:11:00 -0700 Subject: Build failures In-Reply-To: References: <1BDD8680-89D7-487A-B7AE-0BB94F48E9FA@oracle.com> Message-ID: <6D6C891E-AF64-40A9-AAD0-B3A49A3AD0D7@oracle.com> > By the way, can I suggest moving away from the forest hg extension - it's no longer supported & can't be made to work reliably on Mac. Which page did you see this one? I see this on the Building OpenJFX wiki page: "(Note: Historically you also had to clone the "jfx" repository in the forest that you cared about. However we have modified our approach, such that we no longer promote the use of a forest, and instead are putting all of our sources in a single repository, presently named "rt")." We actually don't use the forest extension on OpenJFX at all anymore, if we're still referring to it on a page I'll fix it. Also, are you using the OpenJFX master, or OpenJFX Controls or OpenJFX graphics repo? Graphics / Controls are the daily team repos, master being only sync'd up weekly. > I'm attempting to get OpenJFX built & running against the tip of Nashorn. OK the first question I have is to make sure I understand correctly. Do you mean that you're trying to build the latest OpenJFX + the latest Nashorn, combine them into a single JDK build, and then write an app that uses both? Is Nashorn developed in a different repo, like OpenJFX is, or is it now built as part of the normal JDK 8? > > Assuming it is, it still isn't working. After a certain amount of > > yak-shaving (Gradle being useless, and having to hack around the forest > > extension gunk) the build is failing (details below). Why did you need forest? Maybe if we start here with where the yak shaving exercise started then maybe I can see where you may have left the beaten path. > > /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar Which build of Java 8 is this? > > :fxpackager:compileLauncher > > In file included from > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6, > > from > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, > > from > > /Users/boxcat/projects/openjdk/master/rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26: > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12:20: > > error: stdarg.h: No such file or directory I'm building with 10.8 rather than 10.7. Kevin do you know what the hudson machines are setup to build with? Looking at main.m line 26 we see this import: #import It seems that something must be misconfigured on your system if importing Cocoa.h leads to a compile error. I'm not an expert on Mac native programming, maybe Felipe or David Dehaven can chime in? Thanks Richard From richard.bair at oracle.com Thu Aug 1 12:52:34 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Aug 2013 12:52:34 -0700 Subject: A different way to handle pulse timing In-Reply-To: <51FA5296.2050009@oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> Message-ID: > as far as I can read it, your idea is to start preparing the next frame right after synchronization (scenegraph to render tree) is completed for the previous frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem with input events starvation. There will be no or very little window, when the events can be processed on the event thread, because the thread will always be either busy handling CSS, animations, etc., or blocked waiting for the render thread to finish rendering. I think the difference is that I was going to use the vsync as the limiter. That is, the first time through we do a pulse, then we schedule another pulse, then we run that other pulse (almost immediately), then we hit the sync point with the render thread and have to wait for it because it is blocked on vsync. Meanwhile the user events are being queued up. When we get back from this, the next pulse is placed on the end of the queue, we process all input events, then the next pulse. >> Whenever an animation starts, the runningAnimationCounter is >> incremented. When an animation ends, it is decremented (or it could >> be a Set or whatever). The pendingPulse is simply false to >> start with, and is checked before we submit another pulse. Whenever a >> node in the scene graph becomes dirty, or the scene is resized, or >> stylesheets are changed, or in any case something happens that >> requires us to draw again, we check this flag and fire a new pulse if >> one is not already pending. > > Scene graph is only changed on the event thread. So my guess is that "fire a new pulse" is just > > Platform.runLater(() -> pulse()) Right. >> When a pulse occurs, we process animations first, then CSS, then >> layout, then validate all the bounds, and *then we block* until the >> rendering thread is available for synchronization. I believe this is >> what we are doing today (it was a change Steve and I looked at with >> Jasper a couple months ago IIRC). >> >> But now for the new part. Immediately after synchronization, we check >> the runningAnimationCounter. If it is > 0, then we fire off a new >> pulse and leave the pendingPulse flag set to true. If >> runningAnimationCounter == 0, then we flip pendingPulse to false. >> Other than the pick that always happens at the end of the pulse, we >> do nothing else new and, if the pick didn't cause state to change, we >> are now quiescent. >> >> Meanwhile, the render thread has run off doing its thing. The last >> step of rendering is the present, where we will block until the thing >> is presented, which, when we return, would put us *immediately* at >> the start of the next 16.66ms cycle. Since the render thread has just >> completed its duties, it goes back to waiting until the FX thread >> comes around asking to sync up again. >> >> If there is an animation going on such that a new pulse had been >> fired immediately after synchronization, then that new pulse would >> have been handled while the previous frame was being rendered. Most >> likely, by the time the render thread completes presenting and comes >> back to check with the FX thread, it will find that the FX thread is >> already waiting for it with the next frames data. It will synchronize >> immediately and then carry on rendering another frame. > > Given that you propose to fire a new pulse() whenever anything is changed in scene graph, and also right after synchronization, there is no need to have an external timer (QuantumToolkit.pulseTimer()) any longer. Correct. >> I think the way this would behave is that, when an animation is first >> played, you will get two pulses close to each other. The first pulse >> will do its business and then synchronize and then immediately fire >> off another pulse. That next pulse will then also get processed and >> then the FX thread will block until the previous frame finishes >> rendering. During this time, additional events (either application >> generated via runLater calls happening on background threads, or from >> OS events) will get queued up. Between pulse #2 and pulse #3 then a >> bunch of other events will get processed, essentially playing >> catch-up. My guess is that this won't be a problem but you might see >> a hiccup at the start of a new animation if the event queue is too >> full and it can't process all that stuff in 16ms (because at this >> point we're really multi-theaded between the FX and render threads >> and have nearly 16ms for each thread to do their business, instead of >> only 8ms which is what you'd have in a single threaded system). >> >> Another question I have is around resize events and how those work. >> If they also come in to glass on the FX thread (but at a higher >> priority than user events like a pulse or other input events?) then >> what will happen is that we will get a resize event and process a >> half-a-pulse (or maybe a whole pulse? animations+css+layout or just >> css+layout?) and then render, pretty much just as fast as we can. >> >> As for multiple scenes, I'm actually curious how this happens today. >> If I have 2 scenes, and we have just a single render thread servicing >> both, then when I go to present, it blocks? Or is there a >> non-blocking present method that we use instead? Because if we block, >> then having 2 scenes would cut you down to 30fps maximum, wouldn't > > This is a very interesting question... Experiments show that we can have more than one window/scene running at 60 fps. Someone from the graphics team should comment on this. My only guess (at least, in case of D3D pipeline) that present() doesn't block, if it's called no more than once between vsyncs (but the frame is shown on the screen on vsync anyway). And certainly with full-speed enabled we aren't blocking. The way I guess this would have to work is that if we have 10 scenes to render, we will end up rendering them all and then only block on the last render. My goal is to use the video card as the timer, in essence, such that: a) We have a full 16.666ms for the render thread to do its business each time and b) We never have "timer drift" between some external timer and the vsync timer There is potentially another benefit which is that we don't ever need to enable hi-res timers on Windows or whatnot, and never put the machine in a "non power save" state. Richard From richard.bair at oracle.com Thu Aug 1 12:57:34 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Aug 2013 12:57:34 -0700 Subject: Is it possible to use OpenJDK to develop (and execute ) JAVA FX Application? In-Reply-To: <984693099B29AC4289F387DC2E100A47343FAF89@G4W3211.americas.hpqcorp.net> References: <984693099B29AC4289F387DC2E100A47343FAF89@G4W3211.americas.hpqcorp.net> Message-ID: <773A0A66-EB75-4A6F-A63F-1B5465FF66B0@oracle.com> I would image you should be able to run an FX app on OpenJDK with no problems, as long as you aren't using Applets or WebStart. Richard On Aug 1, 2013, at 2:59 AM, "K, Dhevendran (MSDU)" wrote: > Hi > > I need some clarification on integrating JAVA FX application with OpenJDK 7. > > We have developed JAVA FX application using Oracle JDK (with help of Netbeans 7.3.1 IDE) . Now, We would like to use OpenJDK in place of Oracle JDK . Is it possible to use OpenJDK to develop (and execute ) JAVA FX Application? . As we have to use OpenJDK ( not OracleJDK) ,let me know whether this is possible in some other way. > > Thanks & Regards > Dhevendran K > > > From richard.bair at oracle.com Thu Aug 1 13:33:47 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Aug 2013 13:33:47 -0700 Subject: Mixing 2D and 3D In-Reply-To: <51F96C32.9060500@oracle.com> References: <51F96C32.9060500@oracle.com> Message-ID: <34B1E065-76C0-4E7D-A54A-586D0FE26D2C@oracle.com> > - What is the minimum space taken for "new Node()" these days? Is that too heavyweight for a 3D scene with hundreds or thousands of "things", whatever granularity we have, or come to have, for our Nodes? I think each Node is going to come in somewhere between 1.5-2K in size (I haven't measured recently though so it could be worse or better). In any case, it is fairly significant. The "StretchyGrid" toy in apps/toys had 300K nodes and the performance limitation appeared to be on the rendering size rather than the scene graph side (other than sync overhead which was 16ms, but I was just looking at pulse logger and didn't do a full analysis with profiling tools). So although a node isn't cheap, I think it is cheap enough for a hundred thousand nodes or so on reasonably beefy hardware. On a small device with crappy CPU, we're looking at a thousand or so nodes max. > - How often do those attributes get used on a 3D object? If one is modeling an engine, does one really need every mesh to be pickable, or are they likely to be multi-mesh groups that are pickable? In other words, you might want to pick on the piston, but is that a single mesh? And is the chain that connects it to the alternator a single mesh or a dozen meshes per link in the chain with 100 links? (Yes, I know that alternators use belts, but I'm trying to come up with meaningful examples.) I think this is a good question also applicable to 2D. For example I have a bunch of nodes that are in a TableView, but for many of these they don't need to be individually pickable. We do optimize for this in memory though by "bucketing" the properties. So if you don't use any of the mouse listeners, you only pay for a single null field reference on the Node. As soon as you use a single mouse event property (add a listener, set a value), then we inflate it to an object that holds the implementation for those listeners. So there are games we can play here so that just having this API on a node is actually very inexpensive. Most of the cost (last time I measured) of a Node is actually in the bounds & transforms, which we duplicated on Node and NGNode. And that state we really can't get away without. One thing we talked about in the past was having a way to "compile" a portion of a scene graph. So you could describe some nodes and then pass it to a method which would "compile" it down to an opaque Node type that you could put state on. Maybe there is still a big NG node graph behind the scenes, but once you've compiled it, it is static content (so no listeners etc). Anyway, I'm not sure if it is useful or not. > - How does picking work for 3D apps? Is the ability to add listeners to individual objects good or bad? I assume it is basically the same as 2D. There will be some elements in the screen you want to be pickable / get listeners (key listeners, mouse listeners, etc) but most things won't be. > - How does picking interact with meshes that are tessellated on the fly? Does one ever want to know which tessellated triangle was picked? I could imagine a design application (like Cheetah 3D or something) being interested in this, but with on-card geometry shaders doing LOD-based dynamic tessellation, I think it is something we would not expose in API. Somebody would have to actually create a mesh that complicated (and I guess we'd have to allow picking a particular part of the mesh). So in real 3D we'd not be able to guarantee picking of any geometry, but we could potentially allow picking of any geometry known about on the FX level (in a mesh). Right now they are one-in-the-same, but when we start supporting on-card tessellation, the FX-known geometry will be a subset of all the real geometry on the card. I imagine it is similar to 2D. In 2D we say "here is a rounded rectangle" but in reality we might represent this with any kind of geometry on the card (right now it is just a quad, but we've talked about having a quad for the interior and others for the exterior such that the interior is just a solid opaque quad and the edges transparent quads for AA, such that on-card occlusion culling of fragments could be used). > How does that fit in with the 2D-ish picking events we deliver now? If a cylinder is picked, how do we describe which part of the cylinder was picked? Pavel or Chien will have to pipe in on this part of the question, I don't know. > - Are umpteen isolated 2D-ish transform attributes a convenient or useful way to manipulate 3D objects? Or do we really want occasional transforms inserted in only a few places that are basically a full Affine3D because when you want a transform, you are most likely going to want to change several attributes at once? 2D loves isolated just-translations like candy. It also tends to like simple 2D scales and rotates around Z here and there. But doesn't 3D love quaternion-based 3-axis rotations and scales that very quickly fill most of the slots of a 3x3 or 4x3 matrix? I think that in 3D you definitely use the bigger transforms more. However I think that the simple transforms are also useful. Particularly since we have those various Transition classes to animate stuff around. I think we want to have a Transition class for doing 3D transitions as well. > - Right now our Blend modes are pretty sparse, representing some of the more common equations that we were aware of, but I'm not sure how that may hold up in the future. I can implement any blending equation that someone feeds me, and optimize the heck out of the math of it - but I'm pretty unfamiliar with which equations are useful to content creators in the 2D or 3D world or how they may differ now or in our evolution. This is a good question. There are some blend modes GL supports, but for the ones that GL doesn't natively support, how would we implement those? That is, we could say "in 3D we don't flatten we just change the blend mode used on the card" but I'm not sure that works. > - How will the nodes, and the granularity they impose, enable or prevent getting to the point of an optimized bundle of vector and texture information stored on the card that we tweak and re-trigger? I should probably start reading up on 3D hw utilization techniques. 8( I think having a scene graph helps us here and we're in good shape. This is one of the things I want to do after positioning prism for multi-threading, because the ideas are related. In order to do multi-threading, we have to be able to compute per-node what the drawing commands are (all on background threads) and then combine them all together into a sequence of draw commands that get sent to the card in one go at the end. If we had such a system, it would be easy to persist those commands from frame to frame on the Java side (allowing us to skip a bunch of work on each frame for a node that has to be drawn but hasn't changed). It isn't a far leap from there to storing the drawing commands on the card instead of in Java (or at least the vertex information on the card). > - Looking at the multi-camera issues I keep coming back to my original pre-mis-conceptions of what 3D would add wherein I was under the novice impression that we should have 3D models that live outside the SG, but then have a 3DView that lives in the SG. Multiple views would simply be multiple 3DView objects with shared models similar to multiple ImageViews vs. a small number of Image objects. I'm not a 3D person so that was simply my amateur pre-conception of how 3D would be integrated, but I trust the expertise that went into what we have now. In this pre-concept, though, there were fewer interactions of "3Disms" and "2Disms" - and much lighter weight players in the 3D models. We actually aren't that far off from this view, in that most of the really complicated things people will do will be with a big complicated Mesh displayed in a MeshView (analogous to Image in ImageView). Cameras and such are defined externally so that you can have multiple separate models loaded together. But I imagine that in *most* use cases, people will be off building a 2D app and then create a SubScene configured for 3D and construct their 3D scene graph in there. Its just that they'll be building it using the same node types and API that they are already using, except mostly 3D variants. I was thinking yesterday that there is even a place for 2D rectangles and such in a 3D world, particularly if you have a Paint type that includes bump-map information (normals) that we could define. For example, I could have a gradient where the stops not only have rgba values, but also normals. I seem to remember talking I think with Burkey about this in the past in that we could then have a CSS style sheet to style UI controls such that they would appear to have 3D surface to them. In this way being able to drop UI controls into a 3D app makes sense. > - In looking briefly at some 3D-lite demos it looks like there are attempts to do higher quality AA combined with depth sorting, possibly with breaking primitives up so that they depth sort more cleanly. Some docs on the CSS3 3D attributes indicate particular algorithms that they recommend for slicing up the 2D objects to allow for back to front ordering that allows alpha to mix better with Z while not necessarily targeting the kinds of performance one might want for pure 3D. Such techniques would also allow us to do the algorithmic AA that runs into trouble in the "circles" demo that Richard showed, but those techniques don't scale well. On the other hand, it allows for things like the CSS3 demo that has 4 images on rotating fan blades with alpha - very pretty, but probably not done in a way that would facilitate a model of a factory with 10K parts to be tracked (in particular, you can't do that with just a Z-buffer alone due to the constantly re-sorted alpha): Right, I think the CSS 3D techniques make sense for a 2D-pipeline with 2.5D type 3D rendering, but not for a real 3D pipeline. So if you're just rotating a few planes around in 3D, then it works well, but if you're modeling Duke and Tux in a lightsaber duel, then you really are looking at a completely different rendering pipeline being what you want (with more traditional 3D techniques like BSP trees or whatnot to make sure the transparent triangles are sorted correctly, or something even more radical like depth-peeling). The more I think on it the more it makes sense to me that we ought to have a "2D" pipeline wherein you can do 3D stuff but it all fits according to 2D semantics, and a 3D pipeline for doing real 3D work. As time goes on, we could expose ways for developers to provide their own shaders for the 3D pipeline, which might not make as much sense on the 2D side of the world. Cheers Richard From richard.bair at oracle.com Thu Aug 1 13:38:42 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Aug 2013 13:38:42 -0700 Subject: Mixing 2D and 3D In-Reply-To: <006201ce8e2a$8ef87020$ace95060$@ozemail.com.au> References: <51F96C32.9060500@oracle.com> <006201ce8e2a$8ef87020$ace95060$@ozemail.com.au> Message-ID: <1D9988E5-75D0-4669-9F43-DFBF7F08E5CA@oracle.com> > I intend to agree with you that Node may be "too big" to use as the basis > for a 3D model's triangles and quads given that there can easily be millions > of them and that manipulating or interacting with them on an individual > basis is mostly unlikely. As you say, storing those models outside the > scenegraph seems to make sense... I agree. We don't use Nodes as the basis for 3D model's mesh, we have a separate Mesh class which does this very efficiently (Mesh==Image, MeshView==ImageView). Richard From richard.bair at oracle.com Thu Aug 1 13:40:45 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Aug 2013 13:40:45 -0700 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> Message-ID: <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> Something I guess would go on such a page? http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ On Aug 1, 2013, at 3:21 AM, Anton Epple wrote: > Great idea, there's a site that does the same for NetBeans Platform Apps: > > https://platform.netbeans.org/screenshots.html > > I can tell from my own experience that it helps a lot in discussions with customers to show them that NASA, NATO, Boeing, UNO, US Army, and many others are building on top of NB Platform. > > From the maintainer of this site, I know there's a lot of work involved though, and you have to be very active in identifying users, and reaching out to them. It's definitely not sufficient to wait for users to submit their applications. Sometimes it can take a couple of years from first contact to a screenshot. That said it's absolutely worth it, and I would volunteer to help in any way I can. > > Toni > > -- > Anton Epple > > > > Am 28.07.2013 um 02:38 schrieb Jonathan Giles : > >> This is something that Jasper actually brought up just this morning with Richard and I (wrt fxexperience hosting it). I suspect we may get something underway in the coming weeks. Of course, it depends on the community getting in touch with us and letting us talk about them - so much of the JavaFX world is behind corporate firewalls, where talking about your work is generally frowned upon. In any case, for those of you that can talk about your work, please email one of us off-list. >> -- Jonathan >> Sent from a touch device. Please excuse my brevity. >> >> "John C. Turnbull" wrote: >>> +1 >>> >>> Such a site could be very useful. >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel >>> Zwolenski >>> Sent: Sunday, 28 July 2013 09:56 >>> To: Pedro Duque Vieira >>> Cc: OpenJFX Mailing List >>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) >>> >>> The idea of a JFX Sightings page (in the tradition of the Swing >>> Sightings >>> page) has been raised before and I think is a good one. >>> >>> It deserves it's own page though, that technet section isn't up to it >>> in my >>> opinion. >>> >>> Personally I think this would be great under the fxexperience site as >>> it >>> partners nicely with the links of the week? >>> >>> >>> >>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira >>> >>> wrote: >>> >>>> I have an Swing/JavaFX app, the site is: http://modellus.co >>>> >>>> How can I get it to be on that real world usecases section? Or does >>> it >>>> not have the necessary requirements to be in it? >>>> >>>> Thanks, best regards, >>>> >>>> @John: On the JavaFx community site they have a section with >>>> references to >>>>> real world usecases. >>>>> http://www.oracle.com/technetwork/java/javafx/community/index.html >>>>> >>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull >>>>> >>>>> wrote: >>>>>> Like Daniel said, none of what we say is in any way a criticism of >>>>>> the JavaFX development team who, in my view and that of the entire >>>>>> community, are doing an awesome job. >>>>>> >>>>>> >>>>>> >>>>>> For mine, all the shortcomings of JavaFX (perceived or actual) can >>>>>> be >>>>> blown >>>>>> away if I could just demonstrate what JavaFX is really capable of. >>>>>> >>>>>> >>>>>> >>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras (whose >>>>>> demo incidentally doesn't run since Java 7 Update 21). With Oracle >>> >>>>>> Ensemble >>>>> we >>>>>> can see that JavaFX has quite a nice set of basic controls and that >>> >>>>>> it at least supports very simple animations. With JFXtras Ensemble >>> >>>>>> we can see that very nice controls are possible but unfortunately >>>>>> many of these are >>>>> of >>>>>> a rather "whimsical" nature and not the kind of control you would >>>>>> use in everyday business apps. >>>>>> >>>>>> >>>>>> >>>>>> What else is there? >>>>>> >>>>>> >>>>>> >>>>>> Of course we have rock stars like Gerrit Grunwald who frequently >>>>>> post awesome controls and code snippets but we really need >>> something >>>>>> that >>>>> brings >>>>>> it altogether in a kick-arse showcase. Preferably a whole suite of >>>>> killer >>>>>> apps that highlights everything JavaFX is capable of. >>>>>> >>>>>> >>>>>> >>>>>> Yes, that would require a lot of effort but IMHO it is absolutely >>>>>> worth >>>>> it. >>>>>> Without it, people like me really struggle to sell JavaFX or even >>>>>> get a handle on its true potential. I can promise people that more >>> >>>>>> advanced things are "possible" but given that they write the >>>>>> cheques, they need to see it for themselves. >>>>>> >>>>>> >>>>>> >>>>>> And how about a website of JavaFX reference sites? There must be >>>>>> big companies out there using it right? >>>>>> >>>>>> >>>>>> >>>>>> In the end it doesn't matter if I personally see enormous potential >>> >>>>>> for JavaFX if I cannot convince others to see what I see. >>>>>> >>>>>> >>>>>> >>>>>> -jct >>>>>> >>>>>> >>>>>> >>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] >>>>>> Sent: Saturday, 27 July 2013 09:12 >>>>>> To: John C. Turnbull >>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net >>>>>> Subject: Re: Can JavaFX do CAD? >>>>>> >>>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> >>>>>> >>>>>> I've failed to convince multiple clients that they should use JFX >>>>>> because of >>>>>> >>>>>> >>>>>> a) lack of examples of what it can really do, and how to make it do >>> >>>>>> that (e.g. in enterprise space we have >>>>>> http://static.springsource.org/docs/petclinic.html) >>>>>> >>>>>> b) lack of any big or notable players out there actually using it, >>>>>> or at least publicly saying they are using it >>>>>> >>>>>> c) the deployment hassles vs the ease of html app deployment and >>> the >>>>>> true cross-platform-ness of html >>>>>> >>>>>> >>>>>> >>>>>> After actually getting one client to trust me on it and use it on a >>> >>>>>> real, commercial app (startup), I hit problems with performance >>>>>> (broad interpretation of the term, not 'framerate'), crippling >>>>>> deployment and >>>>> auto >>>>>> updating issues, missing basic features (e.g. maximise button, >>>>>> coming in >>>>>> 2014 I believe?), unpredictability of CSS styling, and a lack of >>>>>> best practices for things like how to do CAD-like diagrams (not so >>>>>> much render performance but zooming, panning, mouse input, >>> layering, >>> dragging, etc). >>>>>> >>>>>> >>>>>> >>>>>> Like John, I've been guilty of letting my frustration show in these >>>>> forums. >>>>>> Like John, it's because I want so badly for JavaFX to be the >>>>>> platform I develop on, it has the potential to be awesome, but >>>>>> things (that seem obvious and small to me) completely stop it from >>>>>> being usable in a real world situation for me. >>>>>> >>>>>> >>>>>> >>>>>> It's not that we think the JFX team aren't slogging their guts out, >>>>> clearly >>>>>> you are. It's just that in some key areas, there are small-ish >>>>>> blocks >>>>> that >>>>>> stop the whole rocket from launching. To then see a whole lot of >>>>>> effort >>>>> be >>>>>> poured into things like binary CSS/FXML compilation, Pi platform >>>>>> support (that's more important than iOS/Android, really?), web >>>>>> deployment >>>>> patches, >>>>>> or even 3D (as cool as that is), just knocks me about. Obviously >>>>>> your priorities are coming from somewhere different to ours, but >>> the >>>>>> way you prioritise is unfathomable to me and that definitely adds >>> to >>>>>> the frustration. >>>>>> >>>>>> >>>>>> >>>>>> At this stage, I am not suggesting my clients use JFX (I actively >>>>>> discourage them from it, in their interest). Mobile is the area >>> that >>>>>> has the >>>>> potential >>>>>> to bring JFX back into usable for me as it can compete easier with >>>>>> the current technologies (which are all crap). Maybe if that ends >>> up >>>>>> working >>>>> (a >>>>>> long, long road to go on that and very much an 'if') then it will >>>>>> seep >>>>> back >>>>>> into the desktop for me, but at a minimum the desktop deployment >>>>>> options will need to be improved before that's even a possibility. >>>>>> >>>>>> >>>>>> I've come to accept that I am not in the primary target audience >>> for >>>>>> JavaFX, maybe a secondary target. I don't understand who the >>> primary >>>>>> target is though, and knowing/accepting doesn't make it any less >>>>>> frustrating. I >>>>> keep >>>>>> involved in the hope that I might get a usable platform somewhere >>>>>> along >>>>> the >>>>>> way but it's more of a hope than a belief. >>>>>> >>>>>> >>>>>> >>>>>> So nothing really new above, but just adding my voice to John's. >>>>>> JavaFX >>>>> is >>>>>> definitely not production ready for me, my clients and the types of >>> >>>>>> apps >>>>> I >>>>>> build (e.g. consumer facing online systems, enterprise/backoffice >>>>> systems, >>>>>> form/data systems, diagramming systems). One day I hope it will be, >>> >>>>>> but it's moving extremely slowly or not at all in the areas that >>>>>> would make it so for me. Meanwhile the competitors (primarily >>>>>> JavaScript based solutions) are improving rapidly in the areas >>> where >>>>>> they have traditionally been weak. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < >>>>> ozemale at ozemail.com.au >>>>>> > wrote: >>>>>> >>>>>> Hi Richard, >>>>>> >>>>>> I have to stop posting late at night, that one came across as >>> really >>>>> ANGRY! >>>>>> >>>>>> It's not anger, it's passion... and frustration. >>>>>> >>>>>> I am frustrated because I spend much of my day trying to convince >>> my >>>>>> employer that we should be using JavaFX. They ask me questions >>> like: >>>>>> >>>>>> "What happens if Oracle abandons JavaFX just like Sun did with JMF, >>>>> Java3D, >>>>>> JOGL etc. ?" >>>>>> >>>>>> I say: >>>>>> >>>>>> "This is Oracle, not Sun." >>>>>> >>>>>> They say: >>>>>> >>>>>> "Can you show me what JavaFX can do? There must be examples out >>>>>> there right?" >>>>>> >>>>>> And I say: >>>>>> >>>>>> "Sure, here's Ensemble." >>>>>> >>>>>> They say: >>>>>> >>>>>> "OK, so it has a nice set of basic controls and can do simple >>>>>> animations but what about more complex things like Flash?" >>>>>> >>>>>> ...hence the dancing cat reference. >>>>>> >>>>>> It's not that my employer *needs* dancing cats, it's just that they >>> >>>>>> need >>>>> to >>>>>> see that there is more to JavaFX than red circle transitions. I >>>>>> can't >>>>> even >>>>>> prove to them that JavaFX is capable of dancing cats. They don't >>>>>> have >>>>> the >>>>>> resources to fund me to develop something more sophisticated but >>>>>> they >>>>> tell >>>>>> me that if JavaFX truly was a "mature" technology (like I tell >>> them) >>>>>> then where are all the examples? >>>>>> >>>>>> I am finding it difficult to convince them that JavaFX is >>> production >>>>> ready >>>>>> and is not still in "experimental" mode because I am unable to >>>>> demonstrate >>>>>> its true capabilities or refer them to many examples of people (and >>> >>>>>> I >>>>> mean >>>>>> big companies) actually using it. >>>>>> >>>>>> The main concerns of my employer and I think many companies in a >>>>>> similar situation is that JavaFX won't survive long term and that >>> it >>>>>> is only >>>>> really >>>>>> suitable for form based applications. Then of course there is the >>>>>> whole >>>>>> "HTML5 runs on all platforms" argument but that's another story... >>>>>> >>>>>> So this is why I think it's imperative that Oracle invests in >>>>>> developing >>>>> a >>>>>> true showcase application for JavaFX. Something that non-technical >>>>> people >>>>>> (like managers who make decisions about where the money goes) can >>>>>> look at it and go "wow!". >>>>>> >>>>>> I am just not getting my managers to go "wow" at what I can show >>>>>> them >>>>> with >>>>>> JavaFX at the moment. >>>>>> >>>>>> Every comment or apparent criticism I post about JavaFX is from the >>> >>>>>> perspective that I am trying to deal with real-world problems and >>>>>> people who require proof (such as demos, reference sites etc.) and >>>>>> not because I myself think JavaFX is not up to scratch. >>>>>> >>>>>> It's quite the opposite actually. >>>>>> >>>>>> I am a very, very strong believer and supporter of JavaFX and have >>>>>> many reasons both personal and professional as to why I want it to >>>>>> be a >>>>> massive >>>>>> success. As I have said before, there are plenty of people who >>>>>> praise JavaFX and tend to avoid the very real issues that are >>>>>> restricting its adoption. I just think we have to face these >>> issues >>>>>> head on if we are to compete in what is a very cut-throat industry. >>>>>> >>>>>> -jct >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Richard Bair [mailto:richard.bair at oracle.com >>>>>> ] >>>>>> Sent: Saturday, 27 July 2013 01:40 >>>>>> To: John C. Turnbull >>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net >>>>>> >>>>>> Subject: Re: Can JavaFX do CAD? >>>>>> >>>>>>> For Flash, there are literally millions of examples of >>>>>>> fancy/complex/impressive graphics and animations out there that >>> can >>>>>>> be really impressive at times. I have not seen ONE such example >>> in >>>>> JavaFX! >>>>>> >>>>>> Point to one? >>>>>> >>>>>> Have you seen any of the JavaOne examples? The movie wall or movies >>> >>>>>> on a stack of 3D cubes was pretty good. But I guess you're not >>>>>> interested in >>>>> the >>>>>> 3D aspect? What is it you are looking for exactly? Different people >>> >>>>>> (on this >>>>>> list) have had different perceptions on both (a) what's important >>>>>> and (b) what kind of graphics they're interested in. Most people >>>>>> would deride the dancing cat as being totally irrelevant to the >>>>>> types of applications they're trying to build (the basis for much >>> of >>>>>> flash animations is shape >>>>> morphing, >>>>>> you can find some code here >>> https://gist.github.com/gontard/5029764). >>>>>> >>>>>> On the other hand, JavaFX is not a replacement for OpenGL. Drawing >>>>>> 25 million lines is just not something we can do right now, >>>>>> especially in a resource constrained environment. I've already >>>>>> commented on the memory overhead (which would continue to be an >>>>>> issue even if the drawing part of the problem were solved). >>>>>> >>>>>> I've pushed to graphics repo the StretchyGrid, which is about 300k >>>>>> line nodes (the actual amount is variable, see the javadoc >>>>>> comments). At 300k nodes the scene graph overhead is negligible on >>>>>> the FX side, dirty opts >>>>> is >>>>>> taking a long time to run, and painting is really slow. >>>>>> >>>>>> PULSE: 347 [122ms:222ms] >>>>>> T12 (8 +0ms): CSS Pass >>>>>> T12 (8 +0ms): Layout Pass >>>>>> T12 (47 +53ms): Waiting for previous rendering >>>>>> T12 (100 +1ms): Copy state to render graph >>>>>> T10 (101 +16ms): Dirty Opts Computed >>>>>> T10 (117 +105ms): Painted >>>>>> Counters: >>>>>> Nodes rendered: 306565 >>>>>> Nodes visited during render: 306565 >>>>>> >>>>>> If I were doing this by hand in open GL, I think the drawing would >>>>>> be essentially free, if I used LINES with GL anti-aliasing, I could >>> >>>>>> send 'em all down to the card in a single shot (and if I had a >>>>>> modern GL I could >>>>> do >>>>>> LINES + FXAA or one of the other per-pixel AA algorithms available >>>>>> and it would turn out pretty nice). Because our shapes don't >>>>>> implement the >>>>> non-AA >>>>>> path, and our AA involves software rasterization and uploading of >>>>> pixels, I >>>>>> expect that to be the main source of the 105ms time being spent >>> here. >>>>>> >>>>>> Also I noticed (by turning on prism.showdirty=true) that the entire >>> >>>>>> grid >>>>> is >>>>>> being painted every time, even though visually it looks like only a >>> >>>>>> small subset actually needs to be changed. But that's really a >>> minor >>>>>> thing, as >>>>> I >>>>>> said, drawing this many lines should basically be free if I >>>>>> configure "smooth" to false in the app. Except that right now it is >>> >>>>>> totally not implemented (in NGShape): >>>>>> >>>>>> public void setAntialiased(boolean aa) { >>>>>> // We don't support aliased shapes at this time >>>>>> } >>>>>> >>>>>> The point of stretchy grid is not to say "wow look at this amazing >>> demo". >>>>>> The point is to say "what happens if I put in 300K nodes. Where >>> does >>>>>> the system start to fall over?". >>>>>> >>>>>> Richard= >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Pedro Duque Vieira > From james.graham at oracle.com Thu Aug 1 13:53:26 2013 From: james.graham at oracle.com (Jim Graham) Date: Thu, 01 Aug 2013 13:53:26 -0700 Subject: Mixing 2D and 3D In-Reply-To: <1D9988E5-75D0-4669-9F43-DFBF7F08E5CA@oracle.com> References: <51F96C32.9060500@oracle.com> <006201ce8e2a$8ef87020$ace95060$@ozemail.com.au> <1D9988E5-75D0-4669-9F43-DFBF7F08E5CA@oracle.com> Message-ID: <51FACAC6.8010105@oracle.com> There is one Mesh per MeshView and MeshView is a Node, so we require a node per mesh. But, a mesh can have millions of triangles. As long as they all have a common material... ...jim On 8/1/13 1:38 PM, Richard Bair wrote: >> I intend to agree with you that Node may be "too big" to use as the basis >> for a 3D model's triangles and quads given that there can easily be millions >> of them and that manipulating or interacting with them on an individual >> basis is mostly unlikely. As you say, storing those models outside the >> scenegraph seems to make sense... > > I agree. We don't use Nodes as the basis for 3D model's mesh, we have a separate Mesh class which does this very efficiently (Mesh==Image, MeshView==ImageView). > > Richard > From hang.vo at oracle.com Thu Aug 1 14:33:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 21:33:59 +0000 Subject: hg: openjfx/8/graphics/rt: [eclipse only] Adding RegionTests to the classpath Message-ID: <20130801213448.8132848545@hg.openjdk.java.net> Changeset: 6279340ebb9d Author: Felipe Heidrich Date: 2013-08-01 14:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6279340ebb9d [eclipse only] Adding RegionTests to the classpath ! .classpath From hang.vo at oracle.com Thu Aug 1 14:34:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 21:34:10 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130801213507.0477E48546@hg.openjdk.java.net> Changeset: d4657711e052 Author: jgiles Date: 2013-08-02 08:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d4657711e052 Backed out changeset: d9f804166732 ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: 970027341fc2 Author: jgiles Date: 2013-08-02 08:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/970027341fc2 Adding in missing DefaultTreeCell impl + modules/controls/src/main/java/javafx/scene/control/cell/DefaultTreeCell.java From tobi at ultramixer.com Thu Aug 1 14:41:07 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Thu, 1 Aug 2013 23:41:07 +0200 Subject: current state of gradle script for Android? In-Reply-To: <51FA69F9.1040402@oracle.com> References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> <51FA69F9.1040402@oracle.com> Message-ID: Thanks Tomas, after changing android.gradle script line "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.4.3?)? to "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could successfully build OpenJFX for Android von Mac OS X 10.9! So now I?m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in ?com.oracle.dalvik? package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? Best regards, Tobi Am 01.08.2013 um 16:00 schrieb tomas.brandalik : > The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. > http://developer.android.com/sdk/index.html > http://developer.android.com/tools/sdk/ndk/index.html > -Tomas > > On 08/01/2013 03:41 PM, Tobias Bley wrote: >> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? >> >> Thanks! >> Tobi >> >> >> Am 31.07.2013 um 16:42 schrieb tomas.brandalik : >> >>> Hi Tobi, >>> it works on linux only right now. >>> Set properties for cross build and android sdk/ndk. >>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >>> Closed source parts web and font-t2k will be missing. >>> >>> -Tomas >>> >>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>> Hi, >>>> >>>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>>> >>>> Best regards, >>>> Tobi >>>> > From hang.vo at oracle.com Thu Aug 1 14:48:24 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 21:48:24 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-31998, forward port of RT-31701: HiDPI: Effects position are wrong Message-ID: <20130801214927.B41A548547@hg.openjdk.java.net> Changeset: 9c612891d297 Author: flar Date: 2013-08-01 14:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9c612891d297 Fix RT-31998, forward port of RT-31701: HiDPI: Effects position are wrong ! modules/graphics/src/main/jsl-decora/InvertMask.jsl From hang.vo at oracle.com Thu Aug 1 15:03:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 22:03:16 +0000 Subject: hg: openjfx/8/controls/rt: Minor Intellij project update Message-ID: <20130801220402.5A3FE48548@hg.openjdk.java.net> Changeset: 72059831a447 Author: rbair Date: 2013-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/72059831a447 Minor Intellij project update ! .idea/vcs.xml From zonski at gmail.com Thu Aug 1 15:08:03 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 2 Aug 2013 08:08:03 +1000 Subject: How to raise JavaFX iOS bugs? Message-ID: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls? From steve.x.northover at oracle.com Thu Aug 1 15:53:09 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 01 Aug 2013 18:53:09 -0400 Subject: How to raise JavaFX iOS bugs? In-Reply-To: References: Message-ID: <51FAE6D5.7050304@oracle.com> Yes please enter bugs. Please make sure they are specific to iOS. I am seeing the one that you are talking about (it's wierd). I'm going to see whether it happens on my pi. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: > So now the Maven stuff is working ( > http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), > I'm gradually starting to muck around with the iOS stuff. > > There are problems - how do I raise them? Should I log JIRAs? Should I > bring them up here, etc? Will you guys start running jfx on iOS now that > it's possible and are bug fixes within your allowance to work on given iOS > is not a supported platform? > > For example, in the hello world example, I've included a TextField. When I > start typing in it on my iPad the field starts changing size to accommodate > the auto-correction popup, which looks very weird. Should I log that as a > bug against Controls? From hang.vo at oracle.com Thu Aug 1 16:17:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 01 Aug 2013 23:17:26 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-24343: missing doc comments in PixelFormat classes Message-ID: <20130801231754.740034854E@hg.openjdk.java.net> Changeset: 469677a7c799 Author: flar Date: 2013-08-01 16:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/469677a7c799 Fix RT-24343: missing doc comments in PixelFormat classes ! modules/graphics/src/main/java/javafx/scene/image/PixelFormat.java ! modules/graphics/src/main/java/javafx/scene/image/WritablePixelFormat.java From hang.vo at oracle.com Thu Aug 1 17:17:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 00:17:45 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31249: Mechanism to identify application Message-ID: <20130802001817.57F8048550@hg.openjdk.java.net> Changeset: 83f1dd37a34d Author: kcr Date: 2013-08-01 17:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/83f1dd37a34d RT-31249: Mechanism to identify application ! modules/graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java From hang.vo at oracle.com Thu Aug 1 18:17:48 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 01:17:48 +0000 Subject: hg: openjfx/8/controls/rt: RT-24400: Incorrect work ctrl+backspace and ctrl+delete in TextArea. Message-ID: <20130802011857.1386948552@hg.openjdk.java.net> Changeset: 7b779c15ce73 Author: rbair Date: 2013-08-01 18:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7b779c15ce73 RT-24400: Incorrect work ctrl+backspace and ctrl+delete in TextArea. Summary: The problem is that the nextWord / previousWord methods on TextInputControl did not correctly handle cases where numbers are in the stream of characters. There may be additional issues related to symbols and how breaking should occur. Also some of this might be OS specific (on Mac it breaks in some places, on Windows someplace else). However this should fix the SQE tests. ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/test/java/javafx/scene/control/TextInputControlTest.java From hang.vo at oracle.com Thu Aug 1 19:04:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 02:04:17 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130802020508.3F98B48555@hg.openjdk.java.net> Changeset: d0e9bba74866 Author: Chien Yang Date: 2013-08-01 18:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d0e9bba74866 Add Netbeans project for 3D apps/toys projects Add 3D moving camera tests. + apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCamera.java + apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCameraSubScene.java + netbeans/appsToys/FX8-3DFeatures/build.xml + netbeans/appsToys/FX8-3DFeatures/manifest.mf + netbeans/appsToys/FX8-3DFeatures/nbproject/build-impl.xml + netbeans/appsToys/FX8-3DFeatures/nbproject/genfiles.properties + netbeans/appsToys/FX8-3DFeatures/nbproject/project.properties + netbeans/appsToys/FX8-3DFeatures/nbproject/project.xml + netbeans/appsToys/ShapeT3D/build.xml + netbeans/appsToys/ShapeT3D/manifest.mf + netbeans/appsToys/ShapeT3D/nbproject/build-impl.xml + netbeans/appsToys/ShapeT3D/nbproject/genfiles.properties + netbeans/appsToys/ShapeT3D/nbproject/project.properties + netbeans/appsToys/ShapeT3D/nbproject/project.xml Changeset: a22540914163 Author: Chien Yang Date: 2013-08-01 18:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a22540914163 Change title name ! apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCameraSubScene.java From tobi at ultramixer.com Fri Aug 2 00:28:37 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 2 Aug 2013 09:28:37 +0200 Subject: JavaFX On IOS Using RoboVM And Maven In-Reply-To: References: Message-ID: <6A0752D6-DC2E-4A1E-AA9B-AC6AE4C53A35@ultramixer.com> Hi Daniel, thanks for your great work! One question: How can I use third party jar libraries? When I execute the ?compile? maven task, my third party libs are not found? Best, Tobi Am 01.08.2013 um 05:34 schrieb Daniel Zwolenski : > The RoboVM Maven plugin is now released with JFX support using Danno's > backport, which is all in Maven Central. > > I talk about it in detail here: > http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/ > > I'd greatly appreciate people here trying it out and letting me know fairly > quickly if there are any steps I left out or if anything is not working (in > terms of the hello world, not bigger issues at this stage). > > Every time I release or publish something I get a lot of "I don't know how > to code and couldn't get past step 2" type requests. These can be very time > consuming to work through, since some are real and some are just > stupid-user-exceptions. Anything I can head off at the pass is a boon. > > As per the post, yes, it's slow, yes, it's buggy, yes, it all looks pretty > crap at the moment - but it's suppose to. The JFX code has barely been run > by the people who wrote it and the RoboVM code is being developed by one > guy part time and has not been optimised at all. The fact that it works at > all is down right amazing. > > The point of releasing this code is so the above issues can start being > addressed, it's not meant to be perfect. If you want it better, I'm sure > Niklas, Danno and Richard are only too happy for you to help out in each of > the respective areas where there are known issues. > > No one ever wants to help out with the build tools, that's a crap job that > no sane person would do in their spare time :) From anton.tarasov at oracle.com Fri Aug 2 00:55:36 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 02 Aug 2013 11:55:36 +0400 Subject: Multiple JFXPanel? In-Reply-To: References: Message-ID: <51FB65F8.6090300@oracle.com> Hi Pedro, I've made the following experiment. I've created two simple test cases: one is pure fx stage showing WebView which animated some guimark2 benchmarks, another one is the same WebView wrapped with JFXPanel put in JFrame. I ran each test case with a single, two or four toplevels (Stages or JFrames, appropriately) and measured performance difference. I noticed that for the swing test case, adding more toplevels decreased performance with the same proportion like the fx test case did (despite the fact that fx performed relatively faster, of course). For instance, for the Vector Charting Test the ratio was directly proportional to the number of toplevels, that is doubling the toplevels decreased performance by two times equally for both fx and swing cases. This more or less proves the fact that adding another embedded scene into your app doesn't bring anything except another scene. Thanks, Anton. On 01.08.2013 2:45, Pedro Duque Vieira wrote: > Hi, > > I have a doubt. I have a swing app with embed javafx scene. My app has kind > of a MDI style interface. Right now only one window has been converted to > JavaFX, basically it's a window with a JFXPanel in it. > My question is if I want to convert the other windows as well should I also > put a JFXPanel in them? I would than have 2 JFXPanels in my app, does that > mean I would have 2 JavaFX scenes? Is that the way to do it? Would that > seriously hurt performance? > > Thank you in advance, best regards, > From tomas.brandalik at oracle.com Fri Aug 2 01:59:26 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Fri, 02 Aug 2013 10:59:26 +0200 Subject: current state of gradle script for Android? In-Reply-To: References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> <51FA69F9.1040402@oracle.com> Message-ID: <51FB74EE.9050505@oracle.com> On 08/01/2013 11:41 PM, Tobias Bley wrote: > Thanks Tomas, > > after changing android.gradle script line "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.4.3?)? to "defineProperty("ANDROID_CROSS_TOOLS_VER", If toolchain version changed you just need to pass property -PANDROID_CROSS_TOOLS_VER=arm-linux-androideabi-4.6 > "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could successfully build OpenJFX for Android von Mac OS X 10.9! I will have a look at it. > > So now I?m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in ?com.oracle.dalvik? package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? The fx project for android looks like usual android project except that it bundles with the vm image. All essential parameters (main class, debug port, parametets etc) are in AndroidManifest.xml If you look at FXApplication you will realize that it installs vm first and then launches fx application on that vm. FXApplication activity does very little just prepares a surface where to draw opengl stuff. I'm sure you see the catch ... the vm is not available yet. Another option to consider is to run on dalvik which I think is doable with a rewriting the launcher and using compatibility project javafx78 (or how's that called). -Tomas > > Best regards, > Tobi > > > Am 01.08.2013 um 16:00 schrieb tomas.brandalik : > >> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. >> http://developer.android.com/sdk/index.html >> http://developer.android.com/tools/sdk/ndk/index.html >> -Tomas >> >> On 08/01/2013 03:41 PM, Tobias Bley wrote: >>> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? >>> >>> Thanks! >>> Tobi >>> >>> >>> Am 31.07.2013 um 16:42 schrieb tomas.brandalik : >>> >>>> Hi Tobi, >>>> it works on linux only right now. >>>> Set properties for cross build and android sdk/ndk. >>>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >>>> Closed source parts web and font-t2k will be missing. >>>> >>>> -Tomas >>>> >>>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>>> Hi, >>>>> >>>>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>>>> >>>>> Best regards, >>>>> Tobi >>>>> From zonski at gmail.com Fri Aug 2 02:31:08 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 2 Aug 2013 19:31:08 +1000 Subject: JavaFX On IOS Using RoboVM And Maven In-Reply-To: <6A0752D6-DC2E-4A1E-AA9B-AC6AE4C53A35@ultramixer.com> References: <6A0752D6-DC2E-4A1E-AA9B-AC6AE4C53A35@ultramixer.com> Message-ID: What third party libs are you using? Basically you should use the standard maven way of including dependencies which means adding a dependency entry to your pom.xml. So if you want MigLayout for example you would add: com.miglayout miglayout-javafx 4.2 This will download the jar and add it to your classpath. The robovm plugin will then include this in the robovm build. See this for more details: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html A lot of libraries most people use are in maven central: http://search.maven.org/ But if it's something not in central you can add it to your own system manually: http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html Let me know if you need more info. On 02/08/2013, at 5:28 PM, Tobias Bley wrote: > Hi Daniel, > > thanks for your great work! > > One question: How can I use third party jar libraries? When I execute the ?compile? maven task, my third party libs are not found? > > Best, > Tobi > > > Am 01.08.2013 um 05:34 schrieb Daniel Zwolenski : > >> The RoboVM Maven plugin is now released with JFX support using Danno's >> backport, which is all in Maven Central. >> >> I talk about it in detail here: >> http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/ >> >> I'd greatly appreciate people here trying it out and letting me know fairly >> quickly if there are any steps I left out or if anything is not working (in >> terms of the hello world, not bigger issues at this stage). >> >> Every time I release or publish something I get a lot of "I don't know how >> to code and couldn't get past step 2" type requests. These can be very time >> consuming to work through, since some are real and some are just >> stupid-user-exceptions. Anything I can head off at the pass is a boon. >> >> As per the post, yes, it's slow, yes, it's buggy, yes, it all looks pretty >> crap at the moment - but it's suppose to. The JFX code has barely been run >> by the people who wrote it and the RoboVM code is being developed by one >> guy part time and has not been optimised at all. The fact that it works at >> all is down right amazing. >> >> The point of releasing this code is so the above issues can start being >> addressed, it's not meant to be perfect. If you want it better, I'm sure >> Niklas, Danno and Richard are only too happy for you to help out in each of >> the respective areas where there are known issues. >> >> No one ever wants to help out with the build tools, that's a crap job that >> no sane person would do in their spare time :) > From hang.vo at oracle.com Fri Aug 2 05:02:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 12:02:33 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26551 Gtk: Behavior of events sending changed Message-ID: <20130802120400.C6D974856C@hg.openjdk.java.net> Changeset: c6ca49ab6269 Author: Alexander Zvegintsev Date: 2013-08-02 15:41 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c6ca49ab6269 RT-26551 Gtk: Behavior of events sending changed RT-29576 Gtk: Scrolling stops in the combobox popup when the pointer leaves the slider box ! modules/graphics/src/main/native-glass/gtk/glass_gtkcompat.cpp ! modules/graphics/src/main/native-glass/gtk/glass_gtkcompat.h ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp ! modules/graphics/src/main/native-glass/gtk/glass_window.h From tom.schindl at bestsolution.at Fri Aug 2 05:31:13 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 02 Aug 2013 14:31:13 +0200 Subject: JavaFX 2 memory leaks in StyleManager (making FX2 completely unusable for application development) In-Reply-To: <51F7CD9F.5000903@oracle.com> References: <51F7A36B.1010500@bestsolution.at> <51F7CD9F.5000903@oracle.com> Message-ID: <51FBA691.8010708@bestsolution.at> Hi Kevin, I have created a sample application and filed https://javafx-jira.kenai.com/browse/RT-32087 I've uploaded the sources, memory dumps, ... to http://downloads.efxclipse.org/memoryleak/. There are 2 remarkable things if you look at the memory screenshots. memory2.png: Runs the application without the CSS-Images so one can see that the application after sometime holds > 9.000 Cell-Objects who naturally holds other node objects memory1.png: Shows that the CSS is loading image instance for each and every ImageView although we are only one image-url! So after this test I think the CSSEngine is not really leaking images but is loading too many of them although it could reuse them. The really leaking component is ListView which leaks all its list cells. The good thing is that FX8 does not show this problems (no image duplication, no leaked cells) but FX8 is more than 6 months away and those two problems above make FX2.2 completely unusable (one can workaround the CSS-Bug by simply *not* useing Images in CSS) but for ListCell one there's no work-around at all available (beside not using ListView)! Tom On 30.07.13 16:28, Kevin Rushforth wrote: > What version of JDK 7u/FX 2.2.x is this reproduced in? Have you tried > this with a recent build of JDK 7u40? There is a vanishingly small > window to get changes into 7u40 / FX 2.2.40 which is scheduled for > release in the first half of September. The next opportunity would be > January. > > -- Kevin > > > Tom Schindl wrote: >> [resending because mail was blocked yesterday because of included images] >> Hi, >> >> I've been debugging a JavaFX application with a customer and we've found >> a tremendous memory leak in StyleManager when using icons. >> >> This bug makes JavaFX 2.x completely unusable because the application is >> using up to 1.5GB and more within a few mintues! Has anyone seen this >> and if I file a bug could I expect a bugfix in FX2? >> >> The screenshots from the Memory Analyzer can be seen at: >> http://www.efxclipse.org/image001.png >> http://www.efxclipse.org/image002.png >> >> Tom >> From kevin.rushforth at oracle.com Fri Aug 2 05:34:26 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 02 Aug 2013 05:34:26 -0700 Subject: JavaFX 2 memory leaks in StyleManager (making FX2 completely unusable for application development) In-Reply-To: <51FBA691.8010708@bestsolution.at> References: <51F7A36B.1010500@bestsolution.at> <51F7CD9F.5000903@oracle.com> <51FBA691.8010708@bestsolution.at> Message-ID: <51FBA752.3030608@oracle.com> Hi Tom, I have raised the priority to P2 and assigned it to Jonathan to evaluate. -- Kevin Tom Schindl wrote: > Hi Kevin, > > I have created a sample application and filed > https://javafx-jira.kenai.com/browse/RT-32087 > > I've uploaded the sources, memory dumps, ... to > http://downloads.efxclipse.org/memoryleak/. > > There are 2 remarkable things if you look at the memory screenshots. > > memory2.png: Runs the application without the CSS-Images so one can see > that the application after sometime holds > 9.000 > Cell-Objects who naturally holds other node objects > > memory1.png: Shows that the CSS is loading image instance for each and > every ImageView although we are only one image-url! > > So after this test I think the CSSEngine is not really leaking images > but is loading too many of them although it could reuse them. The really > leaking component is ListView which leaks all its list cells. > > The good thing is that FX8 does not show this problems (no image > duplication, no leaked cells) but FX8 is more than 6 months away and > those two problems above make FX2.2 completely unusable (one can > workaround the CSS-Bug by simply *not* useing Images in CSS) but for > ListCell one there's no work-around at all available (beside not using > ListView)! > > Tom > > On 30.07.13 16:28, Kevin Rushforth wrote: > >> What version of JDK 7u/FX 2.2.x is this reproduced in? Have you tried >> this with a recent build of JDK 7u40? There is a vanishingly small >> window to get changes into 7u40 / FX 2.2.40 which is scheduled for >> release in the first half of September. The next opportunity would be >> January. >> >> -- Kevin >> >> >> Tom Schindl wrote: >> >>> [resending because mail was blocked yesterday because of included images] >>> Hi, >>> >>> I've been debugging a JavaFX application with a customer and we've found >>> a tremendous memory leak in StyleManager when using icons. >>> >>> This bug makes JavaFX 2.x completely unusable because the application is >>> using up to 1.5GB and more within a few mintues! Has anyone seen this >>> and if I file a bug could I expect a bugfix in FX2? >>> >>> The screenshots from the Memory Analyzer can be seen at: >>> http://www.efxclipse.org/image001.png >>> http://www.efxclipse.org/image002.png >>> >>> Tom >>> >>> > > From artem.ananiev at oracle.com Fri Aug 2 05:59:44 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 02 Aug 2013 16:59:44 +0400 Subject: A different way to handle pulse timing In-Reply-To: References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> Message-ID: <51FBAD40.10907@oracle.com> On 8/1/2013 11:52 PM, Richard Bair wrote: >> as far as I can read it, your idea is to start preparing the next >> frame right after synchronization (scenegraph to render tree) is >> completed for the previous frame. Do I get it correctly? If yes, >> we'll likely re-introduce the old problem with input events >> starvation. There will be no or very little window, when the events >> can be processed on the event thread, because the thread will >> always be either busy handling CSS, animations, etc., or blocked >> waiting for the render thread to finish rendering. > > I think the difference is that I was going to use the vsync as the > limiter. That is, the first time through we do a pulse, then we > schedule another pulse, then we run that other pulse (almost > immediately), then we hit the sync point with the render thread and > have to wait for it because it is blocked on vsync. Meanwhile the > user events are being queued up. When we get back from this, the next > pulse is placed on the end of the queue, we process all input events, > then the next pulse. I now see the picture. As I wrote in the previous email, it seems that we currently are not blocked waiting for vsync(), at least on Windows with D3D pipeline. Anyway, even if we "fix" that, what you propose is that sometimes both threads will be blocked (the render thread waiting for vsync, the event thread waiting for the render thread), which doesn't sound perfect. Note that on Windows and Mac OS X, input events and application runnables are handled differently at the native level (either using different mechanisms, or having different priorities). To implement this proposal, we'll need to eliminate the difference, which may be a difficult task. Thanks, Artem >>> Whenever an animation starts, the runningAnimationCounter is >>> incremented. When an animation ends, it is decremented (or it could >>> be a Set or whatever). The pendingPulse is simply false to >>> start with, and is checked before we submit another pulse. Whenever a >>> node in the scene graph becomes dirty, or the scene is resized, or >>> stylesheets are changed, or in any case something happens that >>> requires us to draw again, we check this flag and fire a new pulse if >>> one is not already pending. >> >> Scene graph is only changed on the event thread. So my guess is that "fire a new pulse" is just >> >> Platform.runLater(() -> pulse()) > > Right. > >>> When a pulse occurs, we process animations first, then CSS, then >>> layout, then validate all the bounds, and *then we block* until the >>> rendering thread is available for synchronization. I believe this is >>> what we are doing today (it was a change Steve and I looked at with >>> Jasper a couple months ago IIRC). >>> >>> But now for the new part. Immediately after synchronization, we check >>> the runningAnimationCounter. If it is > 0, then we fire off a new >>> pulse and leave the pendingPulse flag set to true. If >>> runningAnimationCounter == 0, then we flip pendingPulse to false. >>> Other than the pick that always happens at the end of the pulse, we >>> do nothing else new and, if the pick didn't cause state to change, we >>> are now quiescent. >>> >>> Meanwhile, the render thread has run off doing its thing. The last >>> step of rendering is the present, where we will block until the thing >>> is presented, which, when we return, would put us *immediately* at >>> the start of the next 16.66ms cycle. Since the render thread has just >>> completed its duties, it goes back to waiting until the FX thread >>> comes around asking to sync up again. >>> >>> If there is an animation going on such that a new pulse had been >>> fired immediately after synchronization, then that new pulse would >>> have been handled while the previous frame was being rendered. Most >>> likely, by the time the render thread completes presenting and comes >>> back to check with the FX thread, it will find that the FX thread is >>> already waiting for it with the next frames data. It will synchronize >>> immediately and then carry on rendering another frame. >> >> Given that you propose to fire a new pulse() whenever anything is changed in scene graph, and also right after synchronization, there is no need to have an external timer (QuantumToolkit.pulseTimer()) any longer. > > Correct. > >>> I think the way this would behave is that, when an animation is first >>> played, you will get two pulses close to each other. The first pulse >>> will do its business and then synchronize and then immediately fire >>> off another pulse. That next pulse will then also get processed and >>> then the FX thread will block until the previous frame finishes >>> rendering. During this time, additional events (either application >>> generated via runLater calls happening on background threads, or from >>> OS events) will get queued up. Between pulse #2 and pulse #3 then a >>> bunch of other events will get processed, essentially playing >>> catch-up. My guess is that this won't be a problem but you might see >>> a hiccup at the start of a new animation if the event queue is too >>> full and it can't process all that stuff in 16ms (because at this >>> point we're really multi-theaded between the FX and render threads >>> and have nearly 16ms for each thread to do their business, instead of >>> only 8ms which is what you'd have in a single threaded system). >>> >>> Another question I have is around resize events and how those work. >>> If they also come in to glass on the FX thread (but at a higher >>> priority than user events like a pulse or other input events?) then >>> what will happen is that we will get a resize event and process a >>> half-a-pulse (or maybe a whole pulse? animations+css+layout or just >>> css+layout?) and then render, pretty much just as fast as we can. >>> >>> As for multiple scenes, I'm actually curious how this happens today. >>> If I have 2 scenes, and we have just a single render thread servicing >>> both, then when I go to present, it blocks? Or is there a >>> non-blocking present method that we use instead? Because if we block, >>> then having 2 scenes would cut you down to 30fps maximum, wouldn't >> >> This is a very interesting question... Experiments show that we can have more than one window/scene running at 60 fps. Someone from the graphics team should comment on this. My only guess (at least, in case of D3D pipeline) that present() doesn't block, if it's called no more than once between vsyncs (but the frame is shown on the screen on vsync anyway). > > And certainly with full-speed enabled we aren't blocking. The way I guess this would have to work is that if we have 10 scenes to render, we will end up rendering them all and then only block on the last render. My goal is to use the video card as the timer, in essence, such that: > > a) We have a full 16.666ms for the render thread to do its business each time and > b) We never have "timer drift" between some external timer and the vsync timer > > There is potentially another benefit which is that we don't ever need to enable hi-res timers on Windows or whatnot, and never put the machine in a "non power save" state. > > Richard > From hang.vo at oracle.com Fri Aug 2 07:02:28 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 14:02:28 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28295 Update libxml2 library to the latest version Message-ID: <20130802140308.D9B7048570@hg.openjdk.java.net> Changeset: 16f605590496 Author: peterz Date: 2013-08-02 17:56 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/16f605590496 RT-28295 Update libxml2 library to the latest version On Windows, jfxwebkit.dll is now statically linked to the latest libxml2/libxslt ! build.gradle ! modules/web/src/main/native/Source/WebCore/TargetJava.pri From hang.vo at oracle.com Fri Aug 2 09:32:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 16:32:53 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130802163358.BFCD348581@hg.openjdk.java.net> Changeset: a4d7b7b2daa2 Author: rbair Date: 2013-08-02 09:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a4d7b7b2daa2 Made some fields final, fixed a javadoc issue. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: 97ff822bb664 Author: rbair Date: 2013-08-02 09:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/97ff822bb664 Removed EMPTY_BINDINGS and use instead Collections.emptyList(). One less field, but more important, the EMPTY_BINDINGS wasn't immutable so there was a possibility of a bug there, whereas now there is not. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java From hang.vo at oracle.com Fri Aug 2 09:47:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 16:47:36 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31428 TableCellFactory sample doesn't cancel editing completely Message-ID: <20130802164844.2DC0F48582@hg.openjdk.java.net> Changeset: bfa38efb69fa Author: dmasada Date: 2013-08-02 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bfa38efb69fa RT-31428 TableCellFactory sample doesn't cancel editing completely - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/CheckBoxTableCell.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/EditingCell.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/TableCellFactoryApp.java From hang.vo at oracle.com Fri Aug 2 10:53:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 17:53:08 +0000 Subject: hg: openjfx/2u/dev/rt: Added tag 2.2.40-b36 for changeset 8d0655bd2163 Message-ID: <20130802175311.EBDE148584@hg.openjdk.java.net> Changeset: c2c325536f52 Author: hudson Date: 2013-07-31 15:38 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/c2c325536f52 Added tag 2.2.40-b36 for changeset 8d0655bd2163 ! .hgtags From tom.schindl at bestsolution.at Fri Aug 2 11:29:54 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 02 Aug 2013 20:29:54 +0200 Subject: JavaFX and iOS - it will remain a dream In-Reply-To: References: <48A47A75-7C7A-429E-9833-2BF1C47B2CEE@ultramixer.com> <67FFC84C-EF91-4C29-B815-D8B804C9A231@bestsolution.at> Message-ID: <51FBFAA2.7090109@bestsolution.at> Hi, Like advertised I've now the first thing to show off. Part of our nightly e(fx)clipse build we generate a *self-contained* FXML-Compiler jar which anyone interested can download from [1]. We currently provide an ant-integration (I'm not 100% happy on how I make sure the appropriate classpath is chosen) which looks like this: > > > > > > > > > > > If you want to compile single FXML-Files you can invoke the jar on the commandline line this: java -cp org.eclipse.fx.fxml.compiler_0.9.0-SNAPSHOT.jar \ org.eclipse.fx.ide.fxml.compiler.FXGraphCompiler \ $fxmlFile \ $packageRoot $fxmlFile ... absolute path to your file $packageRoot ... absolute path to the package-root (to construct the package) so on my localhost I execute it with the like this: java -cp org.eclipse.fx.fxml.compiler_0.9.0-SNAPSHOT.jar:\ /tmp/compilersample/test/bin \ org.eclipse.fx.ide.fxml.compiler.FXGraphCompiler \ /tmp/compilersample/src/test/Test.fxml \ /tmp/compilersample/src/ I've also uploaded a sample project to [2]. Tom [1] http://download.eclipse.org/efxclipse/compiler-nightly/org.eclipse.fx.fxml.compiler_0.9.0-SNAPSHOT.jar [2] http://downloads.efxclipse.org/fxml-compiler.zip On 31.07.13 16:42, Danno Ferrin wrote: > Where is the code base for this converter? Done properly it can also be > written to spit out the generated stubs, as well as output in any > language the user may prefer. A top grade implementation could > integrate with FXMLLoader for a seamless experience ala .bss files. > > On Tuesday, July 30, 2013, Tom Schindl wrote: > > I don't think it is a good idea to use fxml on embedded and mobile, > we are working on a fxml => java converter so you can add it to your > build process. > > Tom > > Von meinem iPhone gesendet > > Am 31.07.2013 um 08:11 schrieb Niklas Therning >: > > >>>> after many days trying to really build iOS apps with JavaFX and > RoboVM > >> or > >>>> Avian I?m very frustrated because of the following things: > >>>> > >>>> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don?t > know > >> the > >>>> reason - maybe it?s the rendering model of JavaFX - maybe it?s the > >>>> currently unoptimized RoboVM > >>>> One big problem of RoboVM is it?s dependence of the Android > library, it > >>>> does not support the OpenJDK. That?s a big reason for many many > >> problems > >>>> when using JavaFX. So currently it?s not possible to use fxml files > >>>> (FXMLoader) because of the missing Stax xml parser and classes like > >>>> XMLInputFactory in the android library? > > > > There's now a compatibility library for the jfx78 backport which > includes > > the missing sun.* classes from OpenJDK [1]. So that will not be a > problem > > when running on RoboVM/Android. Daniel Zwolenski is working on > getting this > > into Maven which will make it nice and easy to develop with > RoboVM+OpenJFX. > > > > FXMLLoader relies an StAX and the Java Scripting API. Those can > both be > > made to work on RoboVM/Android. The POM of the compat project [1] > contains > > optional dependencies on the StAX API and JSR 223 API. For StAX > you'll also > > need a StAX provider [2][3]. For scripting you'll need a JSR 223 > > implementation of the scripting language you're using, like Rhino for > > JavaScript [4][5]. Please note that I haven't tested FXML but it > should > > work (in theory at least ;-) ). Please give it a go. It will be a > great > > blog story if you can make it work on iOS. > > > > As for the performance issues with RoboVM+OpenJFX: those WILL be > addressed! > > You can either wait for it to happen or you can help out. One way > to do > > that would be sample code that exercises the code paths that need > to be > > optimized (e.g. the button rendering you posted about earlier). > Preferably > > the sample should run repeatedly without user interaction. You > should then > > be able to run Apple's Instruments application to profile this > sample. This > > will help us determine what needs to be optimized. > > > > /Niklas > > > > [1] https://github.com/robovm/robovm-jfx78-compat > > [2] https://github.com/FasterXML/aalto-xml > > [3] http://woodstox.codehaus.org/ > > [4] https://developer.mozilla.org/en-US/docs/Rhino > > [5] > > > https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236 > From hang.vo at oracle.com Fri Aug 2 11:47:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 18:47:37 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130802184836.D831E48585@hg.openjdk.java.net> Changeset: a01a090e0477 Author: rbair Date: 2013-08-02 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a01a090e0477 RT-32102: TreeView on Mac does not use cmd+ctrl+space for toggling selection ! 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: 226250c9e7f9 Author: rbair Date: 2013-08-02 11:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/226250c9e7f9 Minor fixes to BehaviorBase. Made convenience traverse methods final, all pointing to the single non-final method that does all the work. Made sure the keyBindings field is unmodifiable. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java From hang.vo at oracle.com Fri Aug 2 14:17:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 21:17:37 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30365 FX 8 3D: Remove predefine 3d shapes' local mesh Message-ID: <20130802211819.D038E4859E@hg.openjdk.java.net> Changeset: 79cd77093f2d Author: Yao Wang Date: 2013-08-02 14:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/79cd77093f2d RT-30365 FX 8 3D: Remove predefine 3d shapes' local mesh ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGBox.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGCylinder.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGSphere.java From hang.vo at oracle.com Fri Aug 2 14:17:35 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 21:17:35 +0000 Subject: hg: openjfx/8/controls/rt: RT-32103: Behaviors should remove listeners when Skin is disposed. Message-ID: <20130802211809.09D354859C@hg.openjdk.java.net> Changeset: 44af70149f3b Author: rbair Date: 2013-08-02 14:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/44af70149f3b RT-32103: Behaviors should remove listeners when Skin is disposed. I believe this is mostly complete other than for TableViewBehavior and TreeTableViewBehavior. Tests forthcoming. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboBehavior.java - modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusListBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusPopupBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java + modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/AccordionBehaviorTest.java + modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java From hang.vo at oracle.com Fri Aug 2 14:47:21 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 02 Aug 2013 21:47:21 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31428 TableCellFactory sample doesn't cancel editing completely-update desc and regen sample info to get new desc Message-ID: <20130802214754.19FCC485A0@hg.openjdk.java.net> Changeset: 673c493e2fd3 Author: dmasada Date: 2013-08-02 14:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/673c493e2fd3 RT-31428 TableCellFactory sample doesn't cancel editing completely-update desc and regen sample info to get new desc ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/TableCellFactoryApp.java From hang.vo at oracle.com Fri Aug 2 17:18:14 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 03 Aug 2013 00:18:14 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130803001913.C704E485A5@hg.openjdk.java.net> Changeset: dfbaa5afdd53 Author: flar Date: 2013-08-02 16:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dfbaa5afdd53 Fix RT-23581 - add 9-slice render methods to Prism Graphics ! modules/graphics/src/main/java/com/sun/prism/Graphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/TestGraphics.java Changeset: 2c8227ed3cf0 Author: flar Date: 2013-08-02 17:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2c8227ed3cf0 Fix RT-27752 - PixelWriter on WritableImage cannot write BYTE_INDEXED image data ! modules/graphics/src/main/java/com/sun/javafx/image/PixelUtils.java + modules/graphics/src/main/java/com/sun/javafx/image/impl/ByteIndexed.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java ! modules/graphics/src/main/java/javafx/scene/image/Image.java ! modules/graphics/src/main/java/javafx/scene/image/PixelFormat.java From hang.vo at oracle.com Fri Aug 2 20:17:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 03 Aug 2013 03:17:31 +0000 Subject: hg: openjfx/8/controls/rt: RT-32110: Cleanup BehaviorBase by passing key bindings in the constructor Message-ID: <20130803031759.CD612485AA@hg.openjdk.java.net> Changeset: e8ccb3fa27cc Author: rbair Date: 2013-08-02 20:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e8ccb3fa27cc RT-32110: Cleanup BehaviorBase by passing key bindings in the constructor ! apps/experiments/ConferenceScheduleApp/src/main/java/com/javafx/experiments/scheduleapp/control/VirtualKeyboardSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ColorPickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DatePickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/MenuButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/MenuButtonBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ProgressBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ProgressIndicatorBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SplitMenuButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.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/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TitledPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ToolBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabelSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SeparatorSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/BehaviorSkinBaseTest.java ! modules/web/src/main/java/com/sun/javafx/scene/web/behavior/HTMLEditorBehavior.java ! modules/web/src/main/java/com/sun/javafx/webkit/theme/RenderThemeImpl.java From hang.vo at oracle.com Fri Aug 2 21:18:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 03 Aug 2013 04:18:15 +0000 Subject: hg: openjfx/8/controls/rt: Remove unused method from BehaviorBase Message-ID: <20130803041830.915F3485AC@hg.openjdk.java.net> Changeset: 5c98da320f07 Author: rbair Date: 2013-08-02 21:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5c98da320f07 Remove unused method from BehaviorBase ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java From toni.epple at eppleton.de Sun Aug 4 00:47:41 2013 From: toni.epple at eppleton.de (Anton Epple) Date: Sun, 4 Aug 2013 09:47:41 +0200 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> Message-ID: <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> A combination of a page describing an individual application, like the one you linked here, would be one part and -more important- a page that lists *all* the applications with a screenshot and a short description. The latter would be important, because it's a showcase for decision makers who are yet undecided if JavaFX is the right technology. Before that page existed for NB Platform, I had the same discussions I now have for potential JavaFX projects. Developers are in doubt if the technology is mature/performant/secure/whatever enough for their large/unique/graphically demanding/etc. project. After they see the page, they're convinced that it can be done. It's especially useful if you need to convince a team. Typically there's at least one person in favor of a different technology (for JavaFX it's typically GWT) and such a page is a great FUD-killer. Am 01.08.2013 um 22:40 schrieb Richard Bair : > Something I guess would go on such a page? > > http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ > > On Aug 1, 2013, at 3:21 AM, Anton Epple wrote: > >> Great idea, there's a site that does the same for NetBeans Platform Apps: >> >> https://platform.netbeans.org/screenshots.html >> >> I can tell from my own experience that it helps a lot in discussions with customers to show them that NASA, NATO, Boeing, UNO, US Army, and many others are building on top of NB Platform. >> >> From the maintainer of this site, I know there's a lot of work involved though, and you have to be very active in identifying users, and reaching out to them. It's definitely not sufficient to wait for users to submit their applications. Sometimes it can take a couple of years from first contact to a screenshot. That said it's absolutely worth it, and I would volunteer to help in any way I can. >> >> Toni >> >> -- >> Anton Epple >> >> >> >> Am 28.07.2013 um 02:38 schrieb Jonathan Giles : >> >>> This is something that Jasper actually brought up just this morning with Richard and I (wrt fxexperience hosting it). I suspect we may get something underway in the coming weeks. Of course, it depends on the community getting in touch with us and letting us talk about them - so much of the JavaFX world is behind corporate firewalls, where talking about your work is generally frowned upon. In any case, for those of you that can talk about your work, please email one of us off-list. >>> -- Jonathan >>> Sent from a touch device. Please excuse my brevity. >>> >>> "John C. Turnbull" wrote: >>>> +1 >>>> >>>> Such a site could be very useful. >>>> >>>> -----Original Message----- >>>> From: openjfx-dev-bounces at openjdk.java.net >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel >>>> Zwolenski >>>> Sent: Sunday, 28 July 2013 09:56 >>>> To: Pedro Duque Vieira >>>> Cc: OpenJFX Mailing List >>>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) >>>> >>>> The idea of a JFX Sightings page (in the tradition of the Swing >>>> Sightings >>>> page) has been raised before and I think is a good one. >>>> >>>> It deserves it's own page though, that technet section isn't up to it >>>> in my >>>> opinion. >>>> >>>> Personally I think this would be great under the fxexperience site as >>>> it >>>> partners nicely with the links of the week? >>>> >>>> >>>> >>>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira >>>> >>>> wrote: >>>> >>>>> I have an Swing/JavaFX app, the site is: http://modellus.co >>>>> >>>>> How can I get it to be on that real world usecases section? Or does >>>> it >>>>> not have the necessary requirements to be in it? >>>>> >>>>> Thanks, best regards, >>>>> >>>>> @John: On the JavaFx community site they have a section with >>>>> references to >>>>>> real world usecases. >>>>>> http://www.oracle.com/technetwork/java/javafx/community/index.html >>>>>> >>>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull >>>>>> >>>>>> wrote: >>>>>>> Like Daniel said, none of what we say is in any way a criticism of >>>>>>> the JavaFX development team who, in my view and that of the entire >>>>>>> community, are doing an awesome job. >>>>>>> >>>>>>> >>>>>>> >>>>>>> For mine, all the shortcomings of JavaFX (perceived or actual) can >>>>>>> be >>>>>> blown >>>>>>> away if I could just demonstrate what JavaFX is really capable of. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras (whose >>>>>>> demo incidentally doesn't run since Java 7 Update 21). With Oracle >>>> >>>>>>> Ensemble >>>>>> we >>>>>>> can see that JavaFX has quite a nice set of basic controls and that >>>> >>>>>>> it at least supports very simple animations. With JFXtras Ensemble >>>> >>>>>>> we can see that very nice controls are possible but unfortunately >>>>>>> many of these are >>>>>> of >>>>>>> a rather "whimsical" nature and not the kind of control you would >>>>>>> use in everyday business apps. >>>>>>> >>>>>>> >>>>>>> >>>>>>> What else is there? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Of course we have rock stars like Gerrit Grunwald who frequently >>>>>>> post awesome controls and code snippets but we really need >>>> something >>>>>>> that >>>>>> brings >>>>>>> it altogether in a kick-arse showcase. Preferably a whole suite of >>>>>> killer >>>>>>> apps that highlights everything JavaFX is capable of. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, that would require a lot of effort but IMHO it is absolutely >>>>>>> worth >>>>>> it. >>>>>>> Without it, people like me really struggle to sell JavaFX or even >>>>>>> get a handle on its true potential. I can promise people that more >>>> >>>>>>> advanced things are "possible" but given that they write the >>>>>>> cheques, they need to see it for themselves. >>>>>>> >>>>>>> >>>>>>> >>>>>>> And how about a website of JavaFX reference sites? There must be >>>>>>> big companies out there using it right? >>>>>>> >>>>>>> >>>>>>> >>>>>>> In the end it doesn't matter if I personally see enormous potential >>>> >>>>>>> for JavaFX if I cannot convince others to see what I see. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -jct >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] >>>>>>> Sent: Saturday, 27 July 2013 09:12 >>>>>>> To: John C. Turnbull >>>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net >>>>>>> Subject: Re: Can JavaFX do CAD? >>>>>>> >>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> I've failed to convince multiple clients that they should use JFX >>>>>>> because of >>>>>>> >>>>>>> >>>>>>> a) lack of examples of what it can really do, and how to make it do >>>> >>>>>>> that (e.g. in enterprise space we have >>>>>>> http://static.springsource.org/docs/petclinic.html) >>>>>>> >>>>>>> b) lack of any big or notable players out there actually using it, >>>>>>> or at least publicly saying they are using it >>>>>>> >>>>>>> c) the deployment hassles vs the ease of html app deployment and >>>> the >>>>>>> true cross-platform-ness of html >>>>>>> >>>>>>> >>>>>>> >>>>>>> After actually getting one client to trust me on it and use it on a >>>> >>>>>>> real, commercial app (startup), I hit problems with performance >>>>>>> (broad interpretation of the term, not 'framerate'), crippling >>>>>>> deployment and >>>>>> auto >>>>>>> updating issues, missing basic features (e.g. maximise button, >>>>>>> coming in >>>>>>> 2014 I believe?), unpredictability of CSS styling, and a lack of >>>>>>> best practices for things like how to do CAD-like diagrams (not so >>>>>>> much render performance but zooming, panning, mouse input, >>>> layering, >>>> dragging, etc). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Like John, I've been guilty of letting my frustration show in these >>>>>> forums. >>>>>>> Like John, it's because I want so badly for JavaFX to be the >>>>>>> platform I develop on, it has the potential to be awesome, but >>>>>>> things (that seem obvious and small to me) completely stop it from >>>>>>> being usable in a real world situation for me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> It's not that we think the JFX team aren't slogging their guts out, >>>>>> clearly >>>>>>> you are. It's just that in some key areas, there are small-ish >>>>>>> blocks >>>>>> that >>>>>>> stop the whole rocket from launching. To then see a whole lot of >>>>>>> effort >>>>>> be >>>>>>> poured into things like binary CSS/FXML compilation, Pi platform >>>>>>> support (that's more important than iOS/Android, really?), web >>>>>>> deployment >>>>>> patches, >>>>>>> or even 3D (as cool as that is), just knocks me about. Obviously >>>>>>> your priorities are coming from somewhere different to ours, but >>>> the >>>>>>> way you prioritise is unfathomable to me and that definitely adds >>>> to >>>>>>> the frustration. >>>>>>> >>>>>>> >>>>>>> >>>>>>> At this stage, I am not suggesting my clients use JFX (I actively >>>>>>> discourage them from it, in their interest). Mobile is the area >>>> that >>>>>>> has the >>>>>> potential >>>>>>> to bring JFX back into usable for me as it can compete easier with >>>>>>> the current technologies (which are all crap). Maybe if that ends >>>> up >>>>>>> working >>>>>> (a >>>>>>> long, long road to go on that and very much an 'if') then it will >>>>>>> seep >>>>>> back >>>>>>> into the desktop for me, but at a minimum the desktop deployment >>>>>>> options will need to be improved before that's even a possibility. >>>>>>> >>>>>>> >>>>>>> I've come to accept that I am not in the primary target audience >>>> for >>>>>>> JavaFX, maybe a secondary target. I don't understand who the >>>> primary >>>>>>> target is though, and knowing/accepting doesn't make it any less >>>>>>> frustrating. I >>>>>> keep >>>>>>> involved in the hope that I might get a usable platform somewhere >>>>>>> along >>>>>> the >>>>>>> way but it's more of a hope than a belief. >>>>>>> >>>>>>> >>>>>>> >>>>>>> So nothing really new above, but just adding my voice to John's. >>>>>>> JavaFX >>>>>> is >>>>>>> definitely not production ready for me, my clients and the types of >>>> >>>>>>> apps >>>>>> I >>>>>>> build (e.g. consumer facing online systems, enterprise/backoffice >>>>>> systems, >>>>>>> form/data systems, diagramming systems). One day I hope it will be, >>>> >>>>>>> but it's moving extremely slowly or not at all in the areas that >>>>>>> would make it so for me. Meanwhile the competitors (primarily >>>>>>> JavaScript based solutions) are improving rapidly in the areas >>>> where >>>>>>> they have traditionally been weak. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < >>>>>> ozemale at ozemail.com.au >>>>>>> > wrote: >>>>>>> >>>>>>> Hi Richard, >>>>>>> >>>>>>> I have to stop posting late at night, that one came across as >>>> really >>>>>> ANGRY! >>>>>>> >>>>>>> It's not anger, it's passion... and frustration. >>>>>>> >>>>>>> I am frustrated because I spend much of my day trying to convince >>>> my >>>>>>> employer that we should be using JavaFX. They ask me questions >>>> like: >>>>>>> >>>>>>> "What happens if Oracle abandons JavaFX just like Sun did with JMF, >>>>>> Java3D, >>>>>>> JOGL etc. ?" >>>>>>> >>>>>>> I say: >>>>>>> >>>>>>> "This is Oracle, not Sun." >>>>>>> >>>>>>> They say: >>>>>>> >>>>>>> "Can you show me what JavaFX can do? There must be examples out >>>>>>> there right?" >>>>>>> >>>>>>> And I say: >>>>>>> >>>>>>> "Sure, here's Ensemble." >>>>>>> >>>>>>> They say: >>>>>>> >>>>>>> "OK, so it has a nice set of basic controls and can do simple >>>>>>> animations but what about more complex things like Flash?" >>>>>>> >>>>>>> ...hence the dancing cat reference. >>>>>>> >>>>>>> It's not that my employer *needs* dancing cats, it's just that they >>>> >>>>>>> need >>>>>> to >>>>>>> see that there is more to JavaFX than red circle transitions. I >>>>>>> can't >>>>>> even >>>>>>> prove to them that JavaFX is capable of dancing cats. They don't >>>>>>> have >>>>>> the >>>>>>> resources to fund me to develop something more sophisticated but >>>>>>> they >>>>>> tell >>>>>>> me that if JavaFX truly was a "mature" technology (like I tell >>>> them) >>>>>>> then where are all the examples? >>>>>>> >>>>>>> I am finding it difficult to convince them that JavaFX is >>>> production >>>>>> ready >>>>>>> and is not still in "experimental" mode because I am unable to >>>>>> demonstrate >>>>>>> its true capabilities or refer them to many examples of people (and >>>> >>>>>>> I >>>>>> mean >>>>>>> big companies) actually using it. >>>>>>> >>>>>>> The main concerns of my employer and I think many companies in a >>>>>>> similar situation is that JavaFX won't survive long term and that >>>> it >>>>>>> is only >>>>>> really >>>>>>> suitable for form based applications. Then of course there is the >>>>>>> whole >>>>>>> "HTML5 runs on all platforms" argument but that's another story... >>>>>>> >>>>>>> So this is why I think it's imperative that Oracle invests in >>>>>>> developing >>>>>> a >>>>>>> true showcase application for JavaFX. Something that non-technical >>>>>> people >>>>>>> (like managers who make decisions about where the money goes) can >>>>>>> look at it and go "wow!". >>>>>>> >>>>>>> I am just not getting my managers to go "wow" at what I can show >>>>>>> them >>>>>> with >>>>>>> JavaFX at the moment. >>>>>>> >>>>>>> Every comment or apparent criticism I post about JavaFX is from the >>>> >>>>>>> perspective that I am trying to deal with real-world problems and >>>>>>> people who require proof (such as demos, reference sites etc.) and >>>>>>> not because I myself think JavaFX is not up to scratch. >>>>>>> >>>>>>> It's quite the opposite actually. >>>>>>> >>>>>>> I am a very, very strong believer and supporter of JavaFX and have >>>>>>> many reasons both personal and professional as to why I want it to >>>>>>> be a >>>>>> massive >>>>>>> success. As I have said before, there are plenty of people who >>>>>>> praise JavaFX and tend to avoid the very real issues that are >>>>>>> restricting its adoption. I just think we have to face these >>>> issues >>>>>>> head on if we are to compete in what is a very cut-throat industry. >>>>>>> >>>>>>> -jct >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Richard Bair [mailto:richard.bair at oracle.com >>>>>>> ] >>>>>>> Sent: Saturday, 27 July 2013 01:40 >>>>>>> To: John C. Turnbull >>>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net >>>>>>> >>>>>>> Subject: Re: Can JavaFX do CAD? >>>>>>> >>>>>>>> For Flash, there are literally millions of examples of >>>>>>>> fancy/complex/impressive graphics and animations out there that >>>> can >>>>>>>> be really impressive at times. I have not seen ONE such example >>>> in >>>>>> JavaFX! >>>>>>> >>>>>>> Point to one? >>>>>>> >>>>>>> Have you seen any of the JavaOne examples? The movie wall or movies >>>> >>>>>>> on a stack of 3D cubes was pretty good. But I guess you're not >>>>>>> interested in >>>>>> the >>>>>>> 3D aspect? What is it you are looking for exactly? Different people >>>> >>>>>>> (on this >>>>>>> list) have had different perceptions on both (a) what's important >>>>>>> and (b) what kind of graphics they're interested in. Most people >>>>>>> would deride the dancing cat as being totally irrelevant to the >>>>>>> types of applications they're trying to build (the basis for much >>>> of >>>>>>> flash animations is shape >>>>>> morphing, >>>>>>> you can find some code here >>>> https://gist.github.com/gontard/5029764). >>>>>>> >>>>>>> On the other hand, JavaFX is not a replacement for OpenGL. Drawing >>>>>>> 25 million lines is just not something we can do right now, >>>>>>> especially in a resource constrained environment. I've already >>>>>>> commented on the memory overhead (which would continue to be an >>>>>>> issue even if the drawing part of the problem were solved). >>>>>>> >>>>>>> I've pushed to graphics repo the StretchyGrid, which is about 300k >>>>>>> line nodes (the actual amount is variable, see the javadoc >>>>>>> comments). At 300k nodes the scene graph overhead is negligible on >>>>>>> the FX side, dirty opts >>>>>> is >>>>>>> taking a long time to run, and painting is really slow. >>>>>>> >>>>>>> PULSE: 347 [122ms:222ms] >>>>>>> T12 (8 +0ms): CSS Pass >>>>>>> T12 (8 +0ms): Layout Pass >>>>>>> T12 (47 +53ms): Waiting for previous rendering >>>>>>> T12 (100 +1ms): Copy state to render graph >>>>>>> T10 (101 +16ms): Dirty Opts Computed >>>>>>> T10 (117 +105ms): Painted >>>>>>> Counters: >>>>>>> Nodes rendered: 306565 >>>>>>> Nodes visited during render: 306565 >>>>>>> >>>>>>> If I were doing this by hand in open GL, I think the drawing would >>>>>>> be essentially free, if I used LINES with GL anti-aliasing, I could >>>> >>>>>>> send 'em all down to the card in a single shot (and if I had a >>>>>>> modern GL I could >>>>>> do >>>>>>> LINES + FXAA or one of the other per-pixel AA algorithms available >>>>>>> and it would turn out pretty nice). Because our shapes don't >>>>>>> implement the >>>>>> non-AA >>>>>>> path, and our AA involves software rasterization and uploading of >>>>>> pixels, I >>>>>>> expect that to be the main source of the 105ms time being spent >>>> here. >>>>>>> >>>>>>> Also I noticed (by turning on prism.showdirty=true) that the entire >>>> >>>>>>> grid >>>>>> is >>>>>>> being painted every time, even though visually it looks like only a >>>> >>>>>>> small subset actually needs to be changed. But that's really a >>>> minor >>>>>>> thing, as >>>>>> I >>>>>>> said, drawing this many lines should basically be free if I >>>>>>> configure "smooth" to false in the app. Except that right now it is >>>> >>>>>>> totally not implemented (in NGShape): >>>>>>> >>>>>>> public void setAntialiased(boolean aa) { >>>>>>> // We don't support aliased shapes at this time >>>>>>> } >>>>>>> >>>>>>> The point of stretchy grid is not to say "wow look at this amazing >>>> demo". >>>>>>> The point is to say "what happens if I put in 300K nodes. Where >>>> does >>>>>>> the system start to fall over?". >>>>>>> >>>>>>> Richard= >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Pedro Duque Vieira >> > From Fabrizio.Giudici at tidalwave.it Sun Aug 4 01:08:08 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Sun, 04 Aug 2013 10:08:08 +0200 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> Message-ID: On Sun, 04 Aug 2013 09:47:41 +0200, Anton Epple wrote: > A combination of a page describing an individual application, like the > one you linked here, would be one part and -more important- a page that > lists *all* the applications with a screenshot and a short description. > The latter would be important, because it's a showcase for decision > makers who are yet undecided if JavaFX is the right technology. > > Before that page existed for NB Platform, I had the same discussions I > now have for potential JavaFX projects. Developers are in doubt if the > technology is mature/performant/secure/whatever enough for their > large/unique/graphically demanding/etc. project. After they see the > page, they're convinced that it can be done. > > It's especially useful if you need to convince a team. Typically there's > at least one person in favor of a different technology (for JavaFX it's > typically GWT) and such a page is a great FUD-killer. +1 -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From johan at lodgon.com Sun Aug 4 01:12:34 2013 From: johan at lodgon.com (Johan Vos) Date: Sun, 4 Aug 2013 10:12:34 +0200 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> Message-ID: Hi, I agree such an overview page would definitely help, but the go/no-go decisions I often see have less to do with convincing customers about JavaFX being the right technology. Customers have a number of requirements, and if I can tell them JavaFX is capable of doing that, they trust me (and they will blame me when I'm wrong). The key bummer I've seen so far is (yet again) wide deployment. "It should run on tablets" and "Our Customers should be able to use [install] this very easily". I am very much aware of the progress being made in both areas, so I'm not complaining at all -- but there is a lot of work to be done. Just want to set expectations right: a cool overview of what is already achieved with JavaFX is not going to convince all potential customers -- in my experience the deployment is still the major reasons why a number of companies are not in favor of JavaFX yet. - Johan 2013/8/4 Anton Epple > A combination of a page describing an individual application, like the one > you linked here, would be one part and -more important- a page that lists > *all* the applications with a screenshot and a short description. The > latter would be important, because it's a showcase for decision makers who > are yet undecided if JavaFX is the right technology. > > Before that page existed for NB Platform, I had the same discussions I now > have for potential JavaFX projects. Developers are in doubt if the > technology is mature/performant/secure/whatever enough for their > large/unique/graphically demanding/etc. project. After they see the page, > they're convinced that it can be done. > > It's especially useful if you need to convince a team. Typically there's > at least one person in favor of a different technology (for JavaFX it's > typically GWT) and such a page is a great FUD-killer. > > Am 01.08.2013 um 22:40 schrieb Richard Bair : > > > Something I guess would go on such a page? > > > > http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ > > > > On Aug 1, 2013, at 3:21 AM, Anton Epple wrote: > > > >> Great idea, there's a site that does the same for NetBeans Platform > Apps: > >> > >> https://platform.netbeans.org/screenshots.html > >> > >> I can tell from my own experience that it helps a lot in discussions > with customers to show them that NASA, NATO, Boeing, UNO, US Army, and many > others are building on top of NB Platform. > >> > >> From the maintainer of this site, I know there's a lot of work involved > though, and you have to be very active in identifying users, and reaching > out to them. It's definitely not sufficient to wait for users to submit > their applications. Sometimes it can take a couple of years from first > contact to a screenshot. That said it's absolutely worth it, and I would > volunteer to help in any way I can. > >> > >> Toni > >> > >> -- > >> Anton Epple > >> > >> > >> > >> Am 28.07.2013 um 02:38 schrieb Jonathan Giles < > jonathan.giles at oracle.com>: > >> > >>> This is something that Jasper actually brought up just this morning > with Richard and I (wrt fxexperience hosting it). I suspect we may get > something underway in the coming weeks. Of course, it depends on the > community getting in touch with us and letting us talk about them - so much > of the JavaFX world is behind corporate firewalls, where talking about your > work is generally frowned upon. In any case, for those of you that can talk > about your work, please email one of us off-list. > >>> -- Jonathan > >>> Sent from a touch device. Please excuse my brevity. > >>> > >>> "John C. Turnbull" wrote: > >>>> +1 > >>>> > >>>> Such a site could be very useful. > >>>> > >>>> -----Original Message----- > >>>> From: openjfx-dev-bounces at openjdk.java.net > >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel > >>>> Zwolenski > >>>> Sent: Sunday, 28 July 2013 09:56 > >>>> To: Pedro Duque Vieira > >>>> Cc: OpenJFX Mailing List > >>>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) > >>>> > >>>> The idea of a JFX Sightings page (in the tradition of the Swing > >>>> Sightings > >>>> page) has been raised before and I think is a good one. > >>>> > >>>> It deserves it's own page though, that technet section isn't up to it > >>>> in my > >>>> opinion. > >>>> > >>>> Personally I think this would be great under the fxexperience site as > >>>> it > >>>> partners nicely with the links of the week? > >>>> > >>>> > >>>> > >>>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira > >>>> > >>>> wrote: > >>>> > >>>>> I have an Swing/JavaFX app, the site is: http://modellus.co > >>>>> > >>>>> How can I get it to be on that real world usecases section? Or does > >>>> it > >>>>> not have the necessary requirements to be in it? > >>>>> > >>>>> Thanks, best regards, > >>>>> > >>>>> @John: On the JavaFx community site they have a section with > >>>>> references to > >>>>>> real world usecases. > >>>>>> http://www.oracle.com/technetwork/java/javafx/community/index.html > >>>>>> > >>>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull > >>>>>> >>>>>>> wrote: > >>>>>>> Like Daniel said, none of what we say is in any way a criticism of > >>>>>>> the JavaFX development team who, in my view and that of the entire > >>>>>>> community, are doing an awesome job. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> For mine, all the shortcomings of JavaFX (perceived or actual) can > >>>>>>> be > >>>>>> blown > >>>>>>> away if I could just demonstrate what JavaFX is really capable of. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras (whose > >>>>>>> demo incidentally doesn't run since Java 7 Update 21). With Oracle > >>>> > >>>>>>> Ensemble > >>>>>> we > >>>>>>> can see that JavaFX has quite a nice set of basic controls and that > >>>> > >>>>>>> it at least supports very simple animations. With JFXtras Ensemble > >>>> > >>>>>>> we can see that very nice controls are possible but unfortunately > >>>>>>> many of these are > >>>>>> of > >>>>>>> a rather "whimsical" nature and not the kind of control you would > >>>>>>> use in everyday business apps. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> What else is there? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Of course we have rock stars like Gerrit Grunwald who frequently > >>>>>>> post awesome controls and code snippets but we really need > >>>> something > >>>>>>> that > >>>>>> brings > >>>>>>> it altogether in a kick-arse showcase. Preferably a whole suite of > >>>>>> killer > >>>>>>> apps that highlights everything JavaFX is capable of. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Yes, that would require a lot of effort but IMHO it is absolutely > >>>>>>> worth > >>>>>> it. > >>>>>>> Without it, people like me really struggle to sell JavaFX or even > >>>>>>> get a handle on its true potential. I can promise people that more > >>>> > >>>>>>> advanced things are "possible" but given that they write the > >>>>>>> cheques, they need to see it for themselves. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> And how about a website of JavaFX reference sites? There must be > >>>>>>> big companies out there using it right? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> In the end it doesn't matter if I personally see enormous potential > >>>> > >>>>>>> for JavaFX if I cannot convince others to see what I see. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -jct > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] > >>>>>>> Sent: Saturday, 27 July 2013 09:12 > >>>>>>> To: John C. Turnbull > >>>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net > >>>>>>> Subject: Re: Can JavaFX do CAD? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I've failed to convince multiple clients that they should use JFX > >>>>>>> because of > >>>>>>> > >>>>>>> > >>>>>>> a) lack of examples of what it can really do, and how to make it do > >>>> > >>>>>>> that (e.g. in enterprise space we have > >>>>>>> http://static.springsource.org/docs/petclinic.html) > >>>>>>> > >>>>>>> b) lack of any big or notable players out there actually using it, > >>>>>>> or at least publicly saying they are using it > >>>>>>> > >>>>>>> c) the deployment hassles vs the ease of html app deployment and > >>>> the > >>>>>>> true cross-platform-ness of html > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> After actually getting one client to trust me on it and use it on a > >>>> > >>>>>>> real, commercial app (startup), I hit problems with performance > >>>>>>> (broad interpretation of the term, not 'framerate'), crippling > >>>>>>> deployment and > >>>>>> auto > >>>>>>> updating issues, missing basic features (e.g. maximise button, > >>>>>>> coming in > >>>>>>> 2014 I believe?), unpredictability of CSS styling, and a lack of > >>>>>>> best practices for things like how to do CAD-like diagrams (not so > >>>>>>> much render performance but zooming, panning, mouse input, > >>>> layering, > >>>> dragging, etc). > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Like John, I've been guilty of letting my frustration show in these > >>>>>> forums. > >>>>>>> Like John, it's because I want so badly for JavaFX to be the > >>>>>>> platform I develop on, it has the potential to be awesome, but > >>>>>>> things (that seem obvious and small to me) completely stop it from > >>>>>>> being usable in a real world situation for me. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> It's not that we think the JFX team aren't slogging their guts out, > >>>>>> clearly > >>>>>>> you are. It's just that in some key areas, there are small-ish > >>>>>>> blocks > >>>>>> that > >>>>>>> stop the whole rocket from launching. To then see a whole lot of > >>>>>>> effort > >>>>>> be > >>>>>>> poured into things like binary CSS/FXML compilation, Pi platform > >>>>>>> support (that's more important than iOS/Android, really?), web > >>>>>>> deployment > >>>>>> patches, > >>>>>>> or even 3D (as cool as that is), just knocks me about. Obviously > >>>>>>> your priorities are coming from somewhere different to ours, but > >>>> the > >>>>>>> way you prioritise is unfathomable to me and that definitely adds > >>>> to > >>>>>>> the frustration. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> At this stage, I am not suggesting my clients use JFX (I actively > >>>>>>> discourage them from it, in their interest). Mobile is the area > >>>> that > >>>>>>> has the > >>>>>> potential > >>>>>>> to bring JFX back into usable for me as it can compete easier with > >>>>>>> the current technologies (which are all crap). Maybe if that ends > >>>> up > >>>>>>> working > >>>>>> (a > >>>>>>> long, long road to go on that and very much an 'if') then it will > >>>>>>> seep > >>>>>> back > >>>>>>> into the desktop for me, but at a minimum the desktop deployment > >>>>>>> options will need to be improved before that's even a possibility. > >>>>>>> > >>>>>>> > >>>>>>> I've come to accept that I am not in the primary target audience > >>>> for > >>>>>>> JavaFX, maybe a secondary target. I don't understand who the > >>>> primary > >>>>>>> target is though, and knowing/accepting doesn't make it any less > >>>>>>> frustrating. I > >>>>>> keep > >>>>>>> involved in the hope that I might get a usable platform somewhere > >>>>>>> along > >>>>>> the > >>>>>>> way but it's more of a hope than a belief. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> So nothing really new above, but just adding my voice to John's. > >>>>>>> JavaFX > >>>>>> is > >>>>>>> definitely not production ready for me, my clients and the types of > >>>> > >>>>>>> apps > >>>>>> I > >>>>>>> build (e.g. consumer facing online systems, enterprise/backoffice > >>>>>> systems, > >>>>>>> form/data systems, diagramming systems). One day I hope it will be, > >>>> > >>>>>>> but it's moving extremely slowly or not at all in the areas that > >>>>>>> would make it so for me. Meanwhile the competitors (primarily > >>>>>>> JavaScript based solutions) are improving rapidly in the areas > >>>> where > >>>>>>> they have traditionally been weak. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < > >>>>>> ozemale at ozemail.com.au > >>>>>>> > wrote: > >>>>>>> > >>>>>>> Hi Richard, > >>>>>>> > >>>>>>> I have to stop posting late at night, that one came across as > >>>> really > >>>>>> ANGRY! > >>>>>>> > >>>>>>> It's not anger, it's passion... and frustration. > >>>>>>> > >>>>>>> I am frustrated because I spend much of my day trying to convince > >>>> my > >>>>>>> employer that we should be using JavaFX. They ask me questions > >>>> like: > >>>>>>> > >>>>>>> "What happens if Oracle abandons JavaFX just like Sun did with JMF, > >>>>>> Java3D, > >>>>>>> JOGL etc. ?" > >>>>>>> > >>>>>>> I say: > >>>>>>> > >>>>>>> "This is Oracle, not Sun." > >>>>>>> > >>>>>>> They say: > >>>>>>> > >>>>>>> "Can you show me what JavaFX can do? There must be examples out > >>>>>>> there right?" > >>>>>>> > >>>>>>> And I say: > >>>>>>> > >>>>>>> "Sure, here's Ensemble." > >>>>>>> > >>>>>>> They say: > >>>>>>> > >>>>>>> "OK, so it has a nice set of basic controls and can do simple > >>>>>>> animations but what about more complex things like Flash?" > >>>>>>> > >>>>>>> ...hence the dancing cat reference. > >>>>>>> > >>>>>>> It's not that my employer *needs* dancing cats, it's just that they > >>>> > >>>>>>> need > >>>>>> to > >>>>>>> see that there is more to JavaFX than red circle transitions. I > >>>>>>> can't > >>>>>> even > >>>>>>> prove to them that JavaFX is capable of dancing cats. They don't > >>>>>>> have > >>>>>> the > >>>>>>> resources to fund me to develop something more sophisticated but > >>>>>>> they > >>>>>> tell > >>>>>>> me that if JavaFX truly was a "mature" technology (like I tell > >>>> them) > >>>>>>> then where are all the examples? > >>>>>>> > >>>>>>> I am finding it difficult to convince them that JavaFX is > >>>> production > >>>>>> ready > >>>>>>> and is not still in "experimental" mode because I am unable to > >>>>>> demonstrate > >>>>>>> its true capabilities or refer them to many examples of people (and > >>>> > >>>>>>> I > >>>>>> mean > >>>>>>> big companies) actually using it. > >>>>>>> > >>>>>>> The main concerns of my employer and I think many companies in a > >>>>>>> similar situation is that JavaFX won't survive long term and that > >>>> it > >>>>>>> is only > >>>>>> really > >>>>>>> suitable for form based applications. Then of course there is the > >>>>>>> whole > >>>>>>> "HTML5 runs on all platforms" argument but that's another story... > >>>>>>> > >>>>>>> So this is why I think it's imperative that Oracle invests in > >>>>>>> developing > >>>>>> a > >>>>>>> true showcase application for JavaFX. Something that non-technical > >>>>>> people > >>>>>>> (like managers who make decisions about where the money goes) can > >>>>>>> look at it and go "wow!". > >>>>>>> > >>>>>>> I am just not getting my managers to go "wow" at what I can show > >>>>>>> them > >>>>>> with > >>>>>>> JavaFX at the moment. > >>>>>>> > >>>>>>> Every comment or apparent criticism I post about JavaFX is from the > >>>> > >>>>>>> perspective that I am trying to deal with real-world problems and > >>>>>>> people who require proof (such as demos, reference sites etc.) and > >>>>>>> not because I myself think JavaFX is not up to scratch. > >>>>>>> > >>>>>>> It's quite the opposite actually. > >>>>>>> > >>>>>>> I am a very, very strong believer and supporter of JavaFX and have > >>>>>>> many reasons both personal and professional as to why I want it to > >>>>>>> be a > >>>>>> massive > >>>>>>> success. As I have said before, there are plenty of people who > >>>>>>> praise JavaFX and tend to avoid the very real issues that are > >>>>>>> restricting its adoption. I just think we have to face these > >>>> issues > >>>>>>> head on if we are to compete in what is a very cut-throat industry. > >>>>>>> > >>>>>>> -jct > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Richard Bair [mailto:richard.bair at oracle.com > >>>>>>> ] > >>>>>>> Sent: Saturday, 27 July 2013 01:40 > >>>>>>> To: John C. Turnbull > >>>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net > >>>>>>> > >>>>>>> Subject: Re: Can JavaFX do CAD? > >>>>>>> > >>>>>>>> For Flash, there are literally millions of examples of > >>>>>>>> fancy/complex/impressive graphics and animations out there that > >>>> can > >>>>>>>> be really impressive at times. I have not seen ONE such example > >>>> in > >>>>>> JavaFX! > >>>>>>> > >>>>>>> Point to one? > >>>>>>> > >>>>>>> Have you seen any of the JavaOne examples? The movie wall or movies > >>>> > >>>>>>> on a stack of 3D cubes was pretty good. But I guess you're not > >>>>>>> interested in > >>>>>> the > >>>>>>> 3D aspect? What is it you are looking for exactly? Different people > >>>> > >>>>>>> (on this > >>>>>>> list) have had different perceptions on both (a) what's important > >>>>>>> and (b) what kind of graphics they're interested in. Most people > >>>>>>> would deride the dancing cat as being totally irrelevant to the > >>>>>>> types of applications they're trying to build (the basis for much > >>>> of > >>>>>>> flash animations is shape > >>>>>> morphing, > >>>>>>> you can find some code here > >>>> https://gist.github.com/gontard/5029764). > >>>>>>> > >>>>>>> On the other hand, JavaFX is not a replacement for OpenGL. Drawing > >>>>>>> 25 million lines is just not something we can do right now, > >>>>>>> especially in a resource constrained environment. I've already > >>>>>>> commented on the memory overhead (which would continue to be an > >>>>>>> issue even if the drawing part of the problem were solved). > >>>>>>> > >>>>>>> I've pushed to graphics repo the StretchyGrid, which is about 300k > >>>>>>> line nodes (the actual amount is variable, see the javadoc > >>>>>>> comments). At 300k nodes the scene graph overhead is negligible on > >>>>>>> the FX side, dirty opts > >>>>>> is > >>>>>>> taking a long time to run, and painting is really slow. > >>>>>>> > >>>>>>> PULSE: 347 [122ms:222ms] > >>>>>>> T12 (8 +0ms): CSS Pass > >>>>>>> T12 (8 +0ms): Layout Pass > >>>>>>> T12 (47 +53ms): Waiting for previous rendering > >>>>>>> T12 (100 +1ms): Copy state to render graph > >>>>>>> T10 (101 +16ms): Dirty Opts Computed > >>>>>>> T10 (117 +105ms): Painted > >>>>>>> Counters: > >>>>>>> Nodes rendered: 306565 > >>>>>>> Nodes visited during render: 306565 > >>>>>>> > >>>>>>> If I were doing this by hand in open GL, I think the drawing would > >>>>>>> be essentially free, if I used LINES with GL anti-aliasing, I could > >>>> > >>>>>>> send 'em all down to the card in a single shot (and if I had a > >>>>>>> modern GL I could > >>>>>> do > >>>>>>> LINES + FXAA or one of the other per-pixel AA algorithms available > >>>>>>> and it would turn out pretty nice). Because our shapes don't > >>>>>>> implement the > >>>>>> non-AA > >>>>>>> path, and our AA involves software rasterization and uploading of > >>>>>> pixels, I > >>>>>>> expect that to be the main source of the 105ms time being spent > >>>> here. > >>>>>>> > >>>>>>> Also I noticed (by turning on prism.showdirty=true) that the entire > >>>> > >>>>>>> grid > >>>>>> is > >>>>>>> being painted every time, even though visually it looks like only a > >>>> > >>>>>>> small subset actually needs to be changed. But that's really a > >>>> minor > >>>>>>> thing, as > >>>>>> I > >>>>>>> said, drawing this many lines should basically be free if I > >>>>>>> configure "smooth" to false in the app. Except that right now it is > >>>> > >>>>>>> totally not implemented (in NGShape): > >>>>>>> > >>>>>>> public void setAntialiased(boolean aa) { > >>>>>>> // We don't support aliased shapes at this time > >>>>>>> } > >>>>>>> > >>>>>>> The point of stretchy grid is not to say "wow look at this amazing > >>>> demo". > >>>>>>> The point is to say "what happens if I put in 300K nodes. Where > >>>> does > >>>>>>> the system start to fall over?". > >>>>>>> > >>>>>>> Richard= > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Pedro Duque Vieira > >> > > > > From hang.vo at oracle.com Sun Aug 4 02:33:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 04 Aug 2013 09:33:52 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-32111 - slice removal optimizations in 9-slicing methods are overly optimistic Message-ID: <20130804093457.2CAFA485BF@hg.openjdk.java.net> Changeset: 7c1ff801571d Author: flar Date: 2013-08-04 02:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7c1ff801571d Fix RT-32111 - slice removal optimizations in 9-slicing methods are overly optimistic ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java From hang.vo at oracle.com Sun Aug 4 06:03:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 04 Aug 2013 13:03:50 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31892 Tap radius and time out should be configurable and set to a lower default Message-ID: <20130804130453.141CF485C0@hg.openjdk.java.net> Changeset: 6de8fb22ec57 Author: Rafi Tayar Date: 2013-08-04 15:48 +0300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6de8fb22ec57 RT-31892 Tap radius and time out should be configurable and set to a lower default ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensTouchInputSupport.java ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c From sven.reimers at gmail.com Sun Aug 4 06:15:42 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 4 Aug 2013 15:15:42 +0200 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> Message-ID: Hi, from my perspective a showcase list saying technology X is used by the top ten largest engineering companies is always very nice to convince people they are not basing a long term project/product on an used, not widespread technology. So for me building a showcase page is a key thing for helping in the decision making process. -Sven On Sun, Aug 4, 2013 at 10:12 AM, Johan Vos wrote: > Hi, > > I agree such an overview page would definitely help, but the go/no-go > decisions I often see have less to do with convincing customers about > JavaFX being the right technology. Customers have a number of requirements, > and if I can tell them JavaFX is capable of doing that, they trust me (and > they will blame me when I'm wrong). > > The key bummer I've seen so far is (yet again) wide deployment. "It should > run on tablets" and "Our Customers should be able to use [install] this > very easily". > I am very much aware of the progress being made in both areas, so I'm not > complaining at all -- but there is a lot of work to be done. > Just want to set expectations right: a cool overview of what is already > achieved with JavaFX is not going to convince all potential customers -- in > my experience the deployment is still the major reasons why a number of > companies are not in favor of JavaFX yet. > > - Johan > > > > 2013/8/4 Anton Epple > > > A combination of a page describing an individual application, like the > one > > you linked here, would be one part and -more important- a page that lists > > *all* the applications with a screenshot and a short description. The > > latter would be important, because it's a showcase for decision makers > who > > are yet undecided if JavaFX is the right technology. > > > > Before that page existed for NB Platform, I had the same discussions I > now > > have for potential JavaFX projects. Developers are in doubt if the > > technology is mature/performant/secure/whatever enough for their > > large/unique/graphically demanding/etc. project. After they see the page, > > they're convinced that it can be done. > > > > It's especially useful if you need to convince a team. Typically there's > > at least one person in favor of a different technology (for JavaFX it's > > typically GWT) and such a page is a great FUD-killer. > > > > Am 01.08.2013 um 22:40 schrieb Richard Bair : > > > > > Something I guess would go on such a page? > > > > > > http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ > > > > > > On Aug 1, 2013, at 3:21 AM, Anton Epple > wrote: > > > > > >> Great idea, there's a site that does the same for NetBeans Platform > > Apps: > > >> > > >> https://platform.netbeans.org/screenshots.html > > >> > > >> I can tell from my own experience that it helps a lot in discussions > > with customers to show them that NASA, NATO, Boeing, UNO, US Army, and > many > > others are building on top of NB Platform. > > >> > > >> From the maintainer of this site, I know there's a lot of work > involved > > though, and you have to be very active in identifying users, and reaching > > out to them. It's definitely not sufficient to wait for users to submit > > their applications. Sometimes it can take a couple of years from first > > contact to a screenshot. That said it's absolutely worth it, and I would > > volunteer to help in any way I can. > > >> > > >> Toni > > >> > > >> -- > > >> Anton Epple > > >> > > >> > > >> > > >> Am 28.07.2013 um 02:38 schrieb Jonathan Giles < > > jonathan.giles at oracle.com>: > > >> > > >>> This is something that Jasper actually brought up just this morning > > with Richard and I (wrt fxexperience hosting it). I suspect we may get > > something underway in the coming weeks. Of course, it depends on the > > community getting in touch with us and letting us talk about them - so > much > > of the JavaFX world is behind corporate firewalls, where talking about > your > > work is generally frowned upon. In any case, for those of you that can > talk > > about your work, please email one of us off-list. > > >>> -- Jonathan > > >>> Sent from a touch device. Please excuse my brevity. > > >>> > > >>> "John C. Turnbull" wrote: > > >>>> +1 > > >>>> > > >>>> Such a site could be very useful. > > >>>> > > >>>> -----Original Message----- > > >>>> From: openjfx-dev-bounces at openjdk.java.net > > >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel > > >>>> Zwolenski > > >>>> Sent: Sunday, 28 July 2013 09:56 > > >>>> To: Pedro Duque Vieira > > >>>> Cc: OpenJFX Mailing List > > >>>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) > > >>>> > > >>>> The idea of a JFX Sightings page (in the tradition of the Swing > > >>>> Sightings > > >>>> page) has been raised before and I think is a good one. > > >>>> > > >>>> It deserves it's own page though, that technet section isn't up to > it > > >>>> in my > > >>>> opinion. > > >>>> > > >>>> Personally I think this would be great under the fxexperience site > as > > >>>> it > > >>>> partners nicely with the links of the week? > > >>>> > > >>>> > > >>>> > > >>>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira > > >>>> > > >>>> wrote: > > >>>> > > >>>>> I have an Swing/JavaFX app, the site is: http://modellus.co > > >>>>> > > >>>>> How can I get it to be on that real world usecases section? Or does > > >>>> it > > >>>>> not have the necessary requirements to be in it? > > >>>>> > > >>>>> Thanks, best regards, > > >>>>> > > >>>>> @John: On the JavaFx community site they have a section with > > >>>>> references to > > >>>>>> real world usecases. > > >>>>>> > http://www.oracle.com/technetwork/java/javafx/community/index.html > > >>>>>> > > >>>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull > > >>>>>> > >>>>>>> wrote: > > >>>>>>> Like Daniel said, none of what we say is in any way a criticism > of > > >>>>>>> the JavaFX development team who, in my view and that of the > entire > > >>>>>>> community, are doing an awesome job. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> For mine, all the shortcomings of JavaFX (perceived or actual) > can > > >>>>>>> be > > >>>>>> blown > > >>>>>>> away if I could just demonstrate what JavaFX is really capable > of. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras > (whose > > >>>>>>> demo incidentally doesn't run since Java 7 Update 21). With > Oracle > > >>>> > > >>>>>>> Ensemble > > >>>>>> we > > >>>>>>> can see that JavaFX has quite a nice set of basic controls and > that > > >>>> > > >>>>>>> it at least supports very simple animations. With JFXtras > Ensemble > > >>>> > > >>>>>>> we can see that very nice controls are possible but unfortunately > > >>>>>>> many of these are > > >>>>>> of > > >>>>>>> a rather "whimsical" nature and not the kind of control you would > > >>>>>>> use in everyday business apps. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> What else is there? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Of course we have rock stars like Gerrit Grunwald who frequently > > >>>>>>> post awesome controls and code snippets but we really need > > >>>> something > > >>>>>>> that > > >>>>>> brings > > >>>>>>> it altogether in a kick-arse showcase. Preferably a whole suite > of > > >>>>>> killer > > >>>>>>> apps that highlights everything JavaFX is capable of. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Yes, that would require a lot of effort but IMHO it is absolutely > > >>>>>>> worth > > >>>>>> it. > > >>>>>>> Without it, people like me really struggle to sell JavaFX or even > > >>>>>>> get a handle on its true potential. I can promise people that > more > > >>>> > > >>>>>>> advanced things are "possible" but given that they write the > > >>>>>>> cheques, they need to see it for themselves. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> And how about a website of JavaFX reference sites? There must be > > >>>>>>> big companies out there using it right? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> In the end it doesn't matter if I personally see enormous > potential > > >>>> > > >>>>>>> for JavaFX if I cannot convince others to see what I see. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -jct > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] > > >>>>>>> Sent: Saturday, 27 July 2013 09:12 > > >>>>>>> To: John C. Turnbull > > >>>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net > > >>>>>>> Subject: Re: Can JavaFX do CAD? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> +1 > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> I've failed to convince multiple clients that they should use JFX > > >>>>>>> because of > > >>>>>>> > > >>>>>>> > > >>>>>>> a) lack of examples of what it can really do, and how to make it > do > > >>>> > > >>>>>>> that (e.g. in enterprise space we have > > >>>>>>> http://static.springsource.org/docs/petclinic.html) > > >>>>>>> > > >>>>>>> b) lack of any big or notable players out there actually using > it, > > >>>>>>> or at least publicly saying they are using it > > >>>>>>> > > >>>>>>> c) the deployment hassles vs the ease of html app deployment and > > >>>> the > > >>>>>>> true cross-platform-ness of html > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> After actually getting one client to trust me on it and use it > on a > > >>>> > > >>>>>>> real, commercial app (startup), I hit problems with performance > > >>>>>>> (broad interpretation of the term, not 'framerate'), crippling > > >>>>>>> deployment and > > >>>>>> auto > > >>>>>>> updating issues, missing basic features (e.g. maximise button, > > >>>>>>> coming in > > >>>>>>> 2014 I believe?), unpredictability of CSS styling, and a lack of > > >>>>>>> best practices for things like how to do CAD-like diagrams (not > so > > >>>>>>> much render performance but zooming, panning, mouse input, > > >>>> layering, > > >>>> dragging, etc). > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Like John, I've been guilty of letting my frustration show in > these > > >>>>>> forums. > > >>>>>>> Like John, it's because I want so badly for JavaFX to be the > > >>>>>>> platform I develop on, it has the potential to be awesome, but > > >>>>>>> things (that seem obvious and small to me) completely stop it > from > > >>>>>>> being usable in a real world situation for me. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> It's not that we think the JFX team aren't slogging their guts > out, > > >>>>>> clearly > > >>>>>>> you are. It's just that in some key areas, there are small-ish > > >>>>>>> blocks > > >>>>>> that > > >>>>>>> stop the whole rocket from launching. To then see a whole lot of > > >>>>>>> effort > > >>>>>> be > > >>>>>>> poured into things like binary CSS/FXML compilation, Pi platform > > >>>>>>> support (that's more important than iOS/Android, really?), web > > >>>>>>> deployment > > >>>>>> patches, > > >>>>>>> or even 3D (as cool as that is), just knocks me about. Obviously > > >>>>>>> your priorities are coming from somewhere different to ours, but > > >>>> the > > >>>>>>> way you prioritise is unfathomable to me and that definitely adds > > >>>> to > > >>>>>>> the frustration. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> At this stage, I am not suggesting my clients use JFX (I actively > > >>>>>>> discourage them from it, in their interest). Mobile is the area > > >>>> that > > >>>>>>> has the > > >>>>>> potential > > >>>>>>> to bring JFX back into usable for me as it can compete easier > with > > >>>>>>> the current technologies (which are all crap). Maybe if that ends > > >>>> up > > >>>>>>> working > > >>>>>> (a > > >>>>>>> long, long road to go on that and very much an 'if') then it will > > >>>>>>> seep > > >>>>>> back > > >>>>>>> into the desktop for me, but at a minimum the desktop deployment > > >>>>>>> options will need to be improved before that's even a > possibility. > > >>>>>>> > > >>>>>>> > > >>>>>>> I've come to accept that I am not in the primary target audience > > >>>> for > > >>>>>>> JavaFX, maybe a secondary target. I don't understand who the > > >>>> primary > > >>>>>>> target is though, and knowing/accepting doesn't make it any less > > >>>>>>> frustrating. I > > >>>>>> keep > > >>>>>>> involved in the hope that I might get a usable platform somewhere > > >>>>>>> along > > >>>>>> the > > >>>>>>> way but it's more of a hope than a belief. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> So nothing really new above, but just adding my voice to John's. > > >>>>>>> JavaFX > > >>>>>> is > > >>>>>>> definitely not production ready for me, my clients and the types > of > > >>>> > > >>>>>>> apps > > >>>>>> I > > >>>>>>> build (e.g. consumer facing online systems, enterprise/backoffice > > >>>>>> systems, > > >>>>>>> form/data systems, diagramming systems). One day I hope it will > be, > > >>>> > > >>>>>>> but it's moving extremely slowly or not at all in the areas that > > >>>>>>> would make it so for me. Meanwhile the competitors (primarily > > >>>>>>> JavaScript based solutions) are improving rapidly in the areas > > >>>> where > > >>>>>>> they have traditionally been weak. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < > > >>>>>> ozemale at ozemail.com.au > > >>>>>>> > wrote: > > >>>>>>> > > >>>>>>> Hi Richard, > > >>>>>>> > > >>>>>>> I have to stop posting late at night, that one came across as > > >>>> really > > >>>>>> ANGRY! > > >>>>>>> > > >>>>>>> It's not anger, it's passion... and frustration. > > >>>>>>> > > >>>>>>> I am frustrated because I spend much of my day trying to convince > > >>>> my > > >>>>>>> employer that we should be using JavaFX. They ask me questions > > >>>> like: > > >>>>>>> > > >>>>>>> "What happens if Oracle abandons JavaFX just like Sun did with > JMF, > > >>>>>> Java3D, > > >>>>>>> JOGL etc. ?" > > >>>>>>> > > >>>>>>> I say: > > >>>>>>> > > >>>>>>> "This is Oracle, not Sun." > > >>>>>>> > > >>>>>>> They say: > > >>>>>>> > > >>>>>>> "Can you show me what JavaFX can do? There must be examples out > > >>>>>>> there right?" > > >>>>>>> > > >>>>>>> And I say: > > >>>>>>> > > >>>>>>> "Sure, here's Ensemble." > > >>>>>>> > > >>>>>>> They say: > > >>>>>>> > > >>>>>>> "OK, so it has a nice set of basic controls and can do simple > > >>>>>>> animations but what about more complex things like Flash?" > > >>>>>>> > > >>>>>>> ...hence the dancing cat reference. > > >>>>>>> > > >>>>>>> It's not that my employer *needs* dancing cats, it's just that > they > > >>>> > > >>>>>>> need > > >>>>>> to > > >>>>>>> see that there is more to JavaFX than red circle transitions. I > > >>>>>>> can't > > >>>>>> even > > >>>>>>> prove to them that JavaFX is capable of dancing cats. They don't > > >>>>>>> have > > >>>>>> the > > >>>>>>> resources to fund me to develop something more sophisticated but > > >>>>>>> they > > >>>>>> tell > > >>>>>>> me that if JavaFX truly was a "mature" technology (like I tell > > >>>> them) > > >>>>>>> then where are all the examples? > > >>>>>>> > > >>>>>>> I am finding it difficult to convince them that JavaFX is > > >>>> production > > >>>>>> ready > > >>>>>>> and is not still in "experimental" mode because I am unable to > > >>>>>> demonstrate > > >>>>>>> its true capabilities or refer them to many examples of people > (and > > >>>> > > >>>>>>> I > > >>>>>> mean > > >>>>>>> big companies) actually using it. > > >>>>>>> > > >>>>>>> The main concerns of my employer and I think many companies in a > > >>>>>>> similar situation is that JavaFX won't survive long term and that > > >>>> it > > >>>>>>> is only > > >>>>>> really > > >>>>>>> suitable for form based applications. Then of course there is > the > > >>>>>>> whole > > >>>>>>> "HTML5 runs on all platforms" argument but that's another > story... > > >>>>>>> > > >>>>>>> So this is why I think it's imperative that Oracle invests in > > >>>>>>> developing > > >>>>>> a > > >>>>>>> true showcase application for JavaFX. Something that > non-technical > > >>>>>> people > > >>>>>>> (like managers who make decisions about where the money goes) can > > >>>>>>> look at it and go "wow!". > > >>>>>>> > > >>>>>>> I am just not getting my managers to go "wow" at what I can show > > >>>>>>> them > > >>>>>> with > > >>>>>>> JavaFX at the moment. > > >>>>>>> > > >>>>>>> Every comment or apparent criticism I post about JavaFX is from > the > > >>>> > > >>>>>>> perspective that I am trying to deal with real-world problems and > > >>>>>>> people who require proof (such as demos, reference sites etc.) > and > > >>>>>>> not because I myself think JavaFX is not up to scratch. > > >>>>>>> > > >>>>>>> It's quite the opposite actually. > > >>>>>>> > > >>>>>>> I am a very, very strong believer and supporter of JavaFX and > have > > >>>>>>> many reasons both personal and professional as to why I want it > to > > >>>>>>> be a > > >>>>>> massive > > >>>>>>> success. As I have said before, there are plenty of people who > > >>>>>>> praise JavaFX and tend to avoid the very real issues that are > > >>>>>>> restricting its adoption. I just think we have to face these > > >>>> issues > > >>>>>>> head on if we are to compete in what is a very cut-throat > industry. > > >>>>>>> > > >>>>>>> -jct > > >>>>>>> > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Richard Bair [mailto:richard.bair at oracle.com > > >>>>>>> ] > > >>>>>>> Sent: Saturday, 27 July 2013 01:40 > > >>>>>>> To: John C. Turnbull > > >>>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net > > >>>>>>> > > >>>>>>> Subject: Re: Can JavaFX do CAD? > > >>>>>>> > > >>>>>>>> For Flash, there are literally millions of examples of > > >>>>>>>> fancy/complex/impressive graphics and animations out there that > > >>>> can > > >>>>>>>> be really impressive at times. I have not seen ONE such example > > >>>> in > > >>>>>> JavaFX! > > >>>>>>> > > >>>>>>> Point to one? > > >>>>>>> > > >>>>>>> Have you seen any of the JavaOne examples? The movie wall or > movies > > >>>> > > >>>>>>> on a stack of 3D cubes was pretty good. But I guess you're not > > >>>>>>> interested in > > >>>>>> the > > >>>>>>> 3D aspect? What is it you are looking for exactly? Different > people > > >>>> > > >>>>>>> (on this > > >>>>>>> list) have had different perceptions on both (a) what's important > > >>>>>>> and (b) what kind of graphics they're interested in. Most people > > >>>>>>> would deride the dancing cat as being totally irrelevant to the > > >>>>>>> types of applications they're trying to build (the basis for much > > >>>> of > > >>>>>>> flash animations is shape > > >>>>>> morphing, > > >>>>>>> you can find some code here > > >>>> https://gist.github.com/gontard/5029764). > > >>>>>>> > > >>>>>>> On the other hand, JavaFX is not a replacement for OpenGL. > Drawing > > >>>>>>> 25 million lines is just not something we can do right now, > > >>>>>>> especially in a resource constrained environment. I've already > > >>>>>>> commented on the memory overhead (which would continue to be an > > >>>>>>> issue even if the drawing part of the problem were solved). > > >>>>>>> > > >>>>>>> I've pushed to graphics repo the StretchyGrid, which is about > 300k > > >>>>>>> line nodes (the actual amount is variable, see the javadoc > > >>>>>>> comments). At 300k nodes the scene graph overhead is negligible > on > > >>>>>>> the FX side, dirty opts > > >>>>>> is > > >>>>>>> taking a long time to run, and painting is really slow. > > >>>>>>> > > >>>>>>> PULSE: 347 [122ms:222ms] > > >>>>>>> T12 (8 +0ms): CSS Pass > > >>>>>>> T12 (8 +0ms): Layout Pass > > >>>>>>> T12 (47 +53ms): Waiting for previous rendering > > >>>>>>> T12 (100 +1ms): Copy state to render graph > > >>>>>>> T10 (101 +16ms): Dirty Opts Computed > > >>>>>>> T10 (117 +105ms): Painted > > >>>>>>> Counters: > > >>>>>>> Nodes rendered: 306565 > > >>>>>>> Nodes visited during render: 306565 > > >>>>>>> > > >>>>>>> If I were doing this by hand in open GL, I think the drawing > would > > >>>>>>> be essentially free, if I used LINES with GL anti-aliasing, I > could > > >>>> > > >>>>>>> send 'em all down to the card in a single shot (and if I had a > > >>>>>>> modern GL I could > > >>>>>> do > > >>>>>>> LINES + FXAA or one of the other per-pixel AA algorithms > available > > >>>>>>> and it would turn out pretty nice). Because our shapes don't > > >>>>>>> implement the > > >>>>>> non-AA > > >>>>>>> path, and our AA involves software rasterization and uploading of > > >>>>>> pixels, I > > >>>>>>> expect that to be the main source of the 105ms time being spent > > >>>> here. > > >>>>>>> > > >>>>>>> Also I noticed (by turning on prism.showdirty=true) that the > entire > > >>>> > > >>>>>>> grid > > >>>>>> is > > >>>>>>> being painted every time, even though visually it looks like > only a > > >>>> > > >>>>>>> small subset actually needs to be changed. But that's really a > > >>>> minor > > >>>>>>> thing, as > > >>>>>> I > > >>>>>>> said, drawing this many lines should basically be free if I > > >>>>>>> configure "smooth" to false in the app. Except that right now it > is > > >>>> > > >>>>>>> totally not implemented (in NGShape): > > >>>>>>> > > >>>>>>> public void setAntialiased(boolean aa) { > > >>>>>>> // We don't support aliased shapes at this time > > >>>>>>> } > > >>>>>>> > > >>>>>>> The point of stretchy grid is not to say "wow look at this > amazing > > >>>> demo". > > >>>>>>> The point is to say "what happens if I put in 300K nodes. Where > > >>>> does > > >>>>>>> the system start to fall over?". > > >>>>>>> > > >>>>>>> Richard= > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> Pedro Duque Vieira > > >> > > > > > > > > -- 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 Aug 4 15:13:46 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sun, 4 Aug 2013 23:13:46 +0100 Subject: Multiple JFXPanel? In-Reply-To: <51FB65F8.6090300@oracle.com> References: <51FB65F8.6090300@oracle.com> Message-ID: Hi Anton, Thanks for your reply. Actually I wasn't clear enough when I explained my app. My app is composed of a MDI style interface but each window belongs to the same JFrame, so there is only one JFrame but multiple internal frames. One of these internal frames has a JFXPanel with a scene in it. I intend to migrate the rest of the internal frames to javafx one by one using this approach. My question was is this a viable way to do this? Or am I going to pay a performance penalty from having multiple JFXPanels (hence multiple scenes) inside the same app (the same JFrame)? >From what people have told me in this mailing list, they are using multiple JFXPanels without any significant performance penalty, anyway it would be interesting hearing the opinion from you, JavaFX dev team guys. Thanks once again for your replies, best regards, On Fri, Aug 2, 2013 at 8:55 AM, Anton V. Tarasov wrote: > Hi Pedro, > > I've made the following experiment. I've created two simple test cases: > one is pure fx stage showing WebView which animated some guimark2 > benchmarks, another one is the same WebView wrapped with JFXPanel put in > JFrame. > > I ran each test case with a single, two or four toplevels (Stages or > JFrames, appropriately) and measured performance difference. I noticed that > for the swing test case, adding more toplevels decreased performance with > the same proportion like the fx test case did (despite the fact that fx > performed relatively faster, of course). For instance, for the Vector > Charting Test the ratio was directly proportional to the number of > toplevels, that is doubling the toplevels decreased performance by two > times equally for both fx and swing cases. > > This more or less proves the fact that adding another embedded scene into > your app doesn't bring anything except another scene. > > Thanks, > Anton. > > > On 01.08.2013 2:45, Pedro Duque Vieira wrote: > >> Hi, >> >> I have a doubt. I have a swing app with embed javafx scene. My app has >> kind >> of a MDI style interface. Right now only one window has been converted to >> JavaFX, basically it's a window with a JFXPanel in it. >> My question is if I want to convert the other windows as well should I >> also >> put a JFXPanel in them? I would than have 2 JFXPanels in my app, does that >> mean I would have 2 JavaFX scenes? Is that the way to do it? Would that >> seriously hurt performance? >> >> Thank you in advance, best regards, >> >> > -- Pedro Duque Vieira From tobi at ultramixer.com Mon Aug 5 01:32:48 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 5 Aug 2013 10:32:48 +0200 Subject: How to get the content scale factor (hiDPI) on Mac on OpenJDK8? Message-ID: <014603BA-CE1D-4745-A0F2-741063F64192@ultramixer.com> With Apple JDK6 we can call the scale factor like this: toolkit.getDesktopProperty("apple.awt.contentScaleFactor?); Unfortunately thats not possible with JDK7/8. Is there another way to get the scale factor? Best regards, Tobi From mathiapeter at gmail.com Mon Aug 5 01:33:52 2013 From: mathiapeter at gmail.com (Peter Mathia) Date: Mon, 5 Aug 2013 10:33:52 +0200 Subject: exception Message-ID: Hi everyone, is anybody able to tell me something about this error without posting my code? I use javaFX 2.2 to develop Gantt chart visualizer. Sometimes I get this exceptions when I want to update GUI in Platform.runLater thread. The chart has Canvas as a background and every Task in chart is represented by a Rectangle (drag/resize)... Thank you! Peter java.lang.NullPointerException at com.sun.javafx.sg.prism.NGCanvas$RenderBuf.validate(NGCanvas.java:76) at com.sun.javafx.sg.prism.NGCanvas.initCanvas(NGCanvas.java:336) at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:316) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode$CacheFilter.impl_renderNodeToScreen(NGNode.java:712) at com.sun.javafx.sg.BaseCacheFilter.render(BaseCacheFilter.java:168) at com.sun.javafx.sg.prism.NGNode$CacheFilter.render(NGNode.java:660) at com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:487) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:183) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:429) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:320) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:346) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:179) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:429) at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:320) at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:346) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:179) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:117) at com.sun.javafx.tk.quantum.AbstractPainter.paintImpl(AbstractPainter.java:175) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:73) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at com.sun.prism.render.RenderJob.run(RenderJob.java:37) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:98) at java.lang.Thread.run(Thread.java:724) From felix.bembrick at gmail.com Mon Aug 5 03:11:58 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 5 Aug 2013 20:11:58 +1000 Subject: Developing controls based on Canvas? Message-ID: I am investigating the feasibility of developing a JavaFX 8 control based on Canvas. I have chosen Canvas as the base class as this control is of a very dynamic nature and would not be easy to implement with a retained mode style ancestor (at least as far as I can tell). So is this feasible? While I can readily see how to render the visual aspects of the control, I am not sure how to best "embed" other controls within it should that become necessary (and almost certainly will). For example, how would I go about embedding a Button within my control? It looks to me like I would need to create an actual Button node somewhere else in the scenegraph and then perhaps render it within my control using gc.drawImage() passing in a snapshot of the Button node. That's OK but then I have to somehow handle events and I am not sure how best to do that. Another issue I see is that there seems to be no way to apply effects to individual graphic elements within the Canvas as the applyEffect() method applies to the entire Canvas. Finally, a significant obstacle is this issue: https://javafx-jira.kenai.com/browse/RT-23822 This issue relates to the lack of support for LCD font smoothing within Canvas. This may not sound that serious but the difference between LCD font-smoothed text in other controls and the grey-scale text in Canvas is so distinct on my current machine that a control based on Canvas would really stick out like a sore thumb and appear significantly less appealing than a "standard" control. So, am I wasting my time? Are there any other issues I am likely to face? Are there other ways to develop dynamic controls which may involve thousands of nodes (such as lines, curves etc.)? Thanks, Felix From pavel.safrata at oracle.com Mon Aug 5 03:44:12 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 05 Aug 2013 12:44:12 +0200 Subject: Mixing 2D and 3D In-Reply-To: <34B1E065-76C0-4E7D-A54A-586D0FE26D2C@oracle.com> References: <51F96C32.9060500@oracle.com> <34B1E065-76C0-4E7D-A54A-586D0FE26D2C@oracle.com> Message-ID: <51FF81FC.6090706@oracle.com> On 1.8.2013 22:33, Richard Bair wrote: >> How does that fit in with the 2D-ish picking events we deliver now? If a cylinder is picked, how do we describe which part of the cylinder was picked? > Pavel or Chien will have to pipe in on this part of the question, I don't know. > Similar to 2D, the delivered event has coordinates in the cylinder's local coordinate space, so getX(), getY(), getZ() tell you the intersection point of the pick ray cast to the scene by cursor position and the cylinder. Moreover, the events have getPickResult() from which you can obtain also distance from camera, picked face (not used for cylinder but identifies picked triangle for a mesh) and texture coordinates. Pavel From diego.cirujano-cuesta at zeiss.com Mon Aug 5 04:49:30 2013 From: diego.cirujano-cuesta at zeiss.com (Diego Cirujano-Cuesta) Date: Mon, 5 Aug 2013 13:49:30 +0200 Subject: Missed "pulse"? In-Reply-To: References: Message-ID: I had a look to the source code Scott sent me(I think that was not the same that could be sent to Eva-https://javafx-jira.kenai.com/browse/RT-31025- because is not related to the bug). It would be great if we would have all the source code in order to see if it affect us too. About the code you sent me, I think that there is an error. The code that Scott sent me had a line with GridPane.setColumnSpan(gp, 2); that wasn't correctly placed. In fact, by removing it the behaviour is enough to fix the problem but not enough good to have a clean UI structure ;). There is an strange component structure where gridpanes are added to gridcomponents where it shouldn?t be neccesary but it might have test purposes. I didn?t have a look to the other parts. I think that FXML(Scene Builder) might help you here a lot. It would be great if Scott could upload the source code somewhere available for all. Diego From: Scott Palmer To: Richard Bair Cc: Diego Cirujano-Cuesta , "openjfx-dev at openjdk.java.net" Date: 31.07.2013 17:18 Subject: Re: Missed "pulse"? I did notice that commit. Does that require the use of Canvas? We aren't using that, at least not directly. It didn't sound like the same thing.. this one is really strange as *some* nodes are clipped and others aren't. You can download a short video of what I'm experiencing in my app from here http://www.screencast.com/t/8Syrqp5nz This is RT-30591 Scott On Wed, Jul 31, 2013 at 10:58 AM, Richard Bair wrote: Jim just fixed "RT-30223, RT-30826, RT-31044 - Canvas clears clip on Windows/D3D". If you are on Windows and seeing things are drawing that should be clipped, it might be related to one of these fixes. He's trying to get the fix into the 2.2 line as well as in 8. I only considered just now that this might be what you are seeing. Richard On Jul 31, 2013, at 7:42 AM, Scott Palmer wrote: > Interesting. The problem outlined in RT-31025 does involve GridPane with > ColumnConstraints. I will try to dig up the code. > > Scott > > > > On Wed, Jul 31, 2013 at 4:47 AM, Diego Cirujano-Cuesta < > diego.cirujano-cuesta at zeiss.com> wrote: > >> Hi Scott, >> >> I have a component quite similar to the one you described and I also had >> problems like the ones that you mentioned with the same workarounds. BUT I >> found out that the problem was of my understanding. One of the problems >> was, I was using invalidation listeners and I wasn't getting always the >> value and another problem was a gridPane with column constraints. >> >> I had a look deeply and I fix them, now they work perfect. >> >> I saw in Jira you sent your code to Eva. If you want, you can send me the >> problem also(with the isolated code) I can have a look or much better, Eva >> could publish the code in Jira. I am interested. >> >> Regards, >> >> Diego >> >>> (I'm talking JavaFX2.x, but this happens in 8 as well.) >> >>> In my application I occasionally see a situation where the rendering >> doesn't jive with what it should. For example I have implemented my own >> scroll pane (ironically enough I did this to workaround manifestations of a >> problem similar to what I am about to describe in the stock ScrollPane) >> using clipping and translations, but sometimes I see the clipped content at >> the wrong location. So my clipped content is offset from the edge of my >> pane, or rendered over top of things outside my pane, even though it is >> impossible for the clipping and translating to not be set together. If I >> mouse over the offending area it suddenly snaps to the way it should be >> (CSS rules on the content would have forced it to redraw). >> >>> In other situations, I may need to coax a proper rendering of certain >> layouts by nudging the size of something to force another layout. >> >>> Obviously things should just paint correctly the first time. In these >> situations, the variables appear to be set to the correct values, but >> somehow that didn't get to the screen. >> >>> I'm not certain, but I suspect I might be able to work around these issues >> if I could force a "pulse" or mark things as dirty some way to trigger one. >> The thing is, there doesn't seem to be a publicly accessible way to do >> this, presumably because it isn't supposed to be necessary in the first >> place. >>> Platform.runLater(... requestLayout ...) was one workaround that I started >> to use, in the cases where things were particularly bad, but it isn't the >> sort of things I want to have to scatter throughout my code.. >> >>> With recent testing on JavaFX 8 I had to remove some of my workarounds >> because they caused a stack overflow doing layout. In requestLayout, I >> would call requestLayout directly on some specific child nodes (without a >> runLater) that seemed to misbehave - somehow this got back to call >> requestLayout again in my class and a quick attempt to break the cycle >> didn't work. >> >>> I'm sure you can appreciate the frustration in trying to ship a >> professional quality application with this sort of instability in the >> rendering system. >> >>> Since I suspect these issues aren't going to be fixed before 7u40 ships, >> and 8 is a long way off, what is the best thing to do? I have already >> filed bugs for issues in a few specific cases. E.g. >> RT-31025 (In >> >> some cases from a long time ago I was unsure if I was doing something wrong >> so I may not have isolated things into a test case and reported a bug.) >> >> >>> Regards, >> >>> Scott >> >> >> ---------------------------------------- >> This message is intended for a particular addressee only and may contain >> business or company secrets. If you have received this email in error, >> please contact the sender and delete the message immediately. Any use of >> this email, including saving, publishing, copying, replication or >> forwarding of the message or the contents is not permitted. >> >> ---------------------------------------- This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. From tom.schindl at bestsolution.at Mon Aug 5 04:55:19 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 05 Aug 2013 13:55:19 +0200 Subject: Is Node.setClip() expected detect changes to the clip-Node? Message-ID: <51FF92A7.2040205@bestsolution.at> Hi, I've been hunting a bug in TitledPaneSkin [1] which makes me wonder if maybe the control code is using the Clip-Feature in appropriately. The code in general looks like this: public class BlaSkin extends Node { private Rectangle rect; public BlaSki() { rect = new Rectangle(); setClip(rect); } public void changeSize(double x, double y) { rect.setWidth(x); rect.setHeight(y); } } so the clipping node changes its size while the code is running but it looks like the rendering code does not know about this and never updates the peer's clipNode (in impl_updatePeer) now I guess this is simply an optimization introduced in FX8 so my question is is Node expected to detect its clip node changes or is the developer forced to somehow tell the Node to do so (my first direct work around was to set the clip to null and back to the rectangle which fixes the problem)? Tom [1]https://javafx-jira.kenai.com/browse/RT-32117 From pavel.safrata at oracle.com Mon Aug 5 06:07:26 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 05 Aug 2013 15:07:26 +0200 Subject: Is Node.setClip() expected detect changes to the clip-Node? In-Reply-To: <51FF92A7.2040205@bestsolution.at> References: <51FF92A7.2040205@bestsolution.at> Message-ID: <51FFA38E.1090505@oracle.com> Hi Tom, this is definitely a bug, clip node has to be synced automatically. Would you please file a Jira issue? Thanks, Pavel On 5.8.2013 13:55, Tom Schindl wrote: > Hi, > > I've been hunting a bug in TitledPaneSkin [1] which makes me wonder if > maybe the control code is using the Clip-Feature in appropriately. > > The code in general looks like this: > > public class BlaSkin extends Node { > private Rectangle rect; > > public BlaSki() { > rect = new Rectangle(); > setClip(rect); > } > > public void changeSize(double x, double y) { > rect.setWidth(x); > rect.setHeight(y); > } > } > > so the clipping node changes its size while the code is running but it > looks like the rendering code does not know about this and never updates > the peer's clipNode (in impl_updatePeer) now I guess this is simply an > optimization introduced in FX8 so my question is is Node expected to > detect its clip node changes or is the developer forced to somehow tell > the Node to do so (my first direct work around was to set the clip to > null and back to the rectangle which fixes the problem)? > > Tom > > [1]https://javafx-jira.kenai.com/browse/RT-32117 From tom.schindl at bestsolution.at Mon Aug 5 06:26:26 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 05 Aug 2013 15:26:26 +0200 Subject: Is Node.setClip() expected detect changes to the clip-Node? In-Reply-To: <51FFA38E.1090505@oracle.com> References: <51FF92A7.2040205@bestsolution.at> <51FFA38E.1090505@oracle.com> Message-ID: <51FFA802.5080006@bestsolution.at> https://javafx-jira.kenai.com/browse/RT-32123 Tom On 05.08.13 15:07, Pavel Safrata wrote: > Hi Tom, > this is definitely a bug, clip node has to be synced automatically. > Would you please file a Jira issue? > Thanks, > Pavel > > On 5.8.2013 13:55, Tom Schindl wrote: >> Hi, >> >> I've been hunting a bug in TitledPaneSkin [1] which makes me wonder if >> maybe the control code is using the Clip-Feature in appropriately. >> >> The code in general looks like this: >> >> public class BlaSkin extends Node { >> private Rectangle rect; >> >> public BlaSki() { >> rect = new Rectangle(); >> setClip(rect); >> } >> >> public void changeSize(double x, double y) { >> rect.setWidth(x); >> rect.setHeight(y); >> } >> } >> >> so the clipping node changes its size while the code is running but it >> looks like the rendering code does not know about this and never updates >> the peer's clipNode (in impl_updatePeer) now I guess this is simply an >> optimization introduced in FX8 so my question is is Node expected to >> detect its clip node changes or is the developer forced to somehow tell >> the Node to do so (my first direct work around was to set the clip to >> null and back to the rectangle which fixes the problem)? >> >> Tom >> >> [1]https://javafx-jira.kenai.com/browse/RT-32117 > From David.Hill at Oracle.com Mon Aug 5 06:47:55 2013 From: David.Hill at Oracle.com (David Hill) Date: Mon, 05 Aug 2013 09:47:55 -0400 Subject: A different way to handle pulse timing In-Reply-To: References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> Message-ID: <51FFAD0B.9040300@Oracle.com> On 8/1/13 Aug 1, 3:52 PM, Richard Bair wrote: >> as far as I can read it, your idea is to start preparing the next frame right after synchronization (scenegraph to render tree) is completed for the previous frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem with input events starvation. There will be no or very little window, when the events can be processed on the event thread, because the thread will always be either busy handling CSS, animations, etc., or blocked waiting for the render thread to finish rendering. > I think the difference is that I was going to use the vsync as the limiter. That is, the first time through we do a pulse, then we schedule another pulse, then we run that other pulse (almost immediately), then we hit the sync point with the render thread and have to wait for it because it is blocked on vsync. Meanwhile the user events are being queued up. When we get back from this, the next pulse is placed on the end of the queue, we process all input events, then the next pulse. You are assuming several things here - most of which would not be present on something like the PI. * access to vsync * a fast enough rendering that you can usually fit into a vsync period. I would be seriously concerned over user event starvation. It would not take much of a busy set of animations to mean we spin painting a SG that has not completely caught up with the bindings/and or ignoring the incoming input events. -- David Hill Java Embedded Development A committee is a cul-de-sac down which ideas are lured and then quietly strangled. -- Sir Barnett Cocks (1907 - 1989) From kevin.rushforth at oracle.com Mon Aug 5 07:36:43 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 05 Aug 2013 07:36:43 -0700 Subject: exception In-Reply-To: References: Message-ID: <51FFB87B.6050704@oracle.com> This suggests a threading problem, as also commented in https://javafx-jira.kenai.com/browse/RT-27655 (to which you added your stack trace). Can you double-check that you never touch a live node (that is, a node attached to a Scene) from any thread other than the FX Application thread? -- Kevin Peter Mathia wrote: > Hi everyone, > is anybody able to tell me something about this error without posting my > code? I use javaFX 2.2 to develop Gantt chart visualizer. Sometimes I get > this exceptions when I want to update GUI in Platform.runLater thread. > The chart has Canvas as a background and every Task in chart is represented > by a Rectangle (drag/resize)... > Thank you! > > Peter > > java.lang.NullPointerException > at com.sun.javafx.sg.prism.NGCanvas$RenderBuf.validate(NGCanvas.java:76) > at com.sun.javafx.sg.prism.NGCanvas.initCanvas(NGCanvas.java:336) > at com.sun.javafx.sg.prism.NGCanvas.renderContent(NGCanvas.java:316) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) > at > com.sun.javafx.sg.prism.NGNode$CacheFilter.impl_renderNodeToScreen(NGNode.java:712) > at com.sun.javafx.sg.BaseCacheFilter.render(BaseCacheFilter.java:168) > at com.sun.javafx.sg.prism.NGNode$CacheFilter.render(NGNode.java:660) > at com.sun.javafx.sg.prism.NGNode.renderCached(NGNode.java:487) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:183) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) > at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:429) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:320) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:346) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:179) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) > at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:429) > at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:320) > at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:346) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:179) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:204) > at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:420) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:187) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:39) > at com.sun.javafx.sg.BaseNode.render(BaseNode.java:1145) > at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:117) > at > com.sun.javafx.tk.quantum.AbstractPainter.paintImpl(AbstractPainter.java:175) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:73) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at > java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at com.sun.prism.render.RenderJob.run(RenderJob.java:37) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:98) > at java.lang.Thread.run(Thread.java:724) > From swpalmer at gmail.com Mon Aug 5 08:24:25 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 5 Aug 2013 11:24:25 -0400 Subject: Missed "pulse"? In-Reply-To: References: Message-ID: I think that was the same code sent to Eva. I can't use Scene builder for this because the UI is dynamically generated. The general form is that there are several rows of a label and a control, but sometimes I need to group a bunch of these in a TitledPane so that TitledPane spans the columns and it contains another GridPane. There could be cleanup needed and possibly a redundant container is in the hierarchy. Which line # has the incorrectly placed setColumnSpan? I will see if I can clean it up. Thanks for having a look. Scott On 2013-08-05, at 7:49 AM, "Diego Cirujano-Cuesta" wrote: > I had a look to the source code Scott sent me(I think that was not the same that could be sent to Eva-https://javafx-jira.kenai.com/browse/RT-31025- because is not related to the bug). It would be great if we would have all the source code in order to see if it affect us too. > > About the code you sent me, I think that there is an error. The code that Scott sent me had a line with GridPane.setColumnSpan(gp, 2); that wasn't correctly placed. In fact, by removing it the behaviour is enough to fix the problem but not enough good to have a clean UI structure ;). There is an strange component structure where gridpanes are added to gridcomponents where it shouldn?t be neccesary but it might have test purposes. > > I didn?t have a look to the other parts. I think that FXML(Scene Builder) might help you here a lot. > > It would be great if Scott could upload the source code somewhere available for all. > > Diego > > > > From: Scott Palmer > To: Richard Bair > Cc: Diego Cirujano-Cuesta , "openjfx-dev at openjdk.java.net" > Date: 31.07.2013 17:18 > Subject: Re: Missed "pulse"? > > > > I did notice that commit. Does that require the use of Canvas? We aren't using that, at least not directly. It didn't sound like the same thing.. this one is really strange as *some* nodes are clipped and others aren't. You can download a short video of what I'm experiencing in my app from here http://www.screencast.com/t/8Syrqp5nz > This is RT-30591 > > Scott > > > On Wed, Jul 31, 2013 at 10:58 AM, Richard Bair wrote: > Jim just fixed "RT-30223, RT-30826, RT-31044 - Canvas clears clip on Windows/D3D". If you are on Windows and seeing things are drawing that should be clipped, it might be related to one of these fixes. He's trying to get the fix into the 2.2 line as well as in 8. I only considered just now that this might be what you are seeing. > > Richard > > On Jul 31, 2013, at 7:42 AM, Scott Palmer wrote: > > > Interesting. The problem outlined in RT-31025 does involve GridPane with > > ColumnConstraints. I will try to dig up the code. > > > > Scott > > > > > > > > On Wed, Jul 31, 2013 at 4:47 AM, Diego Cirujano-Cuesta < > > diego.cirujano-cuesta at zeiss.com> wrote: > > > >> Hi Scott, > >> > >> I have a component quite similar to the one you described and I also had > >> problems like the ones that you mentioned with the same workarounds. BUT I > >> found out that the problem was of my understanding. One of the problems > >> was, I was using invalidation listeners and I wasn't getting always the > >> value and another problem was a gridPane with column constraints. > >> > >> I had a look deeply and I fix them, now they work perfect. > >> > >> I saw in Jira you sent your code to Eva. If you want, you can send me the > >> problem also(with the isolated code) I can have a look or much better, Eva > >> could publish the code in Jira. I am interested. > >> > >> Regards, > >> > >> Diego > >> > >>> (I'm talking JavaFX2.x, but this happens in 8 as well.) > >> > >>> In my application I occasionally see a situation where the rendering > >> doesn't jive with what it should. For example I have implemented my own > >> scroll pane (ironically enough I did this to workaround manifestations of a > >> problem similar to what I am about to describe in the stock ScrollPane) > >> using clipping and translations, but sometimes I see the clipped content at > >> the wrong location. So my clipped content is offset from the edge of my > >> pane, or rendered over top of things outside my pane, even though it is > >> impossible for the clipping and translating to not be set together. If I > >> mouse over the offending area it suddenly snaps to the way it should be > >> (CSS rules on the content would have forced it to redraw). > >> > >>> In other situations, I may need to coax a proper rendering of certain > >> layouts by nudging the size of something to force another layout. > >> > >>> Obviously things should just paint correctly the first time. In these > >> situations, the variables appear to be set to the correct values, but > >> somehow that didn't get to the screen. > >> > >>> I'm not certain, but I suspect I might be able to work around these issues > >> if I could force a "pulse" or mark things as dirty some way to trigger one. > >> The thing is, there doesn't seem to be a publicly accessible way to do > >> this, presumably because it isn't supposed to be necessary in the first > >> place. > >>> Platform.runLater(... requestLayout ...) was one workaround that I started > >> to use, in the cases where things were particularly bad, but it isn't the > >> sort of things I want to have to scatter throughout my code.. > >> > >>> With recent testing on JavaFX 8 I had to remove some of my workarounds > >> because they caused a stack overflow doing layout. In requestLayout, I > >> would call requestLayout directly on some specific child nodes (without a > >> runLater) that seemed to misbehave - somehow this got back to call > >> requestLayout again in my class and a quick attempt to break the cycle > >> didn't work. > >> > >>> I'm sure you can appreciate the frustration in trying to ship a > >> professional quality application with this sort of instability in the > >> rendering system. > >> > >>> Since I suspect these issues aren't going to be fixed before 7u40 ships, > >> and 8 is a long way off, what is the best thing to do? I have already > >> filed bugs for issues in a few specific cases. E.g. > >> RT-31025 (In > >> > >> some cases from a long time ago I was unsure if I was doing something wrong > >> so I may not have isolated things into a test case and reported a bug.) > >> > >> > >>> Regards, > >> > >>> Scott > >> > >> > >> ---------------------------------------- > >> This message is intended for a particular addressee only and may contain > >> business or company secrets. If you have received this email in error, > >> please contact the sender and delete the message immediately. Any use of > >> this email, including saving, publishing, copying, replication or > >> forwarding of the message or the contents is not permitted. > >> > >> > > > > > ---------------------------------------- > This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. > From hang.vo at oracle.com Mon Aug 5 08:32:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Aug 2013 15:32:55 +0000 Subject: hg: openjfx/8/graphics/rt: Follow-on fix for RT-31249 to call Application.setName from FX app thread Message-ID: <20130805153402.A81B5485DD@hg.openjdk.java.net> Changeset: 89345a49e71f Author: kcr Date: 2013-08-05 08:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/89345a49e71f Follow-on fix for RT-31249 to call Application.setName from FX app thread ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java From swpalmer at gmail.com Mon Aug 5 09:27:02 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 5 Aug 2013 12:27:02 -0400 Subject: A different way to handle pulse timing In-Reply-To: <51FFAD0B.9040300@Oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> Message-ID: <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> The idea of user event starvation has been mentioned before and has me a little confused? Why aren't things handled as a simple queue, with no priorities or anything, so starvation is impossible? Is this something the OS is doing? In terms of rendering fast enough that you can fit things into a vsync period.. that shouldn't be necessary. If you miss one sync period then you should be finished by the next.. having a strict requirement to fit within a single vsync period is impractical. Without access to true sync, a timer would serve the same purpose. Having both a timer and sync is where things get silly. Cheers, Scott On 2013-08-05, at 9:47 AM, David Hill wrote: > On 8/1/13 Aug 1, 3:52 PM, Richard Bair wrote: >>> as far as I can read it, your idea is to start preparing the next frame right after synchronization (scenegraph to render tree) is completed for the previous frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem with input events starvation. There will be no or very little window, when the events can be processed on the event thread, because the thread will always be either busy handling CSS, animations, etc., or blocked waiting for the render thread to finish rendering. >> I think the difference is that I was going to use the vsync as the limiter. That is, the first time through we do a pulse, then we schedule another pulse, then we run that other pulse (almost immediately), then we hit the sync point with the render thread and have to wait for it because it is blocked on vsync. Meanwhile the user events are being queued up. When we get back from this, the next pulse is placed on the end of the queue, we process all input events, then the next pulse. > You are assuming several things here - most of which would not be present on something like the PI. > * access to vsync > * a fast enough rendering that you can usually fit into a vsync period. > > I would be seriously concerned over user event starvation. It would not take much of a busy set of animations to mean we spin painting a SG that has not completely caught up with the bindings/and or ignoring the incoming input events. > > -- > David Hill > Java Embedded Development > > A committee is a cul-de-sac down which ideas are lured and then quietly strangled. > -- Sir Barnett Cocks (1907 - 1989) > From richard.bair at oracle.com Mon Aug 5 09:33:42 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 09:33:42 -0700 Subject: A different way to handle pulse timing In-Reply-To: <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> Message-ID: > The idea of user event starvation has been mentioned before and has me a little confused? Why aren't things handled as a simple queue, with no priorities or anything, so starvation is impossible? Is this something the OS is doing? That's what I'm wondering too. > In terms of rendering fast enough that you can fit things into a vsync period.. that shouldn't be necessary. If you miss one sync period then you should be finished by the next.. having a strict requirement to fit within a single vsync period is impractical. > > Without access to true sync, a timer would serve the same purpose. Having both a timer and sync is where things get silly. Exactly what I was thinking. Richard From David.Hill at Oracle.com Mon Aug 5 09:49:56 2013 From: David.Hill at Oracle.com (David Hill) Date: Mon, 05 Aug 2013 12:49:56 -0400 Subject: A different way to handle pulse timing In-Reply-To: <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> Message-ID: <51FFD7B4.3010003@Oracle.com> On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote: > The idea of user event starvation has been mentioned before and has me a little confused? Why aren't things handled as a simple queue, with no priorities or anything, so starvation is impossible? Is this something the OS is doing? There is a "simple" user input queue - the problem is that we dispatch those arriving events on the user event *thread*, and that thread is used for a lot of thing other than user input. It is not so much the cost of handling the input, but rather the cost of handling the actions after input. As an example, on a mouse click, a control may change - which might cause a re-layout, which should cause repainting to happen. Currently, JFX uses a separate "rendering thread" for painting. This is goodness, especially when you have a GPU. On the user event thread we need to queue up and then stage the repaint request. Things are more complicated because many (but not all) painting/window management tasks need to be single threaded. In the past we have seen situations where there are so many tasks on the user event thread, that user response (even on desktop) was not acceptable. Some of these items are getting better as we improve design (ie less redundant layout operations causes by a single change/event). Those of us who have been through several iterations of this are suggesting caution on a rework though :-) BTW - it is very easy to write a "bad" app which will demonstrate the problem. As a thought example - if on a button click, you calculate PI to the nth digit before updating your text field - and you do it in the event callback - you are stalling the user event thread. Add in enough computes and you get an very unresponsive app. Instead of computes, you can just call sleep to see the problem too :-) Dave > > > In terms of rendering fast enough that you can fit things into a vsync period.. that shouldn't be necessary. If you miss one sync period then you should be finished by the next.. having a strict requirement to fit within a single vsync period is impractical. > > Without access to true sync, a timer would serve the same purpose. Having both a timer and sync is where things get silly. > > Cheers, > > Scott > > On 2013-08-05, at 9:47 AM, David Hill wrote: > >> On 8/1/13 Aug 1, 3:52 PM, Richard Bair wrote: >>>> as far as I can read it, your idea is to start preparing the next frame right after synchronization (scenegraph to render tree) is completed for the previous frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem with input events starvation. There will be no or very little window, when the events can be processed on the event thread, because the thread will always be either busy handling CSS, animations, etc., or blocked waiting for the render thread to finish rendering. >>> I think the difference is that I was going to use the vsync as the limiter. That is, the first time through we do a pulse, then we schedule another pulse, then we run that other pulse (almost immediately), then we hit the sync point with the render thread and have to wait for it because it is blocked on vsync. Meanwhile the user events are being queued up. When we get back from this, the next pulse is placed on the end of the queue, we process all input events, then the next pulse. >> You are assuming several things here - most of which would not be present on something like the PI. >> * access to vsync >> * a fast enough rendering that you can usually fit into a vsync period. >> >> I would be seriously concerned over user event starvation. It would not take much of a busy set of animations to mean we spin painting a SG that has not completely caught up with the bindings/and or ignoring the incoming input events. >> >> -- >> David Hill >> Java Embedded Development >> >> A committee is a cul-de-sac down which ideas are lured and then quietly strangled. >> -- Sir Barnett Cocks (1907 - 1989) >> -- David Hill Java Embedded Development The radical of one century is the conservative of the next. The radical invents the views. When he has worn them out the conservative adopts them. -- Mark Twain From richard.bair at oracle.com Mon Aug 5 10:09:07 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 10:09:07 -0700 Subject: A different way to handle pulse timing In-Reply-To: <51FFD7B4.3010003@Oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> Message-ID: <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> > In the past we have seen situations where there are so many tasks on the user event thread, that user response (even on desktop) was not acceptable. Some of these items are getting better as we improve design (ie less redundant layout operations causes by a single change/event). Right, but I don't see how that could still happen in this proposal? The problem before was the pulse events were handled outside of the event queue (as I recall) so that they got higher priority. We got rid of the higher priority and starvation ceased. This proposal would not reintroduce priorities, so I don't see how you could end up with input event starvation again? > BTW - it is very easy to write a "bad" app which will demonstrate the problem. As a thought example - if on a button click, you calculate PI to the nth digit before updating your text field - and you do it in the event callback - you are stalling the user event thread. Add in enough computes and you get an very unresponsive app. Instead of computes, you can just call sleep to see the problem too :-) But this is the case today as well. Richard From hang.vo at oracle.com Mon Aug 5 10:17:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Aug 2013 17:17:33 +0000 Subject: hg: openjfx/8/graphics/rt: Fix to RT-29771: Dirty regions don't work with moving camera Message-ID: <20130805171801.CBF69485E2@hg.openjdk.java.net> Changeset: c3ffaeb2e609 Author: Chien Yang Date: 2013-08-05 10:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c3ffaeb2e609 Fix to RT-29771: Dirty regions don't work with moving camera Reviewed by Kevin ! modules/graphics/src/main/java/javafx/scene/Camera.java ! modules/graphics/src/main/java/javafx/scene/Scene.java From tom.schindl at bestsolution.at Mon Aug 5 10:26:45 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 05 Aug 2013 19:26:45 +0200 Subject: Is Node.setClip() expected detect changes to the clip-Node? In-Reply-To: <51FFA802.5080006@bestsolution.at> References: <51FF92A7.2040205@bestsolution.at> <51FFA38E.1090505@oracle.com> <51FFA802.5080006@bestsolution.at> Message-ID: <51FFE055.6000604@bestsolution.at> I think I've nailed it down now - the problem is that the clip's treeVisible-Property is not update appropiately, hence it is never taken into account and synced because the system thinks it is invisible after the first initialization. Tom On 05.08.13 15:26, Tom Schindl wrote: > https://javafx-jira.kenai.com/browse/RT-32123 > > Tom > > On 05.08.13 15:07, Pavel Safrata wrote: >> Hi Tom, >> this is definitely a bug, clip node has to be synced automatically. >> Would you please file a Jira issue? >> Thanks, >> Pavel >> >> On 5.8.2013 13:55, Tom Schindl wrote: >>> Hi, >>> >>> I've been hunting a bug in TitledPaneSkin [1] which makes me wonder if >>> maybe the control code is using the Clip-Feature in appropriately. >>> >>> The code in general looks like this: >>> >>> public class BlaSkin extends Node { >>> private Rectangle rect; >>> >>> public BlaSki() { >>> rect = new Rectangle(); >>> setClip(rect); >>> } >>> >>> public void changeSize(double x, double y) { >>> rect.setWidth(x); >>> rect.setHeight(y); >>> } >>> } >>> >>> so the clipping node changes its size while the code is running but it >>> looks like the rendering code does not know about this and never updates >>> the peer's clipNode (in impl_updatePeer) now I guess this is simply an >>> optimization introduced in FX8 so my question is is Node expected to >>> detect its clip node changes or is the developer forced to somehow tell >>> the Node to do so (my first direct work around was to set the clip to >>> null and back to the rectangle which fixes the problem)? >>> >>> Tom >>> >>> [1]https://javafx-jira.kenai.com/browse/RT-32117 >> > From swpalmer at gmail.com Mon Aug 5 10:40:29 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 5 Aug 2013 13:40:29 -0400 Subject: A different way to handle pulse timing In-Reply-To: <51FFD7B4.3010003@Oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> Message-ID: <89A5A365-E726-4A32-9F6D-10E0E7B7008D@gmail.com> On 2013-08-05, at 12:49 PM, David Hill wrote: > On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote: >> The idea of user event starvation has been mentioned before and has me a little confused? Why aren't things handled as a simple queue, with no priorities or anything, so starvation is impossible? Is this something the OS is doing? > > There is a "simple" user input queue - the problem is that we dispatch those arriving events on the user event *thread*, and that thread is used for a lot of thing other than user input. It is not so much the cost of handling the input, but rather the cost of handling the actions after input. Right, I guess I don't have a complete picture of the threading model. I assume that user events like mouse clicks and key presses are coming in from some OS thread and queued on the "user event thread". Meanwhile things like runLater() are also queued on the user event thread. If other user events from the OS happened they would naturally be interleaved with runLater type operations - everything eventually gets processed no matter how busy the system is, no matter what you do on the user event thread so long as eventually the operation completes. The cost of handling the input, would either complete and then the next event is processed or they might trigger additional work via runLater. The runLater stuff would be queued behind any other OS events that have already been queued by the OS input thread, they wouldn't "jump the queue". I suspect I am oversimplifying. If there is somewhere to go to get a idea of the actual threading model please point me in the right direction. Regards, Scott From David.Hill at Oracle.com Mon Aug 5 11:21:31 2013 From: David.Hill at Oracle.com (David Hill) Date: Mon, 05 Aug 2013 14:21:31 -0400 Subject: A different way to handle pulse timing In-Reply-To: <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> Message-ID: <51FFED2B.3050105@Oracle.com> On 8/5/13 Aug 5, 1:09 PM, Richard Bair wrote: >> In the past we have seen situations where there are so many tasks on the user event thread, that user response (even on desktop) was not acceptable. Some of these items are getting better as we improve design (ie less redundant layout operations causes by a single change/event). > Right, but I don't see how that could still happen in this proposal? The problem before was the pulse events were handled outside of the event queue (as I recall) so that they got higher priority. We got rid of the higher priority and starvation ceased. This proposal would not reintroduce priorities, so I don't see how you could end up with input event starvation again? rendering is "staged" on the event queue (layout, adding the render job to the render thread). It has been this way for quite a while now. As far as I remember,( other than paths with "live resize"), we have never had a mechanism that provided for event priority (at least not on the Linux side where I tend to live). >> BTW - it is very easy to write a "bad" app which will demonstrate the problem. As a thought example - if on a button click, you calculate PI to the nth digit before updating your text field - and you do it in the event callback - you are stalling the user event thread. Add in enough computes and you get an very unresponsive app. Instead of computes, you can just call sleep to see the problem too :-) > But this is the case today as well. Indeed - and something we document as a "do not do that because it hurts" item. I used this to illustrate the problem. Just like the app writer, we need to make sure we use the user event queue in ways that allows us to handle events in a timely fashion. In some cases - that means we do a lot of work to put computes on a different thread (ie rendering). > > Richard -- David Hill Java Embedded Development Ich wei? nicht. -- an unknown German philosopher From David.Hill at Oracle.com Mon Aug 5 11:25:28 2013 From: David.Hill at Oracle.com (David Hill) Date: Mon, 05 Aug 2013 14:25:28 -0400 Subject: A different way to handle pulse timing In-Reply-To: <89A5A365-E726-4A32-9F6D-10E0E7B7008D@gmail.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <89A5A365-E726-4A32-9F6D-10E0E7B7008D@gmail.com> Message-ID: <51FFEE18.2040707@Oracle.com> On 8/5/13 Aug 5, 1:40 PM, Scott Palmer wrote: > On 2013-08-05, at 12:49 PM, David Hill wrote: > >> On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote: >>> The idea of user event starvation has been mentioned before and has me a little confused? Why aren't things handled as a simple queue, with no priorities or anything, so starvation is impossible? Is this something the OS is doing? >> There is a "simple" user input queue - the problem is that we dispatch those arriving events on the user event *thread*, and that thread is used for a lot of thing other than user input. It is not so much the cost of handling the input, but rather the cost of handling the actions after input. > Right, I guess I don't have a complete picture of the threading model. I think that there is a relatively small number of people that do - and I count myself as someone that has a good, but partial, understanding of it. > > I assume that user events like mouse clicks and key presses are coming in from some OS thread and queued on the "user event thread". Meanwhile things like runLater() are also queued on the user event thread. If other user events from the OS happened they would naturally be interleaved with runLater type operations - everything eventually gets processed no matter how busy the system is, no matter what you do on the user event thread so long as eventually the operation completes. The cost of handling the input, would either complete and then the next event is processed or they might trigger additional work via runLater. The runLater stuff would be queued behind any other OS events that have already been queued by the OS input thread, they wouldn't "jump the queue". > > I suspect I am oversimplifying. If there is somewhere to go to get a idea of the actual threading model please point me in the right direction. As part of our "porting guide" which will just be part of the openjfx wiki - this is something that I want to write up, at least in overview. Not there yet though. I suspect that some of the details will be changing over the next while anyway. The repo refactoring now allows us to clean up some of the rather convoluted means of communicating from the API through quantum to Prism and Glass. Dave -- David Hill Java Embedded Development "The conventional view serves to protect us from the painful job of thinking." -- John Kenneth Galbraith (1908 - 2006) From richard.bair at oracle.com Mon Aug 5 11:26:05 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 11:26:05 -0700 Subject: A different way to handle pulse timing In-Reply-To: <51FFED2B.3050105@Oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> <51FFED2B.3050105@Oracle.com> Message-ID: >>> In the past we have seen situations where there are so many tasks on the user event thread, that user response (even on desktop) was not acceptable. Some of these items are getting better as we improve design (ie less redundant layout operations causes by a single change/event). >> Right, but I don't see how that could still happen in this proposal? The problem before was the pulse events were handled outside of the event queue (as I recall) so that they got higher priority. We got rid of the higher priority and starvation ceased. This proposal would not reintroduce priorities, so I don't see how you could end up with input event starvation again? > rendering is "staged" on the event queue (layout, adding the render job to the render thread). It has been this way for quite a while now. As far as I remember,( other than paths with "live resize"), we have never had a mechanism that provided for event priority (at least not on the Linux side where I tend to live). This is how I thought it used to be done: we had (still have) a separate glass thread which fires off once ever 16ms or so. We used to take this pulse and handle it at the next available opportunity, which was explicit prioritization. If the pulse handling took longer than 16ms, by the time the pulse ended we'd have another pulse ready to be handled and would starve the queue. Today, we get this event and add it to the event queue, so we are never starving the event queue. In this proposal, we also would be putting the next pulse on the end of the queue, so it is impossible to starve input events. Thanks Richard From richard.bair at oracle.com Mon Aug 5 11:39:15 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 11:39:15 -0700 Subject: A different way to handle pulse timing In-Reply-To: <89A5A365-E726-4A32-9F6D-10E0E7B7008D@gmail.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <89A5A365-E726-4A32-9F6D-10E0E7B7008D@gmail.com> Message-ID: <48F6FC7F-6CEA-4DF7-86C8-A47D89429E41@oracle.com> > Right, I guess I don't have a complete picture of the threading model. > > I assume that user events like mouse clicks and key presses are coming in from some OS thread and queued on the "user event thread". Meanwhile things like runLater() are also queued on the user event thread. If other user events from the OS happened they would naturally be interleaved with runLater type operations - everything eventually gets processed no matter how busy the system is, no matter what you do on the user event thread so long as eventually the operation completes. The cost of handling the input, would either complete and then the next event is processed or they might trigger additional work via runLater. The runLater stuff would be queued behind any other OS events that have already been queued by the OS input thread, they wouldn't "jump the queue". That should basically be correct. The only wrinkle is that since we rely on the OS event queues (other than on embedded), if the OS does event prioritization it is possible that things won't get delivered to us in exactly the same order, but I believe in Glass we now make sure our events are not getting higher prioritization to avoid event starvation, so that the above thread model understanding should be correct. Richard From richard.bair at oracle.com Mon Aug 5 11:42:12 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 11:42:12 -0700 Subject: A different way to handle pulse timing In-Reply-To: <51FBAD40.10907@oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FBAD40.10907@oracle.com> Message-ID: > I now see the picture. > > As I wrote in the previous email, it seems that we currently are not blocked waiting for vsync(), at least on Windows with D3D pipeline. Anyway, even if we "fix" that, what you propose is that sometimes both threads will be blocked (the render thread waiting for vsync, the event thread waiting for the render thread), which doesn't sound perfect. Right. That stinks. > Note that on Windows and Mac OS X, input events and application runnables are handled differently at the native level (either using different mechanisms, or having different priorities). To implement this proposal, we'll need to eliminate the difference, which may be a difficult task. Are the application runnables at a higher or lower priority than input events? From richard.bair at oracle.com Mon Aug 5 11:46:18 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 11:46:18 -0700 Subject: A different way to handle pulse timing In-Reply-To: References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FBAD40.10907@oracle.com> Message-ID: <6A9196B4-595C-4EE1-9140-23E02A162697@oracle.com> >> As I wrote in the previous email, it seems that we currently are not blocked waiting for vsync(), at least on Windows with D3D pipeline. Anyway, even if we "fix" that, what you propose is that sometimes both threads will be blocked (the render thread waiting for vsync, the event thread waiting for the render thread), which doesn't sound perfect. > > Right. That stinks. So today, the FX thread will block waiting for the render thread at the point where we synchronize state between the FX thread and render thread. The problem with this proposal is that we will wait here much longer waiting for vsync in the case that we have animations happening, which is just dead time when we ought to be preparing the next frame. Richard From hang.vo at oracle.com Mon Aug 5 13:03:12 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Aug 2013 20:03:12 +0000 Subject: hg: openjfx/8/controls/rt: Added some more tests for BehaviorBase, added comments to BehaviorBase. Message-ID: <20130805200411.C5A69485E7@hg.openjdk.java.net> Changeset: 2f80082e42ef Author: rbair Date: 2013-08-05 13:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2f80082e42ef Added some more tests for BehaviorBase, added comments to BehaviorBase. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java From hang.vo at oracle.com Mon Aug 5 13:32:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Aug 2013 20:32:49 +0000 Subject: hg: openjfx/8/controls/rt: Reduced redundant method invocations in TabPaneBehavior. Message-ID: <20130805203315.01604485E9@hg.openjdk.java.net> Changeset: 0dc911479304 Author: rbair Date: 2013-08-05 13:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0dc911479304 Reduced redundant method invocations in TabPaneBehavior. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TraversalEngine.java From hang.vo at oracle.com Mon Aug 5 14:17:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Aug 2013 21:17:55 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130805211848.0EB43485ED@hg.openjdk.java.net> Changeset: fcdb21d8a960 Author: Felipe Heidrich Date: 2013-08-05 14:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fcdb21d8a960 RT-30922: Implement 9-slice region background caching ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 53a4fad540f1 Author: Felipe Heidrich Date: 2013-08-05 14:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/53a4fad540f1 RT-32126: composite glyphs broken after RT-30367 ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontStrike.java ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java From hang.vo at oracle.com Mon Aug 5 14:17:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 05 Aug 2013 21:17:55 +0000 Subject: hg: openjfx/8/controls/rt: Added tests to test BehaviorBase focus / mouse events are handled correctly Message-ID: <20130805211817.E5ABC485EB@hg.openjdk.java.net> Changeset: b939cc31d31c Author: rbair Date: 2013-08-05 14:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b939cc31d31c Added tests to test BehaviorBase focus / mouse events are handled correctly ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java ! modules/controls/src/test/java/javafx/scene/control/ButtonTest.java ! modules/controls/src/test/java/javafx/scene/control/ColorPickerTest.java From hjohn at xs4all.nl Mon Aug 5 15:27:03 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 06 Aug 2013 00:27:03 +0200 Subject: A different way to handle pulse timing In-Reply-To: <6A9196B4-595C-4EE1-9140-23E02A162697@oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FBAD40.10907@oracle.com> <6A9196B4-595C-4EE1-9140-23E02A162697@oracle.com> Message-ID: <520026B7.7060600@xs4all.nl> On 5/08/2013 20:46, Richard Bair wrote: >>> As I wrote in the previous email, it seems that we currently are not blocked waiting for vsync(), at least on Windows with D3D pipeline. Anyway, even if we "fix" that, what you propose is that sometimes both threads will be blocked (the render thread waiting for vsync, the event thread waiting for the render thread), which doesn't sound perfect. >> Right. That stinks. > So today, the FX thread will block waiting for the render thread at the point where we synchronize state between the FX thread and render thread. The problem with this proposal is that we will wait here much longer waiting for vsync in the case that we have animations happening, which is just dead time when we ought to be preparing the next frame. > > Richard Reading all this I get the distinct feeling that the current way of doing things is 'double buffering', where you have to wait until vsync arrives before you can start with the next frame, while you are looking for 'triple buffering', which allows a new frame to be prepared in a seperate buffer/graph/layout while the first (finished) buffer/graph/layout waits to be passed off to the render thread when vsync arrives. --John From hjohn at xs4all.nl Mon Aug 5 15:34:15 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 06 Aug 2013 00:34:15 +0200 Subject: Is Node.setClip() expected detect changes to the clip-Node? In-Reply-To: <51FF92A7.2040205@bestsolution.at> References: <51FF92A7.2040205@bestsolution.at> Message-ID: <52002867.2050507@xs4all.nl> I think I noticed something like this some time ago, but related to a TreeCell. I basically used the clip to make a graphic capable of filling up like a progress bar (there was a graphic that showed a standard non-filled display, and an overlayed graphic that showed the filled form, but was clipped depending on how far the bar needed to be filled). This didn't always work as expected, and it looked like a clip change wasn't always picked up. In case it is useful, this was issue RT-19285 . --John On 5/08/2013 13:55, Tom Schindl wrote: > Hi, > > I've been hunting a bug in TitledPaneSkin [1] which makes me wonder if > maybe the control code is using the Clip-Feature in appropriately. > > The code in general looks like this: > > public class BlaSkin extends Node { > private Rectangle rect; > > public BlaSki() { > rect = new Rectangle(); > setClip(rect); > } > > public void changeSize(double x, double y) { > rect.setWidth(x); > rect.setHeight(y); > } > } > > so the clipping node changes its size while the code is running but it > looks like the rendering code does not know about this and never updates > the peer's clipNode (in impl_updatePeer) now I guess this is simply an > optimization introduced in FX8 so my question is is Node expected to > detect its clip node changes or is the developer forced to somehow tell > the Node to do so (my first direct work around was to set the clip to > null and back to the rectangle which fixes the problem)? > > Tom > > [1]https://javafx-jira.kenai.com/browse/RT-32117 > From jonathan.giles at oracle.com Mon Aug 5 17:10:57 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 06 Aug 2013 12:10:57 +1200 Subject: Developing controls based on Canvas? In-Reply-To: References: Message-ID: <52003F11.8000502@oracle.com> I think it would pay to take a step back and understand why you think a 'traditional' scenegraph-based (or retained mode) control is not sufficient for your needs? Unfortunately you've not detailed your use case, so it is hard to give any specific advice. Are you able to give any details about what it is you're trying to build and why you think the normal approach to building controls is not sufficient? We've built some fairly complex controls using this approach, and if implemented wisely, there is very little that a scenegraph-based approach can't do. Specifically, do you think your control will render all of the 'thousands of nodes' at once, or will many of these nodes be off screen or otherwise not visible at any one time? For things like the TableView we only render the nodes that are visible. This means that regardless of whether there are 100 or 1,000,000 rows of data, we only have visual nodes for the 20 visible rows, for example. Keeping your scenegraph as minimal as possible is always a very wise idea, if performance is a concern. As you note, the other problem is that you will run into issues if you want to mix canvas rendering with the scenegraph-based controls like Button. The best you're likely to achieve (having not tried it personally) is to position the control on top of the canvas, rather than attempting to render the control inside the canvas (and having to then deal with event handling, etc). This will likely prove to be finicky, and more cumbersome than simply using an entirely canvas-based or entirely scenegraph-based approach. -- Jonathan On 5/08/2013 10:11 p.m., Felix Bembrick wrote: > I am investigating the feasibility of developing a JavaFX 8 control based > on Canvas. I have chosen Canvas as the base class as this control is of a > very dynamic nature and would not be easy to implement with a retained mode > style ancestor (at least as far as I can tell). > > So is this feasible? While I can readily see how to render the visual > aspects of the control, I am not sure how to best "embed" other controls > within it should that become necessary (and almost certainly will). > > For example, how would I go about embedding a Button within my control? It > looks to me like I would need to create an actual Button node somewhere > else in the scenegraph and then perhaps render it within my control using > gc.drawImage() passing in a snapshot of the Button node. That's OK but > then I have to somehow handle events and I am not sure how best to do that. > > Another issue I see is that there seems to be no way to apply effects to > individual graphic elements within the Canvas as the applyEffect() method > applies to the entire Canvas. > > Finally, a significant obstacle is this issue: > > https://javafx-jira.kenai.com/browse/RT-23822 > > This issue relates to the lack of support for LCD font smoothing within > Canvas. This may not sound that serious but the difference between LCD > font-smoothed text in other controls and the grey-scale text in Canvas is > so distinct on my current machine that a control based on Canvas would > really stick out like a sore thumb and appear significantly less appealing > than a "standard" control. > > So, am I wasting my time? > Are there any other issues I am likely to face? > Are there other ways to develop dynamic controls which may involve > thousands of nodes (such as lines, curves etc.)? > > Thanks, > > Felix From zonski at gmail.com Mon Aug 5 17:38:48 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 6 Aug 2013 10:38:48 +1000 Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) Message-ID: Sneaking in here, as you've given an opening with "if implemented wisely, there is very little that a scenegraph-based approach can't do". The question I've been asking for a while is what does "implemented wisely" look like in JFX. This has come up in the performance conversations, the game conversations, the CAD conversations, and many other places. No one seems to have an answer, but you're building extremely complex stuff on a regular basis - what's your tips? When you say you only have "20 visible nodes" out of 1000's in general are the other nodes: a) in the scenegraph and set to not visible b) in memory but not in the scenegraph - added/removed when scrolled into view and out of view c) not in memory, created, added and then removed, destroyed when scrolled into view and out of view d) something else? I know Table uses a rubber stamp approach, where it re-uses cell views where possible, but let's say every row in my 100,000 row Table was uniquely rendered using a different cell. What would happen under the covers? How do you work out the scroll range as well? Each cell can be a unique height right? How do you know the extents of the vertical scrolling without instantiating and rendering everything? Is this what you do? What if a cell is changing size (has a collapsable pane in it, etc) - what happens to the vertical scroll range? Do any of the controls have zooming on them? Have you had to deal with this and have you got a strategy for handling this with respect to scroll bounds, working out which nodes are in view, scaling fonts, etc? Could you hazard a guess at what you would do if you had to implement zooming on a Table for example? Maybe the Table is lucky with its restrictive grid like layout but imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general strategy? On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles wrote: > I think it would pay to take a step back and understand why you think a > 'traditional' scenegraph-based (or retained mode) control is not sufficient > for your needs? > Unfortunately you've not detailed your use case, so it is hard to give any > specific advice. Are you able to give any details about what it is you're > trying to build and why you think the normal approach to building controls > is not sufficient? > > We've built some fairly complex controls using this approach, and if > implemented wisely, there is very little that a scenegraph-based approach > can't do. Specifically, do you think your control will render all of the > 'thousands of nodes' at once, or will many of these nodes be off screen or > otherwise not visible at any one time? For things like the TableView we > only render the nodes that are visible. This means that regardless of > whether there are 100 or 1,000,000 rows of data, we only have visual nodes > for the 20 visible rows, for example. Keeping your scenegraph as minimal as > possible is always a very wise idea, if performance is a concern. > > As you note, the other problem is that you will run into issues if you > want to mix canvas rendering with the scenegraph-based controls like > Button. The best you're likely to achieve (having not tried it personally) > is to position the control on top of the canvas, rather than attempting to > render the control inside the canvas (and having to then deal with event > handling, etc). This will likely prove to be finicky, and more cumbersome > than simply using an entirely canvas-based or entirely scenegraph-based > approach. > > -- Jonathan > > > On 5/08/2013 10:11 p.m., Felix Bembrick wrote: > >> I am investigating the feasibility of developing a JavaFX 8 control based >> on Canvas. I have chosen Canvas as the base class as this control is of a >> very dynamic nature and would not be easy to implement with a retained >> mode >> style ancestor (at least as far as I can tell). >> >> So is this feasible? While I can readily see how to render the visual >> aspects of the control, I am not sure how to best "embed" other controls >> within it should that become necessary (and almost certainly will). >> >> For example, how would I go about embedding a Button within my control? >> It >> looks to me like I would need to create an actual Button node somewhere >> else in the scenegraph and then perhaps render it within my control using >> gc.drawImage() passing in a snapshot of the Button node. That's OK but >> then I have to somehow handle events and I am not sure how best to do >> that. >> >> Another issue I see is that there seems to be no way to apply effects to >> individual graphic elements within the Canvas as the applyEffect() method >> applies to the entire Canvas. >> >> Finally, a significant obstacle is this issue: >> >> https://javafx-jira.kenai.com/**browse/RT-23822 >> >> This issue relates to the lack of support for LCD font smoothing within >> Canvas. This may not sound that serious but the difference between LCD >> font-smoothed text in other controls and the grey-scale text in Canvas is >> so distinct on my current machine that a control based on Canvas would >> really stick out like a sore thumb and appear significantly less appealing >> than a "standard" control. >> >> So, am I wasting my time? >> Are there any other issues I am likely to face? >> Are there other ways to develop dynamic controls which may involve >> thousands of nodes (such as lines, curves etc.)? >> >> Thanks, >> >> Felix >> > > From richard.bair at oracle.com Mon Aug 5 17:47:32 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 17:47:32 -0700 Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) In-Reply-To: References: Message-ID: <07893547-5A4A-4207-9E41-96BFFE6CF04F@oracle.com> > I know Table uses a rubber stamp approach, where it re-uses cell views > where possible One small correction -- this isn't what we call the rubber stamp (which is what Swing did). The rubber stamp approach is to use a *single* cell and change its state and reuse it for rendering everything (which implies immediate mode rendering). In FX we have a different unique cell for each cell on the screen and then recycle them as necessary. Richard From jonathan.giles at oracle.com Mon Aug 5 18:00:34 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 06 Aug 2013 13:00:34 +1200 Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) In-Reply-To: References: Message-ID: <52004AB2.3050800@oracle.com> I don't think there is any particular secret sauce going on in what I do compared with the general guidelines that have been spelled out numerous times. It's the same old, same old: don't create more nodes than you need, don't modify the scenegraph needlessly, don't update the scenegraph multiple times in a single pulse, change state as little as possible, use as few listeners as possible, etc. I wish I had something more groundbreaking for you, but that is about it :-) With respect to TableView (and ListView, TreeView, and TreeTableView), they are all based on the same virtualisation code (VirtualFlow for those of you playing at home). We don't rubber stamp, we create separate cell instances for the visible area of the control, and reuse these exact same cells as the user scrolls. Therefore, if the visible area requires 20 cells, we may create ~22 cells, and as the user scrolls downwards we take the cells that disappear out the top of the view and place them at the bottom of the view, with their new content in place before it is shown on screen. Because all cells come from a single cell factory, and all cells can be used in any location, it is up to the cell to respond to the item placed into it and draw itself appropriately. Therefore, we don't have 1000's of types of cells in a single control, we only have one type of cell that needs to handle all the visual approaches required in the app. Realistically, there aren't 1000's of styles in a single control, normally there are only one, or two at most. All this takes place in the Cell.updateItem(T, boolean) method, and so people overriding this method need to be smart and not do heavy lifting in there. The biggest mistake I see people doing in updateItem(...) is throw away their entire cell scenegraph and recreate the nodes and update the scenegraph. This is unwise. If you have a ListView with 100 nodes, and they are all equally sized except for one (say the 50th), which is _significantly_ bigger, you will see the scrollbar jump in size and other weirdness happen when it is scrolled into view, precisely for the reason you state - we can't go off and measure every row as we'd be doing a lot of busy work. We only measure what is in the visual area, and we don't know where we are in the scroll range in terms of pixels but rather in terms of a 0.0 - 1.0 range (which is translated back to pixels when needed). Up to this point I've known about this issue but I've not spent the cycles to resolve it - it is a relatively rare use case (although it still happens). Priority #1 for these virtualised controls is always speed. If zooming were required on TableView, the implication (I presume) is that there would be that less cells that were visible at any one time, and so we would end up having less cells in the scenegraph. Other than that, things would work as above. In a past life I did a lot of work in Java 2D. This worked really well for use cases like you suggest at the end of your email, namely zooming and direct mouse manipulation of nodes on screen. If I were to write something like you show in the screenshot, I would be tempted to take a Canvas-based route nowadays, but of course that decision would also be driven by the requirements and use cases, and it is possible a scenegraph-based approach with absolute node positioning would work just as well. Hope that helps. -- Jonathan On 6/08/2013 12:38 p.m., Daniel Zwolenski wrote: > Sneaking in here, as you've given an opening with "if implemented > wisely, there is very little that a scenegraph-based approach can't > do". The question I've been asking for a while is what does > "implemented wisely" look like in JFX. > > This has come up in the performance conversations, the game > conversations, the CAD conversations, and many other places. No one > seems to have an answer, but you're building extremely complex stuff > on a regular basis - what's your tips? > > When you say you only have "20 visible nodes" out of 1000's in general > are the other nodes: > a) in the scenegraph and set to not visible > b) in memory but not in the scenegraph - added/removed when scrolled > into view and out of view > c) not in memory, created, added and then removed, destroyed when > scrolled into view and out of view > d) something else? > > I know Table uses a rubber stamp approach, where it re-uses cell views > where possible, but let's say every row in my 100,000 row Table was > uniquely rendered using a different cell. What would happen under the > covers? > > How do you work out the scroll range as well? Each cell can be a > unique height right? How do you know the extents of the vertical > scrolling without instantiating and rendering everything? Is this what > you do? What if a cell is changing size (has a collapsable pane in it, > etc) - what happens to the vertical scroll range? > > Do any of the controls have zooming on them? Have you had to deal with > this and have you got a strategy for handling this with respect to > scroll bounds, working out which nodes are in view, scaling fonts, > etc? Could you hazard a guess at what you would do if you had to > implement zooming on a Table for example? > > Maybe the Table is lucky with its restrictive grid like layout but > imagine you had to build a visualisation of the same data but in a > diagram, maybe something like > http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpg > but with x100 nodes, with zooming and panning - could you outline a > general strategy? > > > > > On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles > > wrote: > > I think it would pay to take a step back and understand why you > think a 'traditional' scenegraph-based (or retained mode) control > is not sufficient for your needs? > Unfortunately you've not detailed your use case, so it is hard to > give any specific advice. Are you able to give any details about > what it is you're trying to build and why you think the normal > approach to building controls is not sufficient? > > We've built some fairly complex controls using this approach, and > if implemented wisely, there is very little that a > scenegraph-based approach can't do. Specifically, do you think > your control will render all of the 'thousands of nodes' at once, > or will many of these nodes be off screen or otherwise not visible > at any one time? For things like the TableView we only render the > nodes that are visible. This means that regardless of whether > there are 100 or 1,000,000 rows of data, we only have visual nodes > for the 20 visible rows, for example. Keeping your scenegraph as > minimal as possible is always a very wise idea, if performance is > a concern. > > As you note, the other problem is that you will run into issues if > you want to mix canvas rendering with the scenegraph-based > controls like Button. The best you're likely to achieve (having > not tried it personally) is to position the control on top of the > canvas, rather than attempting to render the control inside the > canvas (and having to then deal with event handling, etc). This > will likely prove to be finicky, and more cumbersome than simply > using an entirely canvas-based or entirely scenegraph-based approach. > > -- Jonathan > > > On 5/08/2013 10:11 p.m., Felix Bembrick wrote: > > I am investigating the feasibility of developing a JavaFX 8 > control based > on Canvas. I have chosen Canvas as the base class as this > control is of a > very dynamic nature and would not be easy to implement with a > retained mode > style ancestor (at least as far as I can tell). > > So is this feasible? While I can readily see how to render > the visual > aspects of the control, I am not sure how to best "embed" > other controls > within it should that become necessary (and almost certainly > will). > > For example, how would I go about embedding a Button within my > control? It > looks to me like I would need to create an actual Button node > somewhere > else in the scenegraph and then perhaps render it within my > control using > gc.drawImage() passing in a snapshot of the Button node. > That's OK but > then I have to somehow handle events and I am not sure how > best to do that. > > Another issue I see is that there seems to be no way to apply > effects to > individual graphic elements within the Canvas as the > applyEffect() method > applies to the entire Canvas. > > Finally, a significant obstacle is this issue: > > https://javafx-jira.kenai.com/browse/RT-23822 > > This issue relates to the lack of support for LCD font > smoothing within > Canvas. This may not sound that serious but the difference > between LCD > font-smoothed text in other controls and the grey-scale text > in Canvas is > so distinct on my current machine that a control based on > Canvas would > really stick out like a sore thumb and appear significantly > less appealing > than a "standard" control. > > So, am I wasting my time? > Are there any other issues I am likely to face? > Are there other ways to develop dynamic controls which may involve > thousands of nodes (such as lines, curves etc.)? > > Thanks, > > Felix > > > From hang.vo at oracle.com Mon Aug 5 17:17:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 00:17:36 +0000 Subject: hg: openjfx/8/graphics/rt: Interim fix for rt-32116 - roll back changes from commit: Message-ID: <20130806001809.1D102485EE@hg.openjdk.java.net> Changeset: 3456bb1910d4 Author: Lisa.Selle at oracle.com Date: 2013-08-05 20:14 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3456bb1910d4 Interim fix for rt-32116 - roll back changes from commit: changeset: 4447:ff1219a1e652 parent: 4445:074b23ebf5f1 user: Martin Sladecek date: Mon Jul 29 13:33:12 2013 +0200 summary: RT-31919 ColorPicker, ArrayIndexOutOfBoundsException when saving custom color. which currently cause an NPE with a long press on virtual keyboard. See jira for details, this interim fix can be reverted when the bugs that 32116 depends on are fixed. ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/stub/java/javafx/scene/ParentTest.java From hang.vo at oracle.com Mon Aug 5 18:17:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 01:17:47 +0000 Subject: hg: openjfx/8/controls/rt: 6 new changesets Message-ID: <20130806011930.386C4485F2@hg.openjdk.java.net> Changeset: 5752e8bc7cb7 Author: jgiles Date: 2013-08-05 15:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5752e8bc7cb7 RT-19487: TableView: Support returning to unsorted state. For more information, I blogged about this feature here: http://fxexperience.com/2013/08/returning-a-tableview-back-to-an-unsorted-state-in-javafx-8-0/ ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java Changeset: 83a5c0ffd155 Author: jgiles Date: 2013-08-06 10:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/83a5c0ffd155 RT-30484: updateItem is not called at startup on virtualised controls, leading to invalid graphical states. ! 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/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.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: 905b63f0c057 Author: jgiles Date: 2013-08-06 10:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/905b63f0c057 RT-31907: Cleanup control code (part seven: generics cleanup for TableView / TreeTableView skin code) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.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/TreeTableViewSkin.java Changeset: 2a33523022aa Author: jgiles Date: 2013-08-06 11:30 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2a33523022aa RT-31907: Cleanup control code (part eight: Small TreeTableRow cleanup) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java Changeset: cecdbd12e168 Author: jgiles Date: 2013-08-06 11:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cecdbd12e168 RT-31907: Cleanup control code (part nine: Clean up generic warnings in TableRow) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TableRow.java Changeset: 3268003fe9c0 Author: jgiles Date: 2013-08-06 13:11 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3268003fe9c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java From zonski at gmail.com Mon Aug 5 19:06:37 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 6 Aug 2013 12:06:37 +1000 Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) In-Reply-To: <52004AB2.3050800@oracle.com> References: <52004AB2.3050800@oracle.com> Message-ID: Thanks Jonathan, it's good to get your insight. You did finish by muddying the waters again though - to do something complex with zooming and scrolling you'd "be tempted" to fall back into Java2D paint-style programming, and use Canvas for this, not the Scene graph? It's more a couldbe/maybe comment though and is in contrast to your earlier suggestion that there is very little that a scenegraph-based approach can't do. What's the trigger to switch from one approach to the other? Previously there have been comments about the Canvas not really being intended for highly dynamic stuff (that was my interpretation of comments on here when Canvas was first released), and Nodes should be used for most real things. Richard wanted to use Nodes in the TD game for sprites. To add to the confusion, Canvas currently has some drastic z-order bugs, and some clipping issues, so using it combined with Nodes is currently a no-go. I'm not expecting Jonathan to have an answer here really, just highlighting the fact that there is no clear answer on this. I'm still confused and I imagine many others are too. I think we'll see this question again. On Tue, Aug 6, 2013 at 11:00 AM, Jonathan Giles wrote: > I don't think there is any particular secret sauce going on in what I do > compared with the general guidelines that have been spelled out numerous > times. It's the same old, same old: don't create more nodes than you need, > don't modify the scenegraph needlessly, don't update the scenegraph > multiple times in a single pulse, change state as little as possible, use > as few listeners as possible, etc. I wish I had something more > groundbreaking for you, but that is about it :-) > > With respect to TableView (and ListView, TreeView, and TreeTableView), > they are all based on the same virtualisation code (VirtualFlow for those > of you playing at home). We don't rubber stamp, we create separate cell > instances for the visible area of the control, and reuse these exact same > cells as the user scrolls. Therefore, if the visible area requires 20 > cells, we may create ~22 cells, and as the user scrolls downwards we take > the cells that disappear out the top of the view and place them at the > bottom of the view, with their new content in place before it is shown on > screen. > > Because all cells come from a single cell factory, and all cells can be > used in any location, it is up to the cell to respond to the item placed > into it and draw itself appropriately. Therefore, we don't have 1000's of > types of cells in a single control, we only have one type of cell that > needs to handle all the visual approaches required in the app. > Realistically, there aren't 1000's of styles in a single control, normally > there are only one, or two at most. All this takes place in the > Cell.updateItem(T, boolean) method, and so people overriding this method > need to be smart and not do heavy lifting in there. The biggest mistake I > see people doing in updateItem(...) is throw away their entire cell > scenegraph and recreate the nodes and update the scenegraph. This is unwise. > > If you have a ListView with 100 nodes, and they are all equally sized > except for one (say the 50th), which is _significantly_ bigger, you will > see the scrollbar jump in size and other weirdness happen when it is > scrolled into view, precisely for the reason you state - we can't go off > and measure every row as we'd be doing a lot of busy work. We only measure > what is in the visual area, and we don't know where we are in the scroll > range in terms of pixels but rather in terms of a 0.0 - 1.0 range (which is > translated back to pixels when needed). Up to this point I've known about > this issue but I've not spent the cycles to resolve it - it is a relatively > rare use case (although it still happens). Priority #1 for these > virtualised controls is always speed. > > If zooming were required on TableView, the implication (I presume) is that > there would be that less cells that were visible at any one time, and so we > would end up having less cells in the scenegraph. Other than that, things > would work as above. > > In a past life I did a lot of work in Java 2D. This worked really well for > use cases like you suggest at the end of your email, namely zooming and > direct mouse manipulation of nodes on screen. If I were to write something > like you show in the screenshot, I would be tempted to take a Canvas-based > route nowadays, but of course that decision would also be driven by the > requirements and use cases, and it is possible a scenegraph-based approach > with absolute node positioning would work just as well. > > Hope that helps. > > -- Jonathan > > On 6/08/2013 12:38 p.m., Daniel Zwolenski wrote: > > Sneaking in here, as you've given an opening with "if implemented wisely, > there is very little that a scenegraph-based approach can't do". The > question I've been asking for a while is what does "implemented wisely" > look like in JFX. > > This has come up in the performance conversations, the game > conversations, the CAD conversations, and many other places. No one seems > to have an answer, but you're building extremely complex stuff on a regular > basis - what's your tips? > > When you say you only have "20 visible nodes" out of 1000's in general > are the other nodes: > a) in the scenegraph and set to not visible > b) in memory but not in the scenegraph - added/removed when scrolled into > view and out of view > c) not in memory, created, added and then removed, destroyed when scrolled > into view and out of view > d) something else? > > I know Table uses a rubber stamp approach, where it re-uses cell views > where possible, but let's say every row in my 100,000 row Table was > uniquely rendered using a different cell. What would happen under the > covers? > > How do you work out the scroll range as well? Each cell can be a unique > height right? How do you know the extents of the vertical scrolling without > instantiating and rendering everything? Is this what you do? What if a cell > is changing size (has a collapsable pane in it, etc) - what happens to the > vertical scroll range? > > Do any of the controls have zooming on them? Have you had to deal with > this and have you got a strategy for handling this with respect to scroll > bounds, working out which nodes are in view, scaling fonts, etc? Could you > hazard a guess at what you would do if you had to implement zooming on a > Table for example? > > Maybe the Table is lucky with its restrictive grid like layout but > imagine you had to build a visualisation of the same data but in a diagram, > maybe something like > http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general > strategy? > > > > > > On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles > wrote: > >> I think it would pay to take a step back and understand why you think a >> 'traditional' scenegraph-based (or retained mode) control is not sufficient >> for your needs? >> Unfortunately you've not detailed your use case, so it is hard to give >> any specific advice. Are you able to give any details about what it is >> you're trying to build and why you think the normal approach to building >> controls is not sufficient? >> >> We've built some fairly complex controls using this approach, and if >> implemented wisely, there is very little that a scenegraph-based approach >> can't do. Specifically, do you think your control will render all of the >> 'thousands of nodes' at once, or will many of these nodes be off screen or >> otherwise not visible at any one time? For things like the TableView we >> only render the nodes that are visible. This means that regardless of >> whether there are 100 or 1,000,000 rows of data, we only have visual nodes >> for the 20 visible rows, for example. Keeping your scenegraph as minimal as >> possible is always a very wise idea, if performance is a concern. >> >> As you note, the other problem is that you will run into issues if you >> want to mix canvas rendering with the scenegraph-based controls like >> Button. The best you're likely to achieve (having not tried it personally) >> is to position the control on top of the canvas, rather than attempting to >> render the control inside the canvas (and having to then deal with event >> handling, etc). This will likely prove to be finicky, and more cumbersome >> than simply using an entirely canvas-based or entirely scenegraph-based >> approach. >> >> -- Jonathan >> >> >> On 5/08/2013 10:11 p.m., Felix Bembrick wrote: >> >>> I am investigating the feasibility of developing a JavaFX 8 control based >>> on Canvas. I have chosen Canvas as the base class as this control is of >>> a >>> very dynamic nature and would not be easy to implement with a retained >>> mode >>> style ancestor (at least as far as I can tell). >>> >>> So is this feasible? While I can readily see how to render the visual >>> aspects of the control, I am not sure how to best "embed" other controls >>> within it should that become necessary (and almost certainly will). >>> >>> For example, how would I go about embedding a Button within my control? >>> It >>> looks to me like I would need to create an actual Button node somewhere >>> else in the scenegraph and then perhaps render it within my control using >>> gc.drawImage() passing in a snapshot of the Button node. That's OK but >>> then I have to somehow handle events and I am not sure how best to do >>> that. >>> >>> Another issue I see is that there seems to be no way to apply effects to >>> individual graphic elements within the Canvas as the applyEffect() method >>> applies to the entire Canvas. >>> >>> Finally, a significant obstacle is this issue: >>> >>> https://javafx-jira.kenai.com/browse/RT-23822 >>> >>> This issue relates to the lack of support for LCD font smoothing within >>> Canvas. This may not sound that serious but the difference between LCD >>> font-smoothed text in other controls and the grey-scale text in Canvas is >>> so distinct on my current machine that a control based on Canvas would >>> really stick out like a sore thumb and appear significantly less >>> appealing >>> than a "standard" control. >>> >>> So, am I wasting my time? >>> Are there any other issues I am likely to face? >>> Are there other ways to develop dynamic controls which may involve >>> thousands of nodes (such as lines, curves etc.)? >>> >>> Thanks, >>> >>> Felix >>> >> >> > > From jonathan.giles at oracle.com Mon Aug 5 19:19:47 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 06 Aug 2013 14:19:47 +1200 Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) In-Reply-To: References: <52004AB2.3050800@oracle.com> Message-ID: <52005D43.80009@oracle.com> I only said that I'd consider using Canvas given my past experiences in doing the same kind of thing in Java 2D, so I'm familiar with it in that sense (but not in the real sense of having ever used Canvas in production). If I were to ever implement something like this I would of course be informed by experimentation and investigation. The other reason for my answer is that in reality I see them both as much the same thing, given I spend most of my time writing custom layout code anyway. This is what I said right at the end of my email: if you're doing absolute node positioning in the scenegraph you're most of the way to doing canvas stuff anyway, so I see them as relatively interchangeable. Perhaps that is a naive point of view and the canvas experts will correct me though. I don't think it is worth being confused over. I think the general advice is quite clear, and the repercussions of either approach is quite well understood. When professionally evaluating which approach to take you should always be driven by use cases and experimentation. If you need a really clear answer on how to always proceed, my (once again naive and subjective) suggestion is this: always use scenegraph - if that doesn't work, consider canvas. Of course, I welcome the canvas experts to chime in and correct me. I'm not an authority here and so everything should be taken with the appropriate amount of salt. -- Jonathan On 6/08/2013 2:06 p.m., Daniel Zwolenski wrote: > Thanks Jonathan, it's good to get your insight. > > You did finish by muddying the waters again though - to do something > complex with zooming and scrolling you'd "be tempted" to fall back > into Java2D paint-style programming, and use Canvas for this, not the > Scene graph? It's more a couldbe/maybe comment though and is in > contrast to your earlier suggestion that there is very little that a > scenegraph-based approach can't do. What's the trigger to switch from > one approach to the other? > > Previously there have been comments about the Canvas not really being > intended for highly dynamic stuff (that was my interpretation of > comments on here when Canvas was first released), and Nodes should be > used for most real things. Richard wanted to use Nodes in the TD game > for sprites. To add to the confusion, Canvas currently has some > drastic z-order bugs, and some clipping issues, so using it combined > with Nodes is currently a no-go. > > I'm not expecting Jonathan to have an answer here really, just > highlighting the fact that there is no clear answer on this. I'm still > confused and I imagine many others are too. I think we'll see this > question again. > > > On Tue, Aug 6, 2013 at 11:00 AM, Jonathan Giles > > wrote: > > I don't think there is any particular secret sauce going on in > what I do compared with the general guidelines that have been > spelled out numerous times. It's the same old, same old: don't > create more nodes than you need, don't modify the scenegraph > needlessly, don't update the scenegraph multiple times in a single > pulse, change state as little as possible, use as few listeners as > possible, etc. I wish I had something more groundbreaking for you, > but that is about it :-) > > With respect to TableView (and ListView, TreeView, and > TreeTableView), they are all based on the same virtualisation code > (VirtualFlow for those of you playing at home). We don't rubber > stamp, we create separate cell instances for the visible area of > the control, and reuse these exact same cells as the user scrolls. > Therefore, if the visible area requires 20 cells, we may create > ~22 cells, and as the user scrolls downwards we take the cells > that disappear out the top of the view and place them at the > bottom of the view, with their new content in place before it is > shown on screen. > > Because all cells come from a single cell factory, and all cells > can be used in any location, it is up to the cell to respond to > the item placed into it and draw itself appropriately. Therefore, > we don't have 1000's of types of cells in a single control, we > only have one type of cell that needs to handle all the visual > approaches required in the app. Realistically, there aren't 1000's > of styles in a single control, normally there are only one, or two > at most. All this takes place in the Cell.updateItem(T, boolean) > method, and so people overriding this method need to be smart and > not do heavy lifting in there. The biggest mistake I see people > doing in updateItem(...) is throw away their entire cell > scenegraph and recreate the nodes and update the scenegraph. This > is unwise. > > If you have a ListView with 100 nodes, and they are all equally > sized except for one (say the 50th), which is _significantly_ > bigger, you will see the scrollbar jump in size and other > weirdness happen when it is scrolled into view, precisely for the > reason you state - we can't go off and measure every row as we'd > be doing a lot of busy work. We only measure what is in the visual > area, and we don't know where we are in the scroll range in terms > of pixels but rather in terms of a 0.0 - 1.0 range (which is > translated back to pixels when needed). Up to this point I've > known about this issue but I've not spent the cycles to resolve it > - it is a relatively rare use case (although it still happens). > Priority #1 for these virtualised controls is always speed. > > If zooming were required on TableView, the implication (I presume) > is that there would be that less cells that were visible at any > one time, and so we would end up having less cells in the > scenegraph. Other than that, things would work as above. > > In a past life I did a lot of work in Java 2D. This worked really > well for use cases like you suggest at the end of your email, > namely zooming and direct mouse manipulation of nodes on screen. > If I were to write something like you show in the screenshot, I > would be tempted to take a Canvas-based route nowadays, but of > course that decision would also be driven by the requirements and > use cases, and it is possible a scenegraph-based approach with > absolute node positioning would work just as well. > > Hope that helps. > > -- Jonathan > > On 6/08/2013 12:38 p.m., Daniel Zwolenski wrote: >> Sneaking in here, as you've given an opening with "if implemented >> wisely, there is very little that a scenegraph-based approach >> can't do". The question I've been asking for a while is what does >> "implemented wisely" look like in JFX. >> >> This has come up in the performance conversations, the game >> conversations, the CAD conversations, and many other places. No >> one seems to have an answer, but you're building extremely >> complex stuff on a regular basis - what's your tips? >> >> When you say you only have "20 visible nodes" out of 1000's in >> general are the other nodes: >> a) in the scenegraph and set to not visible >> b) in memory but not in the scenegraph - added/removed when >> scrolled into view and out of view >> c) not in memory, created, added and then removed, destroyed when >> scrolled into view and out of view >> d) something else? >> >> I know Table uses a rubber stamp approach, where it re-uses cell >> views where possible, but let's say every row in my 100,000 row >> Table was uniquely rendered using a different cell. What would >> happen under the covers? >> >> How do you work out the scroll range as well? Each cell can be a >> unique height right? How do you know the extents of the vertical >> scrolling without instantiating and rendering everything? Is this >> what you do? What if a cell is changing size (has a collapsable >> pane in it, etc) - what happens to the vertical scroll range? >> >> Do any of the controls have zooming on them? Have you had to deal >> with this and have you got a strategy for handling this with >> respect to scroll bounds, working out which nodes are in view, >> scaling fonts, etc? Could you hazard a guess at what you would do >> if you had to implement zooming on a Table for example? >> >> Maybe the Table is lucky with its restrictive grid like layout >> but imagine you had to build a visualisation of the same data but >> in a diagram, maybe something like >> http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpg >> but with x100 nodes, with zooming and panning - could you outline >> a general strategy? >> >> >> >> >> On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles >> > wrote: >> >> I think it would pay to take a step back and understand why >> you think a 'traditional' scenegraph-based (or retained mode) >> control is not sufficient for your needs? >> Unfortunately you've not detailed your use case, so it is >> hard to give any specific advice. Are you able to give any >> details about what it is you're trying to build and why you >> think the normal approach to building controls is not sufficient? >> >> We've built some fairly complex controls using this approach, >> and if implemented wisely, there is very little that a >> scenegraph-based approach can't do. Specifically, do you >> think your control will render all of the 'thousands of >> nodes' at once, or will many of these nodes be off screen or >> otherwise not visible at any one time? For things like the >> TableView we only render the nodes that are visible. This >> means that regardless of whether there are 100 or 1,000,000 >> rows of data, we only have visual nodes for the 20 visible >> rows, for example. Keeping your scenegraph as minimal as >> possible is always a very wise idea, if performance is a concern. >> >> As you note, the other problem is that you will run into >> issues if you want to mix canvas rendering with the >> scenegraph-based controls like Button. The best you're likely >> to achieve (having not tried it personally) is to position >> the control on top of the canvas, rather than attempting to >> render the control inside the canvas (and having to then deal >> with event handling, etc). This will likely prove to be >> finicky, and more cumbersome than simply using an entirely >> canvas-based or entirely scenegraph-based approach. >> >> -- Jonathan >> >> >> On 5/08/2013 10:11 p.m., Felix Bembrick wrote: >> >> I am investigating the feasibility of developing a JavaFX >> 8 control based >> on Canvas. I have chosen Canvas as the base class as >> this control is of a >> very dynamic nature and would not be easy to implement >> with a retained mode >> style ancestor (at least as far as I can tell). >> >> So is this feasible? While I can readily see how to >> render the visual >> aspects of the control, I am not sure how to best "embed" >> other controls >> within it should that become necessary (and almost >> certainly will). >> >> For example, how would I go about embedding a Button >> within my control? It >> looks to me like I would need to create an actual Button >> node somewhere >> else in the scenegraph and then perhaps render it within >> my control using >> gc.drawImage() passing in a snapshot of the Button node. >> That's OK but >> then I have to somehow handle events and I am not sure >> how best to do that. >> >> Another issue I see is that there seems to be no way to >> apply effects to >> individual graphic elements within the Canvas as the >> applyEffect() method >> applies to the entire Canvas. >> >> Finally, a significant obstacle is this issue: >> >> https://javafx-jira.kenai.com/browse/RT-23822 >> >> This issue relates to the lack of support for LCD font >> smoothing within >> Canvas. This may not sound that serious but the >> difference between LCD >> font-smoothed text in other controls and the grey-scale >> text in Canvas is >> so distinct on my current machine that a control based on >> Canvas would >> really stick out like a sore thumb and appear >> significantly less appealing >> than a "standard" control. >> >> So, am I wasting my time? >> Are there any other issues I am likely to face? >> Are there other ways to develop dynamic controls which >> may involve >> thousands of nodes (such as lines, curves etc.)? >> >> Thanks, >> >> Felix >> >> >> > > From chien.yang at oracle.com Mon Aug 5 19:27:35 2013 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 05 Aug 2013 19:27:35 -0700 Subject: Mixing 2D and 3D In-Reply-To: <51FF81FC.6090706@oracle.com> References: <51F96C32.9060500@oracle.com> <34B1E065-76C0-4E7D-A54A-586D0FE26D2C@oracle.com> <51FF81FC.6090706@oracle.com> Message-ID: <52005F17.8020701@oracle.com> Hi Jim, We worked closely with Pavel to ensure 3D picking did extend nicely. I believe the specification at this link is still up-to-date: https://wiki.openjdk.java.net/display/OpenJFX/Picking3dAPI - Chien On 8/5/2013 3:44 AM, Pavel Safrata wrote: > On 1.8.2013 22:33, Richard Bair wrote: >>> How does that fit in with the 2D-ish picking events we deliver now? >>> If a cylinder is picked, how do we describe which part of the >>> cylinder was picked? >> Pavel or Chien will have to pipe in on this part of the question, I >> don't know. >> > > Similar to 2D, the delivered event has coordinates in the cylinder's > local coordinate space, so getX(), getY(), getZ() tell you the > intersection point of the pick ray cast to the scene by cursor > position and the cylinder. Moreover, the events have getPickResult() > from which you can obtain also distance from camera, picked face (not > used for cylinder but identifies picked triangle for a mesh) and > texture coordinates. > > Pavel From richard.bair at oracle.com Mon Aug 5 21:16:42 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 21:16:42 -0700 Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) In-Reply-To: References: <52004AB2.3050800@oracle.com> Message-ID: <0B1BEB6D-7FD1-4894-ADBC-26C13D63217D@oracle.com> > To add > to the confusion, Canvas currently has some drastic z-order bugs, and some > clipping issues, so using it combined with Nodes is currently a no-go. I believe those have all been fixed in the last couple of weeks. Richard From Richard.Bair at oracle.com Mon Aug 5 21:19:02 2013 From: Richard.Bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 21:19:02 -0700 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> Message-ID: <2CE8AFBF-F7FD-493C-BF4A-75CD64F4F367@oracle.com> Here is another one on the Oracle page: http://www.oracle.com/technetwork/java/javafx/codelse-1984189.html Richard On Aug 4, 2013, at 6:15 AM, Sven Reimers wrote: > Hi, > > from my perspective a showcase list saying technology X is used by the top ten largest engineering companies is always very nice to convince people they are not basing a long term project/product on an used, not widespread technology. > > So for me building a showcase page is a key thing for helping in the decision making process. > > -Sven > > > On Sun, Aug 4, 2013 at 10:12 AM, Johan Vos wrote: > Hi, > > I agree such an overview page would definitely help, but the go/no-go > decisions I often see have less to do with convincing customers about > JavaFX being the right technology. Customers have a number of requirements, > and if I can tell them JavaFX is capable of doing that, they trust me (and > they will blame me when I'm wrong). > > The key bummer I've seen so far is (yet again) wide deployment. "It should > run on tablets" and "Our Customers should be able to use [install] this > very easily". > I am very much aware of the progress being made in both areas, so I'm not > complaining at all -- but there is a lot of work to be done. > Just want to set expectations right: a cool overview of what is already > achieved with JavaFX is not going to convince all potential customers -- in > my experience the deployment is still the major reasons why a number of > companies are not in favor of JavaFX yet. > > - Johan > > > > 2013/8/4 Anton Epple > > > A combination of a page describing an individual application, like the one > > you linked here, would be one part and -more important- a page that lists > > *all* the applications with a screenshot and a short description. The > > latter would be important, because it's a showcase for decision makers who > > are yet undecided if JavaFX is the right technology. > > > > Before that page existed for NB Platform, I had the same discussions I now > > have for potential JavaFX projects. Developers are in doubt if the > > technology is mature/performant/secure/whatever enough for their > > large/unique/graphically demanding/etc. project. After they see the page, > > they're convinced that it can be done. > > > > It's especially useful if you need to convince a team. Typically there's > > at least one person in favor of a different technology (for JavaFX it's > > typically GWT) and such a page is a great FUD-killer. > > > > Am 01.08.2013 um 22:40 schrieb Richard Bair : > > > > > Something I guess would go on such a page? > > > > > > http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ > > > > > > On Aug 1, 2013, at 3:21 AM, Anton Epple wrote: > > > > > >> Great idea, there's a site that does the same for NetBeans Platform > > Apps: > > >> > > >> https://platform.netbeans.org/screenshots.html > > >> > > >> I can tell from my own experience that it helps a lot in discussions > > with customers to show them that NASA, NATO, Boeing, UNO, US Army, and many > > others are building on top of NB Platform. > > >> > > >> From the maintainer of this site, I know there's a lot of work involved > > though, and you have to be very active in identifying users, and reaching > > out to them. It's definitely not sufficient to wait for users to submit > > their applications. Sometimes it can take a couple of years from first > > contact to a screenshot. That said it's absolutely worth it, and I would > > volunteer to help in any way I can. > > >> > > >> Toni > > >> > > >> -- > > >> Anton Epple > > >> > > >> > > >> > > >> Am 28.07.2013 um 02:38 schrieb Jonathan Giles < > > jonathan.giles at oracle.com>: > > >> > > >>> This is something that Jasper actually brought up just this morning > > with Richard and I (wrt fxexperience hosting it). I suspect we may get > > something underway in the coming weeks. Of course, it depends on the > > community getting in touch with us and letting us talk about them - so much > > of the JavaFX world is behind corporate firewalls, where talking about your > > work is generally frowned upon. In any case, for those of you that can talk > > about your work, please email one of us off-list. > > >>> -- Jonathan > > >>> Sent from a touch device. Please excuse my brevity. > > >>> > > >>> "John C. Turnbull" wrote: > > >>>> +1 > > >>>> > > >>>> Such a site could be very useful. > > >>>> > > >>>> -----Original Message----- > > >>>> From: openjfx-dev-bounces at openjdk.java.net > > >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel > > >>>> Zwolenski > > >>>> Sent: Sunday, 28 July 2013 09:56 > > >>>> To: Pedro Duque Vieira > > >>>> Cc: OpenJFX Mailing List > > >>>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) > > >>>> > > >>>> The idea of a JFX Sightings page (in the tradition of the Swing > > >>>> Sightings > > >>>> page) has been raised before and I think is a good one. > > >>>> > > >>>> It deserves it's own page though, that technet section isn't up to it > > >>>> in my > > >>>> opinion. > > >>>> > > >>>> Personally I think this would be great under the fxexperience site as > > >>>> it > > >>>> partners nicely with the links of the week? > > >>>> > > >>>> > > >>>> > > >>>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira > > >>>> > > >>>> wrote: > > >>>> > > >>>>> I have an Swing/JavaFX app, the site is: http://modellus.co > > >>>>> > > >>>>> How can I get it to be on that real world usecases section? Or does > > >>>> it > > >>>>> not have the necessary requirements to be in it? > > >>>>> > > >>>>> Thanks, best regards, > > >>>>> > > >>>>> @John: On the JavaFx community site they have a section with > > >>>>> references to > > >>>>>> real world usecases. > > >>>>>> http://www.oracle.com/technetwork/java/javafx/community/index.html > > >>>>>> > > >>>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull > > >>>>>> > >>>>>>> wrote: > > >>>>>>> Like Daniel said, none of what we say is in any way a criticism of > > >>>>>>> the JavaFX development team who, in my view and that of the entire > > >>>>>>> community, are doing an awesome job. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> For mine, all the shortcomings of JavaFX (perceived or actual) can > > >>>>>>> be > > >>>>>> blown > > >>>>>>> away if I could just demonstrate what JavaFX is really capable of. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras (whose > > >>>>>>> demo incidentally doesn't run since Java 7 Update 21). With Oracle > > >>>> > > >>>>>>> Ensemble > > >>>>>> we > > >>>>>>> can see that JavaFX has quite a nice set of basic controls and that > > >>>> > > >>>>>>> it at least supports very simple animations. With JFXtras Ensemble > > >>>> > > >>>>>>> we can see that very nice controls are possible but unfortunately > > >>>>>>> many of these are > > >>>>>> of > > >>>>>>> a rather "whimsical" nature and not the kind of control you would > > >>>>>>> use in everyday business apps. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> What else is there? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Of course we have rock stars like Gerrit Grunwald who frequently > > >>>>>>> post awesome controls and code snippets but we really need > > >>>> something > > >>>>>>> that > > >>>>>> brings > > >>>>>>> it altogether in a kick-arse showcase. Preferably a whole suite of > > >>>>>> killer > > >>>>>>> apps that highlights everything JavaFX is capable of. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Yes, that would require a lot of effort but IMHO it is absolutely > > >>>>>>> worth > > >>>>>> it. > > >>>>>>> Without it, people like me really struggle to sell JavaFX or even > > >>>>>>> get a handle on its true potential. I can promise people that more > > >>>> > > >>>>>>> advanced things are "possible" but given that they write the > > >>>>>>> cheques, they need to see it for themselves. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> And how about a website of JavaFX reference sites? There must be > > >>>>>>> big companies out there using it right? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> In the end it doesn't matter if I personally see enormous potential > > >>>> > > >>>>>>> for JavaFX if I cannot convince others to see what I see. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -jct > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] > > >>>>>>> Sent: Saturday, 27 July 2013 09:12 > > >>>>>>> To: John C. Turnbull > > >>>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net > > >>>>>>> Subject: Re: Can JavaFX do CAD? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> +1 > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> I've failed to convince multiple clients that they should use JFX > > >>>>>>> because of > > >>>>>>> > > >>>>>>> > > >>>>>>> a) lack of examples of what it can really do, and how to make it do > > >>>> > > >>>>>>> that (e.g. in enterprise space we have > > >>>>>>> http://static.springsource.org/docs/petclinic.html) > > >>>>>>> > > >>>>>>> b) lack of any big or notable players out there actually using it, > > >>>>>>> or at least publicly saying they are using it > > >>>>>>> > > >>>>>>> c) the deployment hassles vs the ease of html app deployment and > > >>>> the > > >>>>>>> true cross-platform-ness of html > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> After actually getting one client to trust me on it and use it on a > > >>>> > > >>>>>>> real, commercial app (startup), I hit problems with performance > > >>>>>>> (broad interpretation of the term, not 'framerate'), crippling > > >>>>>>> deployment and > > >>>>>> auto > > >>>>>>> updating issues, missing basic features (e.g. maximise button, > > >>>>>>> coming in > > >>>>>>> 2014 I believe?), unpredictability of CSS styling, and a lack of > > >>>>>>> best practices for things like how to do CAD-like diagrams (not so > > >>>>>>> much render performance but zooming, panning, mouse input, > > >>>> layering, > > >>>> dragging, etc). > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Like John, I've been guilty of letting my frustration show in these > > >>>>>> forums. > > >>>>>>> Like John, it's because I want so badly for JavaFX to be the > > >>>>>>> platform I develop on, it has the potential to be awesome, but > > >>>>>>> things (that seem obvious and small to me) completely stop it from > > >>>>>>> being usable in a real world situation for me. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> It's not that we think the JFX team aren't slogging their guts out, > > >>>>>> clearly > > >>>>>>> you are. It's just that in some key areas, there are small-ish > > >>>>>>> blocks > > >>>>>> that > > >>>>>>> stop the whole rocket from launching. To then see a whole lot of > > >>>>>>> effort > > >>>>>> be > > >>>>>>> poured into things like binary CSS/FXML compilation, Pi platform > > >>>>>>> support (that's more important than iOS/Android, really?), web > > >>>>>>> deployment > > >>>>>> patches, > > >>>>>>> or even 3D (as cool as that is), just knocks me about. Obviously > > >>>>>>> your priorities are coming from somewhere different to ours, but > > >>>> the > > >>>>>>> way you prioritise is unfathomable to me and that definitely adds > > >>>> to > > >>>>>>> the frustration. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> At this stage, I am not suggesting my clients use JFX (I actively > > >>>>>>> discourage them from it, in their interest). Mobile is the area > > >>>> that > > >>>>>>> has the > > >>>>>> potential > > >>>>>>> to bring JFX back into usable for me as it can compete easier with > > >>>>>>> the current technologies (which are all crap). Maybe if that ends > > >>>> up > > >>>>>>> working > > >>>>>> (a > > >>>>>>> long, long road to go on that and very much an 'if') then it will > > >>>>>>> seep > > >>>>>> back > > >>>>>>> into the desktop for me, but at a minimum the desktop deployment > > >>>>>>> options will need to be improved before that's even a possibility. > > >>>>>>> > > >>>>>>> > > >>>>>>> I've come to accept that I am not in the primary target audience > > >>>> for > > >>>>>>> JavaFX, maybe a secondary target. I don't understand who the > > >>>> primary > > >>>>>>> target is though, and knowing/accepting doesn't make it any less > > >>>>>>> frustrating. I > > >>>>>> keep > > >>>>>>> involved in the hope that I might get a usable platform somewhere > > >>>>>>> along > > >>>>>> the > > >>>>>>> way but it's more of a hope than a belief. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> So nothing really new above, but just adding my voice to John's. > > >>>>>>> JavaFX > > >>>>>> is > > >>>>>>> definitely not production ready for me, my clients and the types of > > >>>> > > >>>>>>> apps > > >>>>>> I > > >>>>>>> build (e.g. consumer facing online systems, enterprise/backoffice > > >>>>>> systems, > > >>>>>>> form/data systems, diagramming systems). One day I hope it will be, > > >>>> > > >>>>>>> but it's moving extremely slowly or not at all in the areas that > > >>>>>>> would make it so for me. Meanwhile the competitors (primarily > > >>>>>>> JavaScript based solutions) are improving rapidly in the areas > > >>>> where > > >>>>>>> they have traditionally been weak. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < > > >>>>>> ozemale at ozemail.com.au > > >>>>>>> > wrote: > > >>>>>>> > > >>>>>>> Hi Richard, > > >>>>>>> > > >>>>>>> I have to stop posting late at night, that one came across as > > >>>> really > > >>>>>> ANGRY! > > >>>>>>> > > >>>>>>> It's not anger, it's passion... and frustration. > > >>>>>>> > > >>>>>>> I am frustrated because I spend much of my day trying to convince > > >>>> my > > >>>>>>> employer that we should be using JavaFX. They ask me questions > > >>>> like: > > >>>>>>> > > >>>>>>> "What happens if Oracle abandons JavaFX just like Sun did with JMF, > > >>>>>> Java3D, > > >>>>>>> JOGL etc. ?" > > >>>>>>> > > >>>>>>> I say: > > >>>>>>> > > >>>>>>> "This is Oracle, not Sun." > > >>>>>>> > > >>>>>>> They say: > > >>>>>>> > > >>>>>>> "Can you show me what JavaFX can do? There must be examples out > > >>>>>>> there right?" > > >>>>>>> > > >>>>>>> And I say: > > >>>>>>> > > >>>>>>> "Sure, here's Ensemble." > > >>>>>>> > > >>>>>>> They say: > > >>>>>>> > > >>>>>>> "OK, so it has a nice set of basic controls and can do simple > > >>>>>>> animations but what about more complex things like Flash?" > > >>>>>>> > > >>>>>>> ...hence the dancing cat reference. > > >>>>>>> > > >>>>>>> It's not that my employer *needs* dancing cats, it's just that they > > >>>> > > >>>>>>> need > > >>>>>> to > > >>>>>>> see that there is more to JavaFX than red circle transitions. I > > >>>>>>> can't > > >>>>>> even > > >>>>>>> prove to them that JavaFX is capable of dancing cats. They don't > > >>>>>>> have > > >>>>>> the > > >>>>>>> resources to fund me to develop something more sophisticated but > > >>>>>>> they > > >>>>>> tell > > >>>>>>> me that if JavaFX truly was a "mature" technology (like I tell > > >>>> them) > > >>>>>>> then where are all the examples? > > >>>>>>> > > >>>>>>> I am finding it difficult to convince them that JavaFX is > > >>>> production > > >>>>>> ready > > >>>>>>> and is not still in "experimental" mode because I am unable to > > >>>>>> demonstrate > > >>>>>>> its true capabilities or refer them to many examples of people (and > > >>>> > > >>>>>>> I > > >>>>>> mean > > >>>>>>> big companies) actually using it. > > >>>>>>> > > >>>>>>> The main concerns of my employer and I think many companies in a > > >>>>>>> similar situation is that JavaFX won't survive long term and that > > >>>> it > > >>>>>>> is only > > >>>>>> really > > >>>>>>> suitable for form based applications. Then of course there is the > > >>>>>>> whole > > >>>>>>> "HTML5 runs on all platforms" argument but that's another story... > > >>>>>>> > > >>>>>>> So this is why I think it's imperative that Oracle invests in > > >>>>>>> developing > > >>>>>> a > > >>>>>>> true showcase application for JavaFX. Something that non-technical > > >>>>>> people > > >>>>>>> (like managers who make decisions about where the money goes) can > > >>>>>>> look at it and go "wow!". > > >>>>>>> > > >>>>>>> I am just not getting my managers to go "wow" at what I can show > > >>>>>>> them > > >>>>>> with > > >>>>>>> JavaFX at the moment. > > >>>>>>> > > >>>>>>> Every comment or apparent criticism I post about JavaFX is from the > > >>>> > > >>>>>>> perspective that I am trying to deal with real-world problems and > > >>>>>>> people who require proof (such as demos, reference sites etc.) and > > >>>>>>> not because I myself think JavaFX is not up to scratch. > > >>>>>>> > > >>>>>>> It's quite the opposite actually. > > >>>>>>> > > >>>>>>> I am a very, very strong believer and supporter of JavaFX and have > > >>>>>>> many reasons both personal and professional as to why I want it to > > >>>>>>> be a > > >>>>>> massive > > >>>>>>> success. As I have said before, there are plenty of people who > > >>>>>>> praise JavaFX and tend to avoid the very real issues that are > > >>>>>>> restricting its adoption. I just think we have to face these > > >>>> issues > > >>>>>>> head on if we are to compete in what is a very cut-throat industry. > > >>>>>>> > > >>>>>>> -jct > > >>>>>>> > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Richard Bair [mailto:richard.bair at oracle.com > > >>>>>>> ] > > >>>>>>> Sent: Saturday, 27 July 2013 01:40 > > >>>>>>> To: John C. Turnbull > > >>>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net > > >>>>>>> > > >>>>>>> Subject: Re: Can JavaFX do CAD? > > >>>>>>> > > >>>>>>>> For Flash, there are literally millions of examples of > > >>>>>>>> fancy/complex/impressive graphics and animations out there that > > >>>> can > > >>>>>>>> be really impressive at times. I have not seen ONE such example > > >>>> in > > >>>>>> JavaFX! > > >>>>>>> > > >>>>>>> Point to one? > > >>>>>>> > > >>>>>>> Have you seen any of the JavaOne examples? The movie wall or movies > > >>>> > > >>>>>>> on a stack of 3D cubes was pretty good. But I guess you're not > > >>>>>>> interested in > > >>>>>> the > > >>>>>>> 3D aspect? What is it you are looking for exactly? Different people > > >>>> > > >>>>>>> (on this > > >>>>>>> list) have had different perceptions on both (a) what's important > > >>>>>>> and (b) what kind of graphics they're interested in. Most people > > >>>>>>> would deride the dancing cat as being totally irrelevant to the > > >>>>>>> types of applications they're trying to build (the basis for much > > >>>> of > > >>>>>>> flash animations is shape > > >>>>>> morphing, > > >>>>>>> you can find some code here > > >>>> https://gist.github.com/gontard/5029764). > > >>>>>>> > > >>>>>>> On the other hand, JavaFX is not a replacement for OpenGL. Drawing > > >>>>>>> 25 million lines is just not something we can do right now, > > >>>>>>> especially in a resource constrained environment. I've already > > >>>>>>> commented on the memory overhead (which would continue to be an > > >>>>>>> issue even if the drawing part of the problem were solved). > > >>>>>>> > > >>>>>>> I've pushed to graphics repo the StretchyGrid, which is about 300k > > >>>>>>> line nodes (the actual amount is variable, see the javadoc > > >>>>>>> comments). At 300k nodes the scene graph overhead is negligible on > > >>>>>>> the FX side, dirty opts > > >>>>>> is > > >>>>>>> taking a long time to run, and painting is really slow. > > >>>>>>> > > >>>>>>> PULSE: 347 [122ms:222ms] > > >>>>>>> T12 (8 +0ms): CSS Pass > > >>>>>>> T12 (8 +0ms): Layout Pass > > >>>>>>> T12 (47 +53ms): Waiting for previous rendering > > >>>>>>> T12 (100 +1ms): Copy state to render graph > > >>>>>>> T10 (101 +16ms): Dirty Opts Computed > > >>>>>>> T10 (117 +105ms): Painted > > >>>>>>> Counters: > > >>>>>>> Nodes rendered: 306565 > > >>>>>>> Nodes visited during render: 306565 > > >>>>>>> > > >>>>>>> If I were doing this by hand in open GL, I think the drawing would > > >>>>>>> be essentially free, if I used LINES with GL anti-aliasing, I could > > >>>> > > >>>>>>> send 'em all down to the card in a single shot (and if I had a > > >>>>>>> modern GL I could > > >>>>>> do > > >>>>>>> LINES + FXAA or one of the other per-pixel AA algorithms available > > >>>>>>> and it would turn out pretty nice). Because our shapes don't > > >>>>>>> implement the > > >>>>>> non-AA > > >>>>>>> path, and our AA involves software rasterization and uploading of > > >>>>>> pixels, I > > >>>>>>> expect that to be the main source of the 105ms time being spent > > >>>> here. > > >>>>>>> > > >>>>>>> Also I noticed (by turning on prism.showdirty=true) that the entire > > >>>> > > >>>>>>> grid > > >>>>>> is > > >>>>>>> being painted every time, even though visually it looks like only a > > >>>> > > >>>>>>> small subset actually needs to be changed. But that's really a > > >>>> minor > > >>>>>>> thing, as > > >>>>>> I > > >>>>>>> said, drawing this many lines should basically be free if I > > >>>>>>> configure "smooth" to false in the app. Except that right now it is > > >>>> > > >>>>>>> totally not implemented (in NGShape): > > >>>>>>> > > >>>>>>> public void setAntialiased(boolean aa) { > > >>>>>>> // We don't support aliased shapes at this time > > >>>>>>> } > > >>>>>>> > > >>>>>>> The point of stretchy grid is not to say "wow look at this amazing > > >>>> demo". > > >>>>>>> The point is to say "what happens if I put in 300K nodes. Where > > >>>> does > > >>>>>>> the system start to fall over?". > > >>>>>>> > > >>>>>>> Richard= > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> Pedro Duque Vieira > > >> > > > > > > > > > > > -- > 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 zonski at gmail.com Mon Aug 5 21:24:35 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 6 Aug 2013 14:24:35 +1000 Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) In-Reply-To: <0B1BEB6D-7FD1-4894-ADBC-26C13D63217D@oracle.com> References: <52004AB2.3050800@oracle.com> <0B1BEB6D-7FD1-4894-ADBC-26C13D63217D@oracle.com> Message-ID: You should be able to check out they work in your TD game and continue development on that then. On Tue, Aug 6, 2013 at 2:16 PM, Richard Bair wrote: > > To add > > to the confusion, Canvas currently has some drastic z-order bugs, and > some > > clipping issues, so using it combined with Nodes is currently a no-go. > > I believe those have all been fixed in the last couple of weeks. > > Richard > From richard.bair at oracle.com Mon Aug 5 22:02:03 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 5 Aug 2013 22:02:03 -0700 Subject: TD game (hijacking Re: Performant Controls (hijacking Re: Developing controls based on Canvas?)) In-Reply-To: References: <52004AB2.3050800@oracle.com> <0B1BEB6D-7FD1-4894-ADBC-26C13D63217D@oracle.com> Message-ID: It really wasn't ever supposed to be my TD game, I keep trying to get you (and others interested in the community) to develop it. I'm up to my eyeballs in work already, as I'm sure you can relate :-) Richard On Aug 5, 2013, at 9:24 PM, Daniel Zwolenski wrote: > You should be able to check out they work in your TD game and continue development on that then. > > > On Tue, Aug 6, 2013 at 2:16 PM, Richard Bair wrote: > > To add > > to the confusion, Canvas currently has some drastic z-order bugs, and some > > clipping issues, so using it combined with Nodes is currently a no-go. > > I believe those have all been fixed in the last couple of weeks. > > Richard > From zonski at gmail.com Mon Aug 5 22:32:53 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 6 Aug 2013 15:32:53 +1000 Subject: TD game (hijacking Re: Performant Controls (hijacking Re: Developing controls based on Canvas?)) In-Reply-To: References: <52004AB2.3050800@oracle.com> <0B1BEB6D-7FD1-4894-ADBC-26C13D63217D@oracle.com> Message-ID: I'm out for that one for the foreseeable future. I've burnt up any and all "free" time on getting the desktop and iOS workflows working with Maven. I'm big time behind on client work. Tell you what though, if you can get someone at Oracle to take over the deployment tools and iOS stuff, I'd very happily switch over to building games and gliffy-like demo apps :) On Tue, Aug 6, 2013 at 3:02 PM, Richard Bair wrote: > It really wasn't ever supposed to be my TD game, I keep trying to get you > (and others interested in the community) to develop it. I'm up to my > eyeballs in work already, as I'm sure you can relate :-) > > Richard > > On Aug 5, 2013, at 9:24 PM, Daniel Zwolenski wrote: > > You should be able to check out they work in your TD game and continue > development on that then. > > > On Tue, Aug 6, 2013 at 2:16 PM, Richard Bair wrote: > >> > To add >> > to the confusion, Canvas currently has some drastic z-order bugs, and >> some >> > clipping issues, so using it combined with Nodes is currently a no-go. >> >> I believe those have all been fixed in the last couple of weeks. >> >> Richard >> > > > From sven.reimers at gmail.com Mon Aug 5 22:54:48 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 6 Aug 2013 07:54:48 +0200 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: <2CE8AFBF-F7FD-493C-BF4A-75CD64F4F367@oracle.com> References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> <2CE8AFBF-F7FD-493C-BF4A-75CD64F4F367@oracle.com> Message-ID: So we should start and assemble them on a community JavaFX showcase page? Should we try to get Jim Weaver and Gerrit involved? -Sven Am 06.08.2013 06:19 schrieb "Richard Bair" : > Here is another one on the Oracle page: > http://www.oracle.com/technetwork/java/javafx/codelse-1984189.html > > Richard > > On Aug 4, 2013, at 6:15 AM, Sven Reimers wrote: > > Hi, > > from my perspective a showcase list saying technology X is used by the top > ten largest engineering companies is always very nice to convince people > they are not basing a long term project/product on an used, not widespread > technology. > > So for me building a showcase page is a key thing for helping in the > decision making process. > > -Sven > > > On Sun, Aug 4, 2013 at 10:12 AM, Johan Vos wrote: > >> Hi, >> >> I agree such an overview page would definitely help, but the go/no-go >> decisions I often see have less to do with convincing customers about >> JavaFX being the right technology. Customers have a number of >> requirements, >> and if I can tell them JavaFX is capable of doing that, they trust me (and >> they will blame me when I'm wrong). >> >> The key bummer I've seen so far is (yet again) wide deployment. "It should >> run on tablets" and "Our Customers should be able to use [install] this >> very easily". >> I am very much aware of the progress being made in both areas, so I'm not >> complaining at all -- but there is a lot of work to be done. >> Just want to set expectations right: a cool overview of what is already >> achieved with JavaFX is not going to convince all potential customers -- >> in >> my experience the deployment is still the major reasons why a number of >> companies are not in favor of JavaFX yet. >> >> - Johan >> >> >> >> 2013/8/4 Anton Epple >> >> > A combination of a page describing an individual application, like the >> one >> > you linked here, would be one part and -more important- a page that >> lists >> > *all* the applications with a screenshot and a short description. The >> > latter would be important, because it's a showcase for decision makers >> who >> > are yet undecided if JavaFX is the right technology. >> > >> > Before that page existed for NB Platform, I had the same discussions I >> now >> > have for potential JavaFX projects. Developers are in doubt if the >> > technology is mature/performant/secure/whatever enough for their >> > large/unique/graphically demanding/etc. project. After they see the >> page, >> > they're convinced that it can be done. >> > >> > It's especially useful if you need to convince a team. Typically there's >> > at least one person in favor of a different technology (for JavaFX it's >> > typically GWT) and such a page is a great FUD-killer. >> > >> > Am 01.08.2013 um 22:40 schrieb Richard Bair : >> > >> > > Something I guess would go on such a page? >> > > >> > > http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ >> > > >> > > On Aug 1, 2013, at 3:21 AM, Anton Epple >> wrote: >> > > >> > >> Great idea, there's a site that does the same for NetBeans Platform >> > Apps: >> > >> >> > >> https://platform.netbeans.org/screenshots.html >> > >> >> > >> I can tell from my own experience that it helps a lot in discussions >> > with customers to show them that NASA, NATO, Boeing, UNO, US Army, and >> many >> > others are building on top of NB Platform. >> > >> >> > >> From the maintainer of this site, I know there's a lot of work >> involved >> > though, and you have to be very active in identifying users, and >> reaching >> > out to them. It's definitely not sufficient to wait for users to submit >> > their applications. Sometimes it can take a couple of years from first >> > contact to a screenshot. That said it's absolutely worth it, and I would >> > volunteer to help in any way I can. >> > >> >> > >> Toni >> > >> >> > >> -- >> > >> Anton Epple >> > >> >> > >> >> > >> >> > >> Am 28.07.2013 um 02:38 schrieb Jonathan Giles < >> > jonathan.giles at oracle.com>: >> > >> >> > >>> This is something that Jasper actually brought up just this morning >> > with Richard and I (wrt fxexperience hosting it). I suspect we may get >> > something underway in the coming weeks. Of course, it depends on the >> > community getting in touch with us and letting us talk about them - so >> much >> > of the JavaFX world is behind corporate firewalls, where talking about >> your >> > work is generally frowned upon. In any case, for those of you that can >> talk >> > about your work, please email one of us off-list. >> > >>> -- Jonathan >> > >>> Sent from a touch device. Please excuse my brevity. >> > >>> >> > >>> "John C. Turnbull" wrote: >> > >>>> +1 >> > >>>> >> > >>>> Such a site could be very useful. >> > >>>> >> > >>>> -----Original Message----- >> > >>>> From: openjfx-dev-bounces at openjdk.java.net >> > >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel >> > >>>> Zwolenski >> > >>>> Sent: Sunday, 28 July 2013 09:56 >> > >>>> To: Pedro Duque Vieira >> > >>>> Cc: OpenJFX Mailing List >> > >>>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) >> > >>>> >> > >>>> The idea of a JFX Sightings page (in the tradition of the Swing >> > >>>> Sightings >> > >>>> page) has been raised before and I think is a good one. >> > >>>> >> > >>>> It deserves it's own page though, that technet section isn't up to >> it >> > >>>> in my >> > >>>> opinion. >> > >>>> >> > >>>> Personally I think this would be great under the fxexperience site >> as >> > >>>> it >> > >>>> partners nicely with the links of the week? >> > >>>> >> > >>>> >> > >>>> >> > >>>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira >> > >>>> >> > >>>> wrote: >> > >>>> >> > >>>>> I have an Swing/JavaFX app, the site is: http://modellus.co >> > >>>>> >> > >>>>> How can I get it to be on that real world usecases section? Or >> does >> > >>>> it >> > >>>>> not have the necessary requirements to be in it? >> > >>>>> >> > >>>>> Thanks, best regards, >> > >>>>> >> > >>>>> @John: On the JavaFx community site they have a section with >> > >>>>> references to >> > >>>>>> real world usecases. >> > >>>>>> >> http://www.oracle.com/technetwork/java/javafx/community/index.html >> > >>>>>> >> > >>>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull >> > >>>>>> > > >>>>>>> wrote: >> > >>>>>>> Like Daniel said, none of what we say is in any way a criticism >> of >> > >>>>>>> the JavaFX development team who, in my view and that of the >> entire >> > >>>>>>> community, are doing an awesome job. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> For mine, all the shortcomings of JavaFX (perceived or actual) >> can >> > >>>>>>> be >> > >>>>>> blown >> > >>>>>>> away if I could just demonstrate what JavaFX is really capable >> of. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras >> (whose >> > >>>>>>> demo incidentally doesn't run since Java 7 Update 21). With >> Oracle >> > >>>> >> > >>>>>>> Ensemble >> > >>>>>> we >> > >>>>>>> can see that JavaFX has quite a nice set of basic controls and >> that >> > >>>> >> > >>>>>>> it at least supports very simple animations. With JFXtras >> Ensemble >> > >>>> >> > >>>>>>> we can see that very nice controls are possible but >> unfortunately >> > >>>>>>> many of these are >> > >>>>>> of >> > >>>>>>> a rather "whimsical" nature and not the kind of control you >> would >> > >>>>>>> use in everyday business apps. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> What else is there? >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Of course we have rock stars like Gerrit Grunwald who frequently >> > >>>>>>> post awesome controls and code snippets but we really need >> > >>>> something >> > >>>>>>> that >> > >>>>>> brings >> > >>>>>>> it altogether in a kick-arse showcase. Preferably a whole >> suite of >> > >>>>>> killer >> > >>>>>>> apps that highlights everything JavaFX is capable of. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Yes, that would require a lot of effort but IMHO it is >> absolutely >> > >>>>>>> worth >> > >>>>>> it. >> > >>>>>>> Without it, people like me really struggle to sell JavaFX or >> even >> > >>>>>>> get a handle on its true potential. I can promise people that >> more >> > >>>> >> > >>>>>>> advanced things are "possible" but given that they write the >> > >>>>>>> cheques, they need to see it for themselves. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> And how about a website of JavaFX reference sites? There must >> be >> > >>>>>>> big companies out there using it right? >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> In the end it doesn't matter if I personally see enormous >> potential >> > >>>> >> > >>>>>>> for JavaFX if I cannot convince others to see what I see. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> -jct >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] >> > >>>>>>> Sent: Saturday, 27 July 2013 09:12 >> > >>>>>>> To: John C. Turnbull >> > >>>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net >> > >>>>>>> Subject: Re: Can JavaFX do CAD? >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> +1 >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> I've failed to convince multiple clients that they should use >> JFX >> > >>>>>>> because of >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> a) lack of examples of what it can really do, and how to make >> it do >> > >>>> >> > >>>>>>> that (e.g. in enterprise space we have >> > >>>>>>> http://static.springsource.org/docs/petclinic.html) >> > >>>>>>> >> > >>>>>>> b) lack of any big or notable players out there actually using >> it, >> > >>>>>>> or at least publicly saying they are using it >> > >>>>>>> >> > >>>>>>> c) the deployment hassles vs the ease of html app deployment and >> > >>>> the >> > >>>>>>> true cross-platform-ness of html >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> After actually getting one client to trust me on it and use it >> on a >> > >>>> >> > >>>>>>> real, commercial app (startup), I hit problems with performance >> > >>>>>>> (broad interpretation of the term, not 'framerate'), crippling >> > >>>>>>> deployment and >> > >>>>>> auto >> > >>>>>>> updating issues, missing basic features (e.g. maximise button, >> > >>>>>>> coming in >> > >>>>>>> 2014 I believe?), unpredictability of CSS styling, and a lack of >> > >>>>>>> best practices for things like how to do CAD-like diagrams (not >> so >> > >>>>>>> much render performance but zooming, panning, mouse input, >> > >>>> layering, >> > >>>> dragging, etc). >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Like John, I've been guilty of letting my frustration show in >> these >> > >>>>>> forums. >> > >>>>>>> Like John, it's because I want so badly for JavaFX to be the >> > >>>>>>> platform I develop on, it has the potential to be awesome, but >> > >>>>>>> things (that seem obvious and small to me) completely stop it >> from >> > >>>>>>> being usable in a real world situation for me. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> It's not that we think the JFX team aren't slogging their guts >> out, >> > >>>>>> clearly >> > >>>>>>> you are. It's just that in some key areas, there are small-ish >> > >>>>>>> blocks >> > >>>>>> that >> > >>>>>>> stop the whole rocket from launching. To then see a whole lot of >> > >>>>>>> effort >> > >>>>>> be >> > >>>>>>> poured into things like binary CSS/FXML compilation, Pi platform >> > >>>>>>> support (that's more important than iOS/Android, really?), web >> > >>>>>>> deployment >> > >>>>>> patches, >> > >>>>>>> or even 3D (as cool as that is), just knocks me about. Obviously >> > >>>>>>> your priorities are coming from somewhere different to ours, but >> > >>>> the >> > >>>>>>> way you prioritise is unfathomable to me and that definitely >> adds >> > >>>> to >> > >>>>>>> the frustration. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> At this stage, I am not suggesting my clients use JFX (I >> actively >> > >>>>>>> discourage them from it, in their interest). Mobile is the area >> > >>>> that >> > >>>>>>> has the >> > >>>>>> potential >> > >>>>>>> to bring JFX back into usable for me as it can compete easier >> with >> > >>>>>>> the current technologies (which are all crap). Maybe if that >> ends >> > >>>> up >> > >>>>>>> working >> > >>>>>> (a >> > >>>>>>> long, long road to go on that and very much an 'if') then it >> will >> > >>>>>>> seep >> > >>>>>> back >> > >>>>>>> into the desktop for me, but at a minimum the desktop deployment >> > >>>>>>> options will need to be improved before that's even a >> possibility. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> I've come to accept that I am not in the primary target audience >> > >>>> for >> > >>>>>>> JavaFX, maybe a secondary target. I don't understand who the >> > >>>> primary >> > >>>>>>> target is though, and knowing/accepting doesn't make it any less >> > >>>>>>> frustrating. I >> > >>>>>> keep >> > >>>>>>> involved in the hope that I might get a usable platform >> somewhere >> > >>>>>>> along >> > >>>>>> the >> > >>>>>>> way but it's more of a hope than a belief. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> So nothing really new above, but just adding my voice to John's. >> > >>>>>>> JavaFX >> > >>>>>> is >> > >>>>>>> definitely not production ready for me, my clients and the >> types of >> > >>>> >> > >>>>>>> apps >> > >>>>>> I >> > >>>>>>> build (e.g. consumer facing online systems, >> enterprise/backoffice >> > >>>>>> systems, >> > >>>>>>> form/data systems, diagramming systems). One day I hope it will >> be, >> > >>>> >> > >>>>>>> but it's moving extremely slowly or not at all in the areas that >> > >>>>>>> would make it so for me. Meanwhile the competitors (primarily >> > >>>>>>> JavaScript based solutions) are improving rapidly in the areas >> > >>>> where >> > >>>>>>> they have traditionally been weak. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < >> > >>>>>> ozemale at ozemail.com.au >> > >>>>>>> > wrote: >> > >>>>>>> >> > >>>>>>> Hi Richard, >> > >>>>>>> >> > >>>>>>> I have to stop posting late at night, that one came across as >> > >>>> really >> > >>>>>> ANGRY! >> > >>>>>>> >> > >>>>>>> It's not anger, it's passion... and frustration. >> > >>>>>>> >> > >>>>>>> I am frustrated because I spend much of my day trying to >> convince >> > >>>> my >> > >>>>>>> employer that we should be using JavaFX. They ask me questions >> > >>>> like: >> > >>>>>>> >> > >>>>>>> "What happens if Oracle abandons JavaFX just like Sun did with >> JMF, >> > >>>>>> Java3D, >> > >>>>>>> JOGL etc. ?" >> > >>>>>>> >> > >>>>>>> I say: >> > >>>>>>> >> > >>>>>>> "This is Oracle, not Sun." >> > >>>>>>> >> > >>>>>>> They say: >> > >>>>>>> >> > >>>>>>> "Can you show me what JavaFX can do? There must be examples out >> > >>>>>>> there right?" >> > >>>>>>> >> > >>>>>>> And I say: >> > >>>>>>> >> > >>>>>>> "Sure, here's Ensemble." >> > >>>>>>> >> > >>>>>>> They say: >> > >>>>>>> >> > >>>>>>> "OK, so it has a nice set of basic controls and can do simple >> > >>>>>>> animations but what about more complex things like Flash?" >> > >>>>>>> >> > >>>>>>> ...hence the dancing cat reference. >> > >>>>>>> >> > >>>>>>> It's not that my employer *needs* dancing cats, it's just that >> they >> > >>>> >> > >>>>>>> need >> > >>>>>> to >> > >>>>>>> see that there is more to JavaFX than red circle transitions. I >> > >>>>>>> can't >> > >>>>>> even >> > >>>>>>> prove to them that JavaFX is capable of dancing cats. They >> don't >> > >>>>>>> have >> > >>>>>> the >> > >>>>>>> resources to fund me to develop something more sophisticated but >> > >>>>>>> they >> > >>>>>> tell >> > >>>>>>> me that if JavaFX truly was a "mature" technology (like I tell >> > >>>> them) >> > >>>>>>> then where are all the examples? >> > >>>>>>> >> > >>>>>>> I am finding it difficult to convince them that JavaFX is >> > >>>> production >> > >>>>>> ready >> > >>>>>>> and is not still in "experimental" mode because I am unable to >> > >>>>>> demonstrate >> > >>>>>>> its true capabilities or refer them to many examples of people >> (and >> > >>>> >> > >>>>>>> I >> > >>>>>> mean >> > >>>>>>> big companies) actually using it. >> > >>>>>>> >> > >>>>>>> The main concerns of my employer and I think many companies in a >> > >>>>>>> similar situation is that JavaFX won't survive long term and >> that >> > >>>> it >> > >>>>>>> is only >> > >>>>>> really >> > >>>>>>> suitable for form based applications. Then of course there is >> the >> > >>>>>>> whole >> > >>>>>>> "HTML5 runs on all platforms" argument but that's another >> story... >> > >>>>>>> >> > >>>>>>> So this is why I think it's imperative that Oracle invests in >> > >>>>>>> developing >> > >>>>>> a >> > >>>>>>> true showcase application for JavaFX. Something that >> non-technical >> > >>>>>> people >> > >>>>>>> (like managers who make decisions about where the money goes) >> can >> > >>>>>>> look at it and go "wow!". >> > >>>>>>> >> > >>>>>>> I am just not getting my managers to go "wow" at what I can show >> > >>>>>>> them >> > >>>>>> with >> > >>>>>>> JavaFX at the moment. >> > >>>>>>> >> > >>>>>>> Every comment or apparent criticism I post about JavaFX is from >> the >> > >>>> >> > >>>>>>> perspective that I am trying to deal with real-world problems >> and >> > >>>>>>> people who require proof (such as demos, reference sites etc.) >> and >> > >>>>>>> not because I myself think JavaFX is not up to scratch. >> > >>>>>>> >> > >>>>>>> It's quite the opposite actually. >> > >>>>>>> >> > >>>>>>> I am a very, very strong believer and supporter of JavaFX and >> have >> > >>>>>>> many reasons both personal and professional as to why I want it >> to >> > >>>>>>> be a >> > >>>>>> massive >> > >>>>>>> success. As I have said before, there are plenty of people who >> > >>>>>>> praise JavaFX and tend to avoid the very real issues that are >> > >>>>>>> restricting its adoption. I just think we have to face these >> > >>>> issues >> > >>>>>>> head on if we are to compete in what is a very cut-throat >> industry. >> > >>>>>>> >> > >>>>>>> -jct >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> -----Original Message----- >> > >>>>>>> From: Richard Bair [mailto:richard.bair at oracle.com >> > >>>>>>> ] >> > >>>>>>> Sent: Saturday, 27 July 2013 01:40 >> > >>>>>>> To: John C. Turnbull >> > >>>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net >> > >>>>>>> >> > >>>>>>> Subject: Re: Can JavaFX do CAD? >> > >>>>>>> >> > >>>>>>>> For Flash, there are literally millions of examples of >> > >>>>>>>> fancy/complex/impressive graphics and animations out there that >> > >>>> can >> > >>>>>>>> be really impressive at times. I have not seen ONE such >> example >> > >>>> in >> > >>>>>> JavaFX! >> > >>>>>>> >> > >>>>>>> Point to one? >> > >>>>>>> >> > >>>>>>> Have you seen any of the JavaOne examples? The movie wall or >> movies >> > >>>> >> > >>>>>>> on a stack of 3D cubes was pretty good. But I guess you're not >> > >>>>>>> interested in >> > >>>>>> the >> > >>>>>>> 3D aspect? What is it you are looking for exactly? Different >> people >> > >>>> >> > >>>>>>> (on this >> > >>>>>>> list) have had different perceptions on both (a) what's >> important >> > >>>>>>> and (b) what kind of graphics they're interested in. Most people >> > >>>>>>> would deride the dancing cat as being totally irrelevant to the >> > >>>>>>> types of applications they're trying to build (the basis for >> much >> > >>>> of >> > >>>>>>> flash animations is shape >> > >>>>>> morphing, >> > >>>>>>> you can find some code here >> > >>>> https://gist.github.com/gontard/5029764). >> > >>>>>>> >> > >>>>>>> On the other hand, JavaFX is not a replacement for OpenGL. >> Drawing >> > >>>>>>> 25 million lines is just not something we can do right now, >> > >>>>>>> especially in a resource constrained environment. I've already >> > >>>>>>> commented on the memory overhead (which would continue to be an >> > >>>>>>> issue even if the drawing part of the problem were solved). >> > >>>>>>> >> > >>>>>>> I've pushed to graphics repo the StretchyGrid, which is about >> 300k >> > >>>>>>> line nodes (the actual amount is variable, see the javadoc >> > >>>>>>> comments). At 300k nodes the scene graph overhead is negligible >> on >> > >>>>>>> the FX side, dirty opts >> > >>>>>> is >> > >>>>>>> taking a long time to run, and painting is really slow. >> > >>>>>>> >> > >>>>>>> PULSE: 347 [122ms:222ms] >> > >>>>>>> T12 (8 +0ms): CSS Pass >> > >>>>>>> T12 (8 +0ms): Layout Pass >> > >>>>>>> T12 (47 +53ms): Waiting for previous rendering >> > >>>>>>> T12 (100 +1ms): Copy state to render graph >> > >>>>>>> T10 (101 +16ms): Dirty Opts Computed >> > >>>>>>> T10 (117 +105ms): Painted >> > >>>>>>> Counters: >> > >>>>>>> Nodes rendered: 306565 >> > >>>>>>> Nodes visited during render: 306565 >> > >>>>>>> >> > >>>>>>> If I were doing this by hand in open GL, I think the drawing >> would >> > >>>>>>> be essentially free, if I used LINES with GL anti-aliasing, I >> could >> > >>>> >> > >>>>>>> send 'em all down to the card in a single shot (and if I had a >> > >>>>>>> modern GL I could >> > >>>>>> do >> > >>>>>>> LINES + FXAA or one of the other per-pixel AA algorithms >> available >> > >>>>>>> and it would turn out pretty nice). Because our shapes don't >> > >>>>>>> implement the >> > >>>>>> non-AA >> > >>>>>>> path, and our AA involves software rasterization and uploading >> of >> > >>>>>> pixels, I >> > >>>>>>> expect that to be the main source of the 105ms time being spent >> > >>>> here. >> > >>>>>>> >> > >>>>>>> Also I noticed (by turning on prism.showdirty=true) that the >> entire >> > >>>> >> > >>>>>>> grid >> > >>>>>> is >> > >>>>>>> being painted every time, even though visually it looks like >> only a >> > >>>> >> > >>>>>>> small subset actually needs to be changed. But that's really a >> > >>>> minor >> > >>>>>>> thing, as >> > >>>>>> I >> > >>>>>>> said, drawing this many lines should basically be free if I >> > >>>>>>> configure "smooth" to false in the app. Except that right now >> it is >> > >>>> >> > >>>>>>> totally not implemented (in NGShape): >> > >>>>>>> >> > >>>>>>> public void setAntialiased(boolean aa) { >> > >>>>>>> // We don't support aliased shapes at this time >> > >>>>>>> } >> > >>>>>>> >> > >>>>>>> The point of stretchy grid is not to say "wow look at this >> amazing >> > >>>> demo". >> > >>>>>>> The point is to say "what happens if I put in 300K nodes. Where >> > >>>> does >> > >>>>>>> the system start to fall over?". >> > >>>>>>> >> > >>>>>>> Richard= >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>> >> > >>>>> >> > >>>>> -- >> > >>>>> Pedro Duque Vieira >> > >> >> > > >> > >> > >> > > > > -- > 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 Aug 5 23:33:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 06:33:26 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32032 Android: VM hangs when application finishes. Message-ID: <20130806063346.C67C9485F8@hg.openjdk.java.net> Changeset: 521cced8d920 Author: tb115823 Date: 2013-08-06 08:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/521cced8d920 RT-32032 Android: VM hangs when application finishes. Detach correctly all threads. Send notification to FXActivity that VM has shutdown. ! modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java ! modules/graphics/src/android/java/com/oracle/dalvik/NativePipeReader.java ! modules/graphics/src/android/java/com/oracle/dalvik/VMLauncher.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/input/android/androidInput.c ! modules/graphics/src/main/native-glass/lens/input/android/androidInput.h ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c From benjamin.john.evans at gmail.com Tue Aug 6 02:35:18 2013 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 6 Aug 2013 10:35:18 +0100 Subject: Build failures In-Reply-To: <6D6C891E-AF64-40A9-AAD0-B3A49A3AD0D7@oracle.com> References: <1BDD8680-89D7-487A-B7AE-0BB94F48E9FA@oracle.com> <6D6C891E-AF64-40A9-AAD0-B3A49A3AD0D7@oracle.com> Message-ID: On Thu, Aug 1, 2013 at 8:11 PM, Richard Bair wrote: > By the way, can I suggest moving away from the forest hg extension - it's > no longer supported & can't be made to work reliably on Mac. > > > Which page did you see this one? I see this on the Building OpenJFX wiki > page: > > "(Note: Historically you also had to clone the "jfx" repository in the > forest that you cared about. However we have modified our approach, such > that we no longer promote the use of a forest, and instead are putting all > of our sources in a single repository, presently named "rt")." > > We actually don't use the forest extension on OpenJFX at all anymore, if > we're still referring to it on a page I'll fix it. > > It's in the README. > Also, are you using the OpenJFX master, or OpenJFX Controls or OpenJFX > graphics repo? Graphics / Controls are the daily team repos, master being > only sync'd up weekly. > I'm using master - I couldn't see any other way to get bootstrapped. Is there some other process I should be following for a first build? I'm attempting to get OpenJFX built & running against the tip of Nashorn. >> > > OK the first question I have is to make sure I understand correctly. Do > you mean that you're trying to build the latest OpenJFX + the latest > Nashorn, combine them into a single JDK build, and then write an app that > uses both? Is Nashorn developed in a different repo, like OpenJFX is, or is > it now built as part of the normal JDK 8? > Nashorn is folded into JDK 8 regiular, but the head of development is ahead of OpenJDK mainline. > > Assuming it is, it still isn't working. After a certain amount of >> > yak-shaving (Gradle being useless, and having to hack around the forest >> > extension gunk) the build is failing (details below). >> > > Why did you need forest? Maybe if we start here with where the yak shaving > exercise started then maybe I can see where you may have left the beaten > path. > The README told me I needed it - I worked out the equivalent hg commands (the ones given in the README as an alternative to forest are slightly wrong). > > >> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar >> > > Which build of Java 8 is this? > This is with Oracle Java 8 EA latest beta. Using an OpenJDK build instead causes a different set of errors. > > :fxpackager:compileLauncher >> > In file included from >> > >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6, >> > from >> > >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, >> > from >> > >> /Users/boxcat/projects/openjdk/master/rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26: >> > >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12:20: >> > error: stdarg.h: No such file or directory >> > > I'm building with 10.8 rather than 10.7. Kevin do you know what the hudson > machines are setup to build with? > Hm. This machine is actually a 10.8 box. > Looking at main.m line 26 we see this import: > > #import > > It seems that something must be misconfigured on your system if importing > Cocoa.h leads to a compile error. I'm not an expert on Mac native > programming, maybe Felipe or David Dehaven can chime in? > I suspect some XCode oddness here - let me investigate further. Thanks, Ben From hang.vo at oracle.com Tue Aug 6 02:47:38 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 09:47:38 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32123: Clip properly synced after parent visibility change. Message-ID: <20130806094823.8FDB9485FC@hg.openjdk.java.net> Changeset: bd6f656cd8a9 Author: Pavel Safrata Date: 2013-08-06 10:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bd6f656cd8a9 RT-32123: Clip properly synced after parent visibility change. Contributed-by: Tom Schindl Added unit test. ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/stub/java/javafx/scene/NodeTest.java From ozemale at ozemail.com.au Tue Aug 6 03:41:45 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Tue, 6 Aug 2013 20:41:45 +1000 Subject: Brick Breaker ball jitter Message-ID: <008601ce9291$8c016d20$a4044760$@ozemail.com.au> I seem to remember some time ago that work was done on reducing the jitter in the ball's motion in the Brick Breaker demo in Ensemble8. Did this ever make it into the main line? I ask because I have just installed JDK 8 b101 and the ball still shows very significant jitter in its motion on this Windows 7 x64 machine. Thanks, -jct From hang.vo at oracle.com Tue Aug 6 03:47:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 10:47:37 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32125: Removed unnecessary call to getParent. Message-ID: <20130806104810.A80DA485FE@hg.openjdk.java.net> Changeset: b0e96ed06cce Author: Pavel Safrata Date: 2013-08-06 11:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b0e96ed06cce RT-32125: Removed unnecessary call to getParent. Contributed-by: Tom Schindl ! modules/graphics/src/main/java/javafx/scene/Node.java From hang.vo at oracle.com Tue Aug 6 04:17:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 11:17:44 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32039: Yandex Maps are broken after sync with WebKit trunk Message-ID: <20130806111804.6A7FB485FF@hg.openjdk.java.net> Changeset: 91a8ecbea96e Author: Vasiliy Baranov Date: 2013-08-06 15:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/91a8ecbea96e RT-32039: Yandex Maps are broken after sync with WebKit trunk ! modules/web/src/main/native/Source/WebCore/DerivedSourcesJava.pri ! modules/web/src/main/native/Source/WebCore/page/java/ChromeClientJava.cpp ! modules/web/src/main/native/Source/WebCore/page/java/ChromeClientJava.h ! modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.cpp ! modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.h From Claus.Luethje at osys.ch Tue Aug 6 04:59:02 2013 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Tue, 6 Aug 2013 11:59:02 +0000 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: References: <363B4111-330B-4D96-801A-5CAE77C9FCB6@gmail.com> <003201ce8b28$2caf1ef0$860d5cd0$@ozemail.com.au> <369223f7-cfbd-4139-ab0d-16a4d8a95d50@email.android.com> <0CDA0FBD-130F-4D43-8014-73F2ABC0F1F7@eppleton.de> <36B0E782-C255-4746-9C42-0D7E22A97B91@oracle.com> <3C66CAC3-8E34-4FF1-BEEE-C6D4EBD04F6B@eppleton.de> <2CE8AFBF-F7FD-493C-BF4A-75CD64F4F367@oracle.com> Message-ID: <193FF4ED343AF14F8CDC65B4792C954D23B8C258@Jeri.osys.ch> It makes certainly sense to get Jim Weaver and Gerrit involved. Just my 0.02$ Claus -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Sven Reimers Sent: Dienstag, 6. August 2013 07:55 To: Richard Bair Cc: openjfx mailing list; Pedro Duque Vieira Subject: Re: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) So we should start and assemble them on a community JavaFX showcase page? Should we try to get Jim Weaver and Gerrit involved? -Sven Am 06.08.2013 06:19 schrieb "Richard Bair" : > Here is another one on the Oracle page: > http://www.oracle.com/technetwork/java/javafx/codelse-1984189.html > > Richard > > On Aug 4, 2013, at 6:15 AM, Sven Reimers wrote: > > Hi, > > from my perspective a showcase list saying technology X is used by the > top ten largest engineering companies is always very nice to convince > people they are not basing a long term project/product on an used, not > widespread technology. > > So for me building a showcase page is a key thing for helping in the > decision making process. > > -Sven > > > On Sun, Aug 4, 2013 at 10:12 AM, Johan Vos wrote: > >> Hi, >> >> I agree such an overview page would definitely help, but the go/no-go >> decisions I often see have less to do with convincing customers about >> JavaFX being the right technology. Customers have a number of >> requirements, and if I can tell them JavaFX is capable of doing that, >> they trust me (and they will blame me when I'm wrong). >> >> The key bummer I've seen so far is (yet again) wide deployment. "It >> should run on tablets" and "Our Customers should be able to use >> [install] this very easily". >> I am very much aware of the progress being made in both areas, so I'm >> not complaining at all -- but there is a lot of work to be done. >> Just want to set expectations right: a cool overview of what is >> already achieved with JavaFX is not going to convince all potential >> customers -- in my experience the deployment is still the major >> reasons why a number of companies are not in favor of JavaFX yet. >> >> - Johan >> >> >> >> 2013/8/4 Anton Epple >> >> > A combination of a page describing an individual application, like >> > the >> one >> > you linked here, would be one part and -more important- a page that >> lists >> > *all* the applications with a screenshot and a short description. >> > The latter would be important, because it's a showcase for decision >> > makers >> who >> > are yet undecided if JavaFX is the right technology. >> > >> > Before that page existed for NB Platform, I had the same >> > discussions I >> now >> > have for potential JavaFX projects. Developers are in doubt if the >> > technology is mature/performant/secure/whatever enough for their >> > large/unique/graphically demanding/etc. project. After they see the >> page, >> > they're convinced that it can be done. >> > >> > It's especially useful if you need to convince a team. Typically >> > there's at least one person in favor of a different technology (for >> > JavaFX it's typically GWT) and such a page is a great FUD-killer. >> > >> > Am 01.08.2013 um 22:40 schrieb Richard Bair : >> > >> > > Something I guess would go on such a page? >> > > >> > > http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ >> > > >> > > On Aug 1, 2013, at 3:21 AM, Anton Epple >> wrote: >> > > >> > >> Great idea, there's a site that does the same for NetBeans >> > >> Platform >> > Apps: >> > >> >> > >> https://platform.netbeans.org/screenshots.html >> > >> >> > >> I can tell from my own experience that it helps a lot in >> > >> discussions >> > with customers to show them that NASA, NATO, Boeing, UNO, US Army, >> > and >> many >> > others are building on top of NB Platform. >> > >> >> > >> From the maintainer of this site, I know there's a lot of work >> involved >> > though, and you have to be very active in identifying users, and >> reaching >> > out to them. It's definitely not sufficient to wait for users to >> > submit their applications. Sometimes it can take a couple of years >> > from first contact to a screenshot. That said it's absolutely worth >> > it, and I would volunteer to help in any way I can. >> > >> >> > >> Toni >> > >> >> > >> -- >> > >> Anton Epple >> > >> >> > >> >> > >> >> > >> Am 28.07.2013 um 02:38 schrieb Jonathan Giles < >> > jonathan.giles at oracle.com>: >> > >> >> > >>> This is something that Jasper actually brought up just this >> > >>> morning >> > with Richard and I (wrt fxexperience hosting it). I suspect we may >> > get something underway in the coming weeks. Of course, it depends >> > on the community getting in touch with us and letting us talk about >> > them - so >> much >> > of the JavaFX world is behind corporate firewalls, where talking >> > about >> your >> > work is generally frowned upon. In any case, for those of you that >> > can >> talk >> > about your work, please email one of us off-list. >> > >>> -- Jonathan >> > >>> Sent from a touch device. Please excuse my brevity. >> > >>> >> > >>> "John C. Turnbull" wrote: >> > >>>> +1 >> > >>>> >> > >>>> Such a site could be very useful. >> > >>>> >> > >>>> -----Original Message----- >> > >>>> From: openjfx-dev-bounces at openjdk.java.net >> > >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of >> > >>>> Daniel Zwolenski >> > >>>> Sent: Sunday, 28 July 2013 09:56 >> > >>>> To: Pedro Duque Vieira >> > >>>> Cc: OpenJFX Mailing List >> > >>>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) >> > >>>> >> > >>>> The idea of a JFX Sightings page (in the tradition of the >> > >>>> Swing Sightings >> > >>>> page) has been raised before and I think is a good one. >> > >>>> >> > >>>> It deserves it's own page though, that technet section isn't >> > >>>> up to >> it >> > >>>> in my >> > >>>> opinion. >> > >>>> >> > >>>> Personally I think this would be great under the fxexperience >> > >>>> site >> as >> > >>>> it >> > >>>> partners nicely with the links of the week? >> > >>>> >> > >>>> >> > >>>> >> > >>>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira >> > >>>> >> > >>>> wrote: >> > >>>> >> > >>>>> I have an Swing/JavaFX app, the site is: http://modellus.co >> > >>>>> >> > >>>>> How can I get it to be on that real world usecases section? >> > >>>>> Or >> does >> > >>>> it >> > >>>>> not have the necessary requirements to be in it? >> > >>>>> >> > >>>>> Thanks, best regards, >> > >>>>> >> > >>>>> @John: On the JavaFx community site they have a section with >> > >>>>> references to >> > >>>>>> real world usecases. >> > >>>>>> >> http://www.oracle.com/technetwork/java/javafx/community/index.html >> > >>>>>> >> > >>>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull >> > >>>>>> > > >>>>>>> wrote: >> > >>>>>>> Like Daniel said, none of what we say is in any way a >> > >>>>>>> criticism >> of >> > >>>>>>> the JavaFX development team who, in my view and that of the >> entire >> > >>>>>>> community, are doing an awesome job. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> For mine, all the shortcomings of JavaFX (perceived or >> > >>>>>>> actual) >> can >> > >>>>>>> be >> > >>>>>> blown >> > >>>>>>> away if I could just demonstrate what JavaFX is really >> > >>>>>>> capable >> of. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras >> (whose >> > >>>>>>> demo incidentally doesn't run since Java 7 Update 21). >> > >>>>>>> With >> Oracle >> > >>>> >> > >>>>>>> Ensemble >> > >>>>>> we >> > >>>>>>> can see that JavaFX has quite a nice set of basic controls >> > >>>>>>> and >> that >> > >>>> >> > >>>>>>> it at least supports very simple animations. With JFXtras >> Ensemble >> > >>>> >> > >>>>>>> we can see that very nice controls are possible but >> unfortunately >> > >>>>>>> many of these are >> > >>>>>> of >> > >>>>>>> a rather "whimsical" nature and not the kind of control you >> would >> > >>>>>>> use in everyday business apps. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> What else is there? >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Of course we have rock stars like Gerrit Grunwald who >> > >>>>>>> frequently post awesome controls and code snippets but we >> > >>>>>>> really need >> > >>>> something >> > >>>>>>> that >> > >>>>>> brings >> > >>>>>>> it altogether in a kick-arse showcase. Preferably a whole >> suite of >> > >>>>>> killer >> > >>>>>>> apps that highlights everything JavaFX is capable of. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Yes, that would require a lot of effort but IMHO it is >> absolutely >> > >>>>>>> worth >> > >>>>>> it. >> > >>>>>>> Without it, people like me really struggle to sell JavaFX >> > >>>>>>> or >> even >> > >>>>>>> get a handle on its true potential. I can promise people >> > >>>>>>> that >> more >> > >>>> >> > >>>>>>> advanced things are "possible" but given that they write >> > >>>>>>> the cheques, they need to see it for themselves. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> And how about a website of JavaFX reference sites? There >> > >>>>>>> must >> be >> > >>>>>>> big companies out there using it right? >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> In the end it doesn't matter if I personally see enormous >> potential >> > >>>> >> > >>>>>>> for JavaFX if I cannot convince others to see what I see. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> -jct >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] >> > >>>>>>> Sent: Saturday, 27 July 2013 09:12 >> > >>>>>>> To: John C. Turnbull >> > >>>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net >> > >>>>>>> Subject: Re: Can JavaFX do CAD? >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> +1 >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> I've failed to convince multiple clients that they should >> > >>>>>>> use >> JFX >> > >>>>>>> because of >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> a) lack of examples of what it can really do, and how to >> > >>>>>>> make >> it do >> > >>>> >> > >>>>>>> that (e.g. in enterprise space we have >> > >>>>>>> http://static.springsource.org/docs/petclinic.html) >> > >>>>>>> >> > >>>>>>> b) lack of any big or notable players out there actually >> > >>>>>>> using >> it, >> > >>>>>>> or at least publicly saying they are using it >> > >>>>>>> >> > >>>>>>> c) the deployment hassles vs the ease of html app >> > >>>>>>> deployment and >> > >>>> the >> > >>>>>>> true cross-platform-ness of html >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> After actually getting one client to trust me on it and use >> > >>>>>>> it >> on a >> > >>>> >> > >>>>>>> real, commercial app (startup), I hit problems with >> > >>>>>>> performance (broad interpretation of the term, not >> > >>>>>>> 'framerate'), crippling deployment and >> > >>>>>> auto >> > >>>>>>> updating issues, missing basic features (e.g. maximise >> > >>>>>>> button, coming in >> > >>>>>>> 2014 I believe?), unpredictability of CSS styling, and a >> > >>>>>>> lack of best practices for things like how to do CAD-like >> > >>>>>>> diagrams (not >> so >> > >>>>>>> much render performance but zooming, panning, mouse input, >> > >>>> layering, >> > >>>> dragging, etc). >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Like John, I've been guilty of letting my frustration show >> > >>>>>>> in >> these >> > >>>>>> forums. >> > >>>>>>> Like John, it's because I want so badly for JavaFX to be >> > >>>>>>> the platform I develop on, it has the potential to be >> > >>>>>>> awesome, but things (that seem obvious and small to me) >> > >>>>>>> completely stop it >> from >> > >>>>>>> being usable in a real world situation for me. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> It's not that we think the JFX team aren't slogging their >> > >>>>>>> guts >> out, >> > >>>>>> clearly >> > >>>>>>> you are. It's just that in some key areas, there are >> > >>>>>>> small-ish blocks >> > >>>>>> that >> > >>>>>>> stop the whole rocket from launching. To then see a whole >> > >>>>>>> lot of effort >> > >>>>>> be >> > >>>>>>> poured into things like binary CSS/FXML compilation, Pi >> > >>>>>>> platform support (that's more important than iOS/Android, >> > >>>>>>> really?), web deployment >> > >>>>>> patches, >> > >>>>>>> or even 3D (as cool as that is), just knocks me about. >> > >>>>>>> Obviously your priorities are coming from somewhere >> > >>>>>>> different to ours, but >> > >>>> the >> > >>>>>>> way you prioritise is unfathomable to me and that >> > >>>>>>> definitely >> adds >> > >>>> to >> > >>>>>>> the frustration. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> At this stage, I am not suggesting my clients use JFX (I >> actively >> > >>>>>>> discourage them from it, in their interest). Mobile is the >> > >>>>>>> area >> > >>>> that >> > >>>>>>> has the >> > >>>>>> potential >> > >>>>>>> to bring JFX back into usable for me as it can compete >> > >>>>>>> easier >> with >> > >>>>>>> the current technologies (which are all crap). Maybe if >> > >>>>>>> that >> ends >> > >>>> up >> > >>>>>>> working >> > >>>>>> (a >> > >>>>>>> long, long road to go on that and very much an 'if') then >> > >>>>>>> it >> will >> > >>>>>>> seep >> > >>>>>> back >> > >>>>>>> into the desktop for me, but at a minimum the desktop >> > >>>>>>> deployment options will need to be improved before that's >> > >>>>>>> even a >> possibility. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> I've come to accept that I am not in the primary target >> > >>>>>>> audience >> > >>>> for >> > >>>>>>> JavaFX, maybe a secondary target. I don't understand who >> > >>>>>>> the >> > >>>> primary >> > >>>>>>> target is though, and knowing/accepting doesn't make it any >> > >>>>>>> less frustrating. I >> > >>>>>> keep >> > >>>>>>> involved in the hope that I might get a usable platform >> somewhere >> > >>>>>>> along >> > >>>>>> the >> > >>>>>>> way but it's more of a hope than a belief. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> So nothing really new above, but just adding my voice to John's. >> > >>>>>>> JavaFX >> > >>>>>> is >> > >>>>>>> definitely not production ready for me, my clients and the >> types of >> > >>>> >> > >>>>>>> apps >> > >>>>>> I >> > >>>>>>> build (e.g. consumer facing online systems, >> enterprise/backoffice >> > >>>>>> systems, >> > >>>>>>> form/data systems, diagramming systems). One day I hope it >> > >>>>>>> will >> be, >> > >>>> >> > >>>>>>> but it's moving extremely slowly or not at all in the areas >> > >>>>>>> that would make it so for me. Meanwhile the competitors >> > >>>>>>> (primarily JavaScript based solutions) are improving >> > >>>>>>> rapidly in the areas >> > >>>> where >> > >>>>>>> they have traditionally been weak. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < >> > >>>>>> ozemale at ozemail.com.au >> > >>>>>>> > wrote: >> > >>>>>>> >> > >>>>>>> Hi Richard, >> > >>>>>>> >> > >>>>>>> I have to stop posting late at night, that one came across >> > >>>>>>> as >> > >>>> really >> > >>>>>> ANGRY! >> > >>>>>>> >> > >>>>>>> It's not anger, it's passion... and frustration. >> > >>>>>>> >> > >>>>>>> I am frustrated because I spend much of my day trying to >> convince >> > >>>> my >> > >>>>>>> employer that we should be using JavaFX. They ask me >> > >>>>>>> questions >> > >>>> like: >> > >>>>>>> >> > >>>>>>> "What happens if Oracle abandons JavaFX just like Sun did >> > >>>>>>> with >> JMF, >> > >>>>>> Java3D, >> > >>>>>>> JOGL etc. ?" >> > >>>>>>> >> > >>>>>>> I say: >> > >>>>>>> >> > >>>>>>> "This is Oracle, not Sun." >> > >>>>>>> >> > >>>>>>> They say: >> > >>>>>>> >> > >>>>>>> "Can you show me what JavaFX can do? There must be examples >> > >>>>>>> out there right?" >> > >>>>>>> >> > >>>>>>> And I say: >> > >>>>>>> >> > >>>>>>> "Sure, here's Ensemble." >> > >>>>>>> >> > >>>>>>> They say: >> > >>>>>>> >> > >>>>>>> "OK, so it has a nice set of basic controls and can do >> > >>>>>>> simple animations but what about more complex things like Flash?" >> > >>>>>>> >> > >>>>>>> ...hence the dancing cat reference. >> > >>>>>>> >> > >>>>>>> It's not that my employer *needs* dancing cats, it's just >> > >>>>>>> that >> they >> > >>>> >> > >>>>>>> need >> > >>>>>> to >> > >>>>>>> see that there is more to JavaFX than red circle >> > >>>>>>> transitions. I can't >> > >>>>>> even >> > >>>>>>> prove to them that JavaFX is capable of dancing cats. They >> don't >> > >>>>>>> have >> > >>>>>> the >> > >>>>>>> resources to fund me to develop something more >> > >>>>>>> sophisticated but they >> > >>>>>> tell >> > >>>>>>> me that if JavaFX truly was a "mature" technology (like I >> > >>>>>>> tell >> > >>>> them) >> > >>>>>>> then where are all the examples? >> > >>>>>>> >> > >>>>>>> I am finding it difficult to convince them that JavaFX is >> > >>>> production >> > >>>>>> ready >> > >>>>>>> and is not still in "experimental" mode because I am unable >> > >>>>>>> to >> > >>>>>> demonstrate >> > >>>>>>> its true capabilities or refer them to many examples of >> > >>>>>>> people >> (and >> > >>>> >> > >>>>>>> I >> > >>>>>> mean >> > >>>>>>> big companies) actually using it. >> > >>>>>>> >> > >>>>>>> The main concerns of my employer and I think many companies >> > >>>>>>> in a similar situation is that JavaFX won't survive long >> > >>>>>>> term and >> that >> > >>>> it >> > >>>>>>> is only >> > >>>>>> really >> > >>>>>>> suitable for form based applications. Then of course there >> > >>>>>>> is >> the >> > >>>>>>> whole >> > >>>>>>> "HTML5 runs on all platforms" argument but that's another >> story... >> > >>>>>>> >> > >>>>>>> So this is why I think it's imperative that Oracle invests >> > >>>>>>> in developing >> > >>>>>> a >> > >>>>>>> true showcase application for JavaFX. Something that >> non-technical >> > >>>>>> people >> > >>>>>>> (like managers who make decisions about where the money >> > >>>>>>> goes) >> can >> > >>>>>>> look at it and go "wow!". >> > >>>>>>> >> > >>>>>>> I am just not getting my managers to go "wow" at what I can >> > >>>>>>> show them >> > >>>>>> with >> > >>>>>>> JavaFX at the moment. >> > >>>>>>> >> > >>>>>>> Every comment or apparent criticism I post about JavaFX is >> > >>>>>>> from >> the >> > >>>> >> > >>>>>>> perspective that I am trying to deal with real-world >> > >>>>>>> problems >> and >> > >>>>>>> people who require proof (such as demos, reference sites >> > >>>>>>> etc.) >> and >> > >>>>>>> not because I myself think JavaFX is not up to scratch. >> > >>>>>>> >> > >>>>>>> It's quite the opposite actually. >> > >>>>>>> >> > >>>>>>> I am a very, very strong believer and supporter of JavaFX >> > >>>>>>> and >> have >> > >>>>>>> many reasons both personal and professional as to why I >> > >>>>>>> want it >> to >> > >>>>>>> be a >> > >>>>>> massive >> > >>>>>>> success. As I have said before, there are plenty of people >> > >>>>>>> who praise JavaFX and tend to avoid the very real issues >> > >>>>>>> that are restricting its adoption. I just think we have to >> > >>>>>>> face these >> > >>>> issues >> > >>>>>>> head on if we are to compete in what is a very cut-throat >> industry. >> > >>>>>>> >> > >>>>>>> -jct >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> -----Original Message----- >> > >>>>>>> From: Richard Bair [mailto:richard.bair at oracle.com >> > >>>>>>> ] >> > >>>>>>> Sent: Saturday, 27 July 2013 01:40 >> > >>>>>>> To: John C. Turnbull >> > >>>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net >> > >>>>>>> >> > >>>>>>> Subject: Re: Can JavaFX do CAD? >> > >>>>>>> >> > >>>>>>>> For Flash, there are literally millions of examples of >> > >>>>>>>> fancy/complex/impressive graphics and animations out there >> > >>>>>>>> that >> > >>>> can >> > >>>>>>>> be really impressive at times. I have not seen ONE such >> example >> > >>>> in >> > >>>>>> JavaFX! >> > >>>>>>> >> > >>>>>>> Point to one? >> > >>>>>>> >> > >>>>>>> Have you seen any of the JavaOne examples? The movie wall >> > >>>>>>> or >> movies >> > >>>> >> > >>>>>>> on a stack of 3D cubes was pretty good. But I guess you're >> > >>>>>>> not interested in >> > >>>>>> the >> > >>>>>>> 3D aspect? What is it you are looking for exactly? >> > >>>>>>> Different >> people >> > >>>> >> > >>>>>>> (on this >> > >>>>>>> list) have had different perceptions on both (a) what's >> important >> > >>>>>>> and (b) what kind of graphics they're interested in. Most >> > >>>>>>> people would deride the dancing cat as being totally >> > >>>>>>> irrelevant to the types of applications they're trying to >> > >>>>>>> build (the basis for >> much >> > >>>> of >> > >>>>>>> flash animations is shape >> > >>>>>> morphing, >> > >>>>>>> you can find some code here >> > >>>> https://gist.github.com/gontard/5029764). >> > >>>>>>> >> > >>>>>>> On the other hand, JavaFX is not a replacement for OpenGL. >> Drawing >> > >>>>>>> 25 million lines is just not something we can do right now, >> > >>>>>>> especially in a resource constrained environment. I've >> > >>>>>>> already commented on the memory overhead (which would >> > >>>>>>> continue to be an issue even if the drawing part of the problem were solved). >> > >>>>>>> >> > >>>>>>> I've pushed to graphics repo the StretchyGrid, which is >> > >>>>>>> about >> 300k >> > >>>>>>> line nodes (the actual amount is variable, see the javadoc >> > >>>>>>> comments). At 300k nodes the scene graph overhead is >> > >>>>>>> negligible >> on >> > >>>>>>> the FX side, dirty opts >> > >>>>>> is >> > >>>>>>> taking a long time to run, and painting is really slow. >> > >>>>>>> >> > >>>>>>> PULSE: 347 [122ms:222ms] >> > >>>>>>> T12 (8 +0ms): CSS Pass >> > >>>>>>> T12 (8 +0ms): Layout Pass >> > >>>>>>> T12 (47 +53ms): Waiting for previous rendering >> > >>>>>>> T12 (100 +1ms): Copy state to render graph >> > >>>>>>> T10 (101 +16ms): Dirty Opts Computed >> > >>>>>>> T10 (117 +105ms): Painted >> > >>>>>>> Counters: >> > >>>>>>> Nodes rendered: 306565 >> > >>>>>>> Nodes visited during render: 306565 >> > >>>>>>> >> > >>>>>>> If I were doing this by hand in open GL, I think the >> > >>>>>>> drawing >> would >> > >>>>>>> be essentially free, if I used LINES with GL anti-aliasing, >> > >>>>>>> I >> could >> > >>>> >> > >>>>>>> send 'em all down to the card in a single shot (and if I >> > >>>>>>> had a modern GL I could >> > >>>>>> do >> > >>>>>>> LINES + FXAA or one of the other per-pixel AA algorithms >> available >> > >>>>>>> and it would turn out pretty nice). Because our shapes >> > >>>>>>> don't implement the >> > >>>>>> non-AA >> > >>>>>>> path, and our AA involves software rasterization and >> > >>>>>>> uploading >> of >> > >>>>>> pixels, I >> > >>>>>>> expect that to be the main source of the 105ms time being >> > >>>>>>> spent >> > >>>> here. >> > >>>>>>> >> > >>>>>>> Also I noticed (by turning on prism.showdirty=true) that >> > >>>>>>> the >> entire >> > >>>> >> > >>>>>>> grid >> > >>>>>> is >> > >>>>>>> being painted every time, even though visually it looks >> > >>>>>>> like >> only a >> > >>>> >> > >>>>>>> small subset actually needs to be changed. But that's >> > >>>>>>> really a >> > >>>> minor >> > >>>>>>> thing, as >> > >>>>>> I >> > >>>>>>> said, drawing this many lines should basically be free if I >> > >>>>>>> configure "smooth" to false in the app. Except that right >> > >>>>>>> now >> it is >> > >>>> >> > >>>>>>> totally not implemented (in NGShape): >> > >>>>>>> >> > >>>>>>> public void setAntialiased(boolean aa) { >> > >>>>>>> // We don't support aliased shapes at this time } >> > >>>>>>> >> > >>>>>>> The point of stretchy grid is not to say "wow look at this >> amazing >> > >>>> demo". >> > >>>>>>> The point is to say "what happens if I put in 300K nodes. >> > >>>>>>> Where >> > >>>> does >> > >>>>>>> the system start to fall over?". >> > >>>>>>> >> > >>>>>>> Richard= >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>> >> > >>>>> >> > >>>>> -- >> > >>>>> Pedro Duque Vieira >> > >> >> > > >> > >> > >> > > > > -- > 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 Tue Aug 6 06:03:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 13:03:03 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130806130415.539D148602@hg.openjdk.java.net> Changeset: 5a2bdb89b8a1 Author: hudson Date: 2013-08-01 08:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5a2bdb89b8a1 Added tag 8.0-b101 for changeset fe19fc3820f3 ! .hgtags Changeset: 1881571d12e6 Author: mv157916 Date: 2013-08-02 00:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1881571d12e6 RT-32076: Update the JDK build number to b101 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: d0ecfb9f77d6 Author: David Grieve Date: 2013-08-06 08:57 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d0ecfb9f77d6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java From artem.ananiev at oracle.com Tue Aug 6 06:10:52 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 06 Aug 2013 17:10:52 +0400 Subject: A different way to handle pulse timing In-Reply-To: References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> <51FFED2B.3050105@Oracle.com> Message-ID: <5200F5DC.3020406@oracle.com> On 8/5/2013 10:26 PM, Richard Bair wrote: >>>> In the past we have seen situations where there are so many >>>> tasks on the user event thread, that user response (even on >>>> desktop) was not acceptable. Some of these items are getting >>>> better as we improve design (ie less redundant layout >>>> operations causes by a single change/event). >>> Right, but I don't see how that could still happen in this >>> proposal? The problem before was the pulse events were handled >>> outside of the event queue (as I recall) so that they got higher >>> priority. We got rid of the higher priority and starvation >>> ceased. This proposal would not reintroduce priorities, so I >>> don't see how you could end up with input event starvation >>> again? >> rendering is "staged" on the event queue (layout, adding the render >> job to the render thread). It has been this way for quite a while >> now. As far as I remember,( other than paths with "live resize"), >> we have never had a mechanism that provided for event priority (at >> least not on the Linux side where I tend to live). > > This is how I thought it used to be done: we had (still have) a > separate glass thread which fires off once ever 16ms or so. We used > to take this pulse and handle it at the next available opportunity, > which was explicit prioritization. If the pulse handling took longer > than 16ms, by the time the pulse ended we'd have another pulse ready > to be handled and would starve the queue. Today, we get this event > and add it to the event queue, so we are never starving the event > queue. > > In this proposal, we also would be putting the next pulse on the end > of the queue, so it is impossible to starve input events. Putting the next pulse on the end of the queue is surprisingly difficult task, at least on Windows. If we use standard APIs provided by the platform, PostMessage() and SendMessage(), events are always put to the head of the queue. If we use timer events, they are of the lowest priority, so we'll have "paint starvation" instead of "input events starvation". Thanks, Artem > Thanks > Richard From artem.ananiev at oracle.com Tue Aug 6 06:13:34 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 06 Aug 2013 17:13:34 +0400 Subject: A different way to handle pulse timing In-Reply-To: <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> Message-ID: <5200F67E.8060807@oracle.com> On 8/5/2013 9:09 PM, Richard Bair wrote: >> In the past we have seen situations where there are so many tasks >> on the user event thread, that user response (even on desktop) was >> not acceptable. Some of these items are getting better as we >> improve design (ie less redundant layout operations causes by a >> single change/event). > > Right, but I don't see how that could still happen in this proposal? > The problem before was the pulse events were handled outside of the > event queue (as I recall) so that they got higher priority. We got > rid of the higher priority and starvation ceased. This proposal would > not reintroduce priorities, so I don't see how you could end up with > input event starvation again? Here is that bug: RT-20656: Pending requests from Application.invokeLater can cause input event starvation It is indeed fixed, but the fix was to make sure we always have a window to dispatch input events (sometimes, very small, but still). Higher priority for user/application runnables is still there. Thanks, Artem >> BTW - it is very easy to write a "bad" app which will demonstrate >> the problem. As a thought example - if on a button click, you >> calculate PI to the nth digit before updating your text field - and >> you do it in the event callback - you are stalling the user event >> thread. Add in enough computes and you get an very unresponsive >> app. Instead of computes, you can just call sleep to see the >> problem too :-) > > But this is the case today as well. > > Richard > From jmartine_1026 at yahoo.com Tue Aug 6 06:36:31 2013 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Tue, 6 Aug 2013 06:36:31 -0700 (PDT) Subject: TD game (hijacking Re: Performant Controls (hijacking Re: Developing controls based on Canvas?)) In-Reply-To: References: <52004AB2.3050800@oracle.com> <0B1BEB6D-7FD1-4894-ADBC-26C13D63217D@oracle.com> Message-ID: <1375796191.43741.YahooMailNeo@web161504.mail.bf1.yahoo.com> I'm pretty burnt myself but it remains in the back of my mind and I will be devoting some effort to it. ?I think this is a good email to spark me to go and work on it. ?Before August is out will work on it. Thanks!? jose ________________________________ From: Daniel Zwolenski To: Richard Bair Cc: "openjfx-dev at openjdk.java.net List" Sent: Tuesday, August 6, 2013 1:32 AM Subject: Re: TD game (hijacking Re: Performant Controls (hijacking Re: Developing controls based on Canvas?)) I'm out for that one for the foreseeable future. I've burnt up any and all "free" time on getting the desktop and iOS workflows working with Maven. I'm big time behind on client work. Tell you what though, if you can get someone at Oracle to take over the deployment tools and iOS stuff, I'd very happily switch over to building games and gliffy-like demo apps :) On Tue, Aug 6, 2013 at 3:02 PM, Richard Bair wrote: > It really wasn't ever supposed to be my TD game, I keep trying to get you > (and others interested in the community) to develop it. I'm up to my > eyeballs in work already, as I'm sure you can relate :-) > > Richard > > On Aug 5, 2013, at 9:24 PM, Daniel Zwolenski wrote: > > You should be able to check out they work in your TD game and continue > development on that then. > > > On Tue, Aug 6, 2013 at 2:16 PM, Richard Bair wrote: > >> > To add >> > to the confusion, Canvas currently has some drastic z-order bugs, and >> some >> > clipping issues, so using it combined with Nodes is currently a no-go. >> >> I believe those have all been fixed in the last couple of weeks. >> >> Richard >> > > > From swpalmer at gmail.com Tue Aug 6 07:07:50 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 6 Aug 2013 10:07:50 -0400 Subject: A different way to handle pulse timing In-Reply-To: <5200F5DC.3020406@oracle.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> <51FFED2B.3050105@Oracle.com> <5200F5DC.3020406@oracle.com> Message-ID: <1F338AC8-2873-44F6-A727-AD7CC8C8DB44@gmail.com> On 2013-08-06, at 9:10 AM, Artem Ananiev wrote: > > On 8/5/2013 10:26 PM, Richard Bair wrote: >> >> In this proposal, we also would be putting the next pulse on the end >> of the queue, so it is impossible to starve input events. > > Putting the next pulse on the end of the queue is surprisingly difficult task, at least on Windows. If we use standard APIs provided by the platform, PostMessage() and SendMessage(), events are always put to the head of the queue. If we use timer events, they are of the lowest priority, so we'll have "paint starvation" instead of "input events starvation". If the OS message queue is fundamentally broken (i.e. it does not behave like a queue), can all this be done on a proper queue that you have control over? I.e. in the OS-specific message loop, just move the messages to a more reasonably behaved queue. Posting a request to process a pulse would simply queue the operation on the well behaved queue and not use the OS PostMessage or SendMessage mechanism at all. I admit to not knowing enough about Windows message processing to know if that even makes sense. (Windows seriously doesn't have a mechanism to put something on the tail end of the message queue? Wow, don't they understand how a "queue" is supposed to work?) Scott From hang.vo at oracle.com Tue Aug 6 07:17:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 14:17:47 +0000 Subject: hg: openjfx/8/graphics/rt: Fix to RT-30270: FX 8 3D: dirtyopts doesn't work for 3D rendering Message-ID: <20130806141822.D18E64860C@hg.openjdk.java.net> Changeset: 891fda941088 Author: Chien Yang Date: 2013-08-06 07:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/891fda941088 Fix to RT-30270: FX 8 3D: dirtyopts doesn't work for 3D rendering Reviewed by Kevin + apps/toys/FX8-3DFeatures/src/fx83dfeatures/LightMotion.java ! modules/graphics/src/main/java/javafx/scene/LightBase.java From artem.ananiev at oracle.com Tue Aug 6 07:51:57 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 06 Aug 2013 18:51:57 +0400 Subject: A different way to handle pulse timing In-Reply-To: <1F338AC8-2873-44F6-A727-AD7CC8C8DB44@gmail.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> <51FFED2B.3050105@Oracle.com> <5200F5DC.3020406@oracle.com> <1F338AC8-2873-44F6-A727-AD7CC8C8DB44@gmail.com> Message-ID: <52010D8D.1040008@oracle.com> On 8/6/2013 6:07 PM, Scott Palmer wrote: > > On 2013-08-06, at 9:10 AM, Artem Ananiev wrote: > >> On 8/5/2013 10:26 PM, Richard Bair wrote: >>> >>> In this proposal, we also would be putting the next pulse on the >>> end of the queue, so it is impossible to starve input events. >> >> Putting the next pulse on the end of the queue is surprisingly >> difficult task, at least on Windows. If we use standard APIs >> provided by the platform, PostMessage() and SendMessage(), events >> are always put to the head of the queue. If we use timer events, >> they are of the lowest priority, so we'll have "paint starvation" >> instead of "input events starvation". > > If the OS message queue is fundamentally broken (i.e. it does not > behave like a queue), can all this be done on a proper queue that you > have control over? I wouldn't say it's broken :) It's implemented this way by design. BTW, as far as I know, Mac OS X is similar to Windows wrt event handling: all the selectors (correspond to PostMessage() and SendMessage()) are processed before input events. > I.e. in the OS-specific message loop, just move the messages to a > more reasonably behaved queue. Posting a request to process a pulse > would simply queue the operation on the well behaved queue and not > use the OS PostMessage or SendMessage mechanism at all. I admit to > not knowing enough about Windows message processing to know if that > even makes sense. What you describe is close to how JavaFX is implemented on embedded platforms. See Lens code in Glass for details. We do this, because on that platforms there is virtually no native event queue, so we have our own. However, on platforms like Windows or Mac OS X, we have to use native event queues, otherwise JavaFX apps won't be good citizens there. This is what we have in AWT/Swing, where a native event queue is separate from Java event queue. I can't say the exact number of minor (e.g. sluggish window resizing), major (dragndrop not working), and even fatal (JVM crashes) issues we fixed in AWT, that were caused by this architecture with 2 queues, but believe me this number is huge. > (Windows seriously doesn't have a mechanism to put something on the > tail end of the message queue? Wow, don't they understand how a > "queue" is supposed to work?) Why do you think it must be a queue? :) It can be a queue, but it can be something more complex as well. And yes, there is no easy way to put an event to the tail of the queue on Windows. What we can do is to put events to the queue with PostMessage/SendMessage, but dequeue them in different order. We prototyped that in the past, but didn't find it acceptable. Thanks, Artem > Scott From David.Hill at Oracle.com Tue Aug 6 08:15:35 2013 From: David.Hill at Oracle.com (David Hill) Date: Tue, 06 Aug 2013 11:15:35 -0400 Subject: CFV: New OpenJFX Committer:Daniel Blaukopf Message-ID: <52011317.6020006@Oracle.com> I hereby nominate Daniel Blaukopf to OpenJFX Committer. Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the "embedded device" space. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf Votes are due by Aug 21, 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]. Thanks, David [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus From David.Hill at Oracle.com Tue Aug 6 08:16:52 2013 From: David.Hill at Oracle.com (David Hill) Date: Tue, 06 Aug 2013 11:16:52 -0400 Subject: CFV: New OpenJFX Committer: Seeon Birger Message-ID: <52011364.4050207@Oracle.com> I hereby nominate Seeon Birger to OpenJFX Committer. Seeon is a member of the Embedded Device team, which means he works across various aspects of the platform, but in particular, Lens and Virtual Keyboard. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=seeon.birger Votes are due by Aug 21, 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]. Thanks, Dave [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus From artem.ananiev at oracle.com Tue Aug 6 08:29:56 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 06 Aug 2013 19:29:56 +0400 Subject: CFV: New OpenJFX Committer:Daniel Blaukopf In-Reply-To: <52011317.6020006@Oracle.com> References: <52011317.6020006@Oracle.com> Message-ID: <52011674.50105@oracle.com> Vote: yes. Artem On 8/6/2013 7:15 PM, David Hill wrote: > I hereby nominate Daniel Blaukopf to OpenJFX Committer. > Daniel is a member of the Embedded Device team, which means he works > across various aspects of the platform. He is also the architect for the > "embedded device" space. > > His recent work can be seen here: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf > > Votes are due by Aug 21, 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]. > > Thanks, > David > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus From hang.vo at oracle.com Tue Aug 6 08:32:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 15:32:58 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20130806153345.8AF034860F@hg.openjdk.java.net> Changeset: 1661f722d536 Author: Vasiliy Baranov Date: 2013-08-06 19:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1661f722d536 Fix Mac build broken by the recent fix for RT-32039 ! modules/web/src/main/native/Source/WebCore/mapfile-macosx ! modules/web/src/main/native/Source/WebCore/mapfile-vers Changeset: 59419bdda806 Author: Felipe Heidrich Date: 2013-08-06 08:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/59419bdda806 RT-27541: Add RTL support to TextFlow ! modules/graphics/src/main/java/javafx/scene/text/TextFlow.java Changeset: 0a2b4115d537 Author: Felipe Heidrich Date: 2013-08-06 08:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0a2b4115d537 Removing out-of-date comment in checkOrientation + dosmetic changes (trailing whitespace) ! modules/graphics/src/main/java/javafx/scene/text/Text.java From David.Hill at Oracle.com Tue Aug 6 08:41:07 2013 From: David.Hill at Oracle.com (David Hill) Date: Tue, 06 Aug 2013 11:41:07 -0400 Subject: A different way to handle pulse timing In-Reply-To: <1F338AC8-2873-44F6-A727-AD7CC8C8DB44@gmail.com> References: <368C21A9-8C2D-4138-AA1E-8B1155B8A996@oracle.com> <51FA5296.2050009@oracle.com> <51FFAD0B.9040300@Oracle.com> <1D6BFF01-A647-40B0-81B5-0C2DF5C63B4B@gmail.com> <51FFD7B4.3010003@Oracle.com> <11888F65-3CC0-4C6B-8DAC-6AC6DEC3F0E0@oracle.com> <51FFED2B.3050105@Oracle.com> <5200F5DC.3020406@oracle.com> <1F338AC8-2873-44F6-A727-AD7CC8C8DB44@gmail.com> Message-ID: <52011913.5000902@Oracle.com> On 8/6/13 Aug 6, 10:07 AM, Scott Palmer wrote: > > On 2013-08-06, at 9:10 AM, Artem Ananiev wrote: > >> On 8/5/2013 10:26 PM, Richard Bair wrote: >>> In this proposal, we also would be putting the next pulse on the end >>> of the queue, so it is impossible to starve input events. >> Putting the next pulse on the end of the queue is surprisingly difficult task, at least on Windows. If we use standard APIs provided by the platform, PostMessage() and SendMessage(), events are always put to the head of the queue. If we use timer events, they are of the lowest priority, so we'll have "paint starvation" instead of "input events starvation". > If the OS message queue is fundamentally broken (i.e. it does not behave like a queue), can all this be done on a proper queue that you have control over? > I.e. in the OS-specific message loop, just move the messages to a more reasonably behaved queue. Posting a request to process a pulse would simply queue the operation on the well behaved queue and not use the OS PostMessage or SendMessage mechanism at all. I admit to not knowing enough about Windows message processing to know if that even makes sense. > (Windows seriously doesn't have a mechanism to put something on the tail end of the message queue? Wow, don't they understand how a "queue" is supposed to work?) This is what Glass/Lens does - the user event thread is all in Java. But then - we also don't have to deal with any pesky native window managers :-) Lens input events are taken from as close as we have to a native event loop (on an input thread) and posted to the java based user event thread, just like any other Application.InvokeLater (first in, first out queue). This also saves Lens a bit of JNI handling as most user (non input events) never leave java this way. Dave > > Scott > -- David Hill Java Embedded Development "Sometimes the questions are complicated and the answers are simple." -- Dr. Seuss (1904 - 1991) From david.grieve at oracle.com Tue Aug 6 08:49:57 2013 From: david.grieve at oracle.com (David Grieve) Date: Tue, 6 Aug 2013 11:49:57 -0400 Subject: CFV: New OpenJFX Committer:Daniel Blaukopf In-Reply-To: <52011317.6020006@Oracle.com> References: <52011317.6020006@Oracle.com> Message-ID: <710AD4F3-813F-46D8-8EA1-3F61A0D78C05@oracle.com> Vote: YES On Aug 6, 2013, at 11:15 AM, David Hill wrote: > I hereby nominate Daniel Blaukopf to OpenJFX Committer. > Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the "embedded device" space. > > His recent work can be seen here: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf > > Votes are due by Aug 21, 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]. > > Thanks, > David > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus From kevin.rushforth at oracle.com Tue Aug 6 08:51:04 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Aug 2013 08:51:04 -0700 Subject: CFV: New OpenJFX Committer:Daniel Blaukopf In-Reply-To: <52011317.6020006@Oracle.com> References: <52011317.6020006@Oracle.com> Message-ID: <52011B68.2030602@oracle.com> Vote: yes David Hill wrote: > I hereby nominate Daniel Blaukopf to OpenJFX Committer. > Daniel is a member of the Embedded Device team, which means he works > across various aspects of the platform. He is also the architect for > the "embedded device" space. > > His recent work can be seen here: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf > > Votes are due by Aug 21, 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]. > > Thanks, > David > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus From kevin.rushforth at oracle.com Tue Aug 6 08:51:10 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Aug 2013 08:51:10 -0700 Subject: CFV: New OpenJFX Committer: Seeon Birger In-Reply-To: <52011364.4050207@Oracle.com> References: <52011364.4050207@Oracle.com> Message-ID: <52011B6E.1000505@oracle.com> Vote: yes David Hill wrote: > I hereby nominate Seeon Birger to OpenJFX Committer. > Seeon is a member of the Embedded Device team, which means he works > across various aspects of the platform, but in particular, Lens and > Virtual Keyboard. > > His recent work can be seen here: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=seeon.birger > > Votes are due by Aug 21, 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]. > > Thanks, > Dave > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus From debra.masada at oracle.com Tue Aug 6 09:19:00 2013 From: debra.masada at oracle.com (Debra Masada) Date: Tue, 6 Aug 2013 09:19:00 -0700 Subject: Brick Breaker ball jitter In-Reply-To: References: Message-ID: Hi John, Sorry, the Brick Breaker fix is not yet in Ensemble8. The fix is in the standalone version of Brick Breaker. The Jira issue for the port is RT-30864. Thanks, Debbie > Message: 4 > Date: Tue, 6 Aug 2013 20:41:45 +1000 > From: "John C. Turnbull" > Subject: Brick Breaker ball jitter > To: > Message-ID: <008601ce9291$8c016d20$a4044760$@ozemail.com.au> > Content-Type: text/plain; charset="us-ascii" > > I seem to remember some time ago that work was done on reducing the jitter > in the ball's motion in the Brick Breaker demo in Ensemble8. > > > > Did this ever make it into the main line? I ask because I have just > installed JDK 8 b101 and the ball still shows very significant jitter in its > motion on this Windows 7 x64 machine. > > > > Thanks, > > > > -jct > From jasper.potts at oracle.com Tue Aug 6 09:44:59 2013 From: jasper.potts at oracle.com (Jasper Potts) Date: Tue, 6 Aug 2013 09:44:59 -0700 Subject: CFV: New OpenJFX Committer:Daniel Blaukopf In-Reply-To: <52011317.6020006@Oracle.com> References: <52011317.6020006@Oracle.com> Message-ID: <8A7D127E-A394-498C-9B21-369961F4DB02@oracle.com> Vote: yes. Jasper On Aug 6, 2013, at 8:15 AM, David Hill wrote: > I hereby nominate Daniel Blaukopf to OpenJFX Committer. > Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the "embedded device" space. > > His recent work can be seen here: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf > > Votes are due by Aug 21, 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]. > > Thanks, > David > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus From david.dehaven at oracle.com Tue Aug 6 09:58:30 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 6 Aug 2013 09:58:30 -0700 Subject: CFV: New OpenJFX Committer:Daniel Blaukopf In-Reply-To: <52011317.6020006@Oracle.com> References: <52011317.6020006@Oracle.com> Message-ID: Vote: yes -DrD- On Aug 6, 2013, at 8:15 AM, David Hill wrote: > I hereby nominate Daniel Blaukopf to OpenJFX Committer. > Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the "embedded device" space. > > His recent work can be seen here: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf > > Votes are due by Aug 21, 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]. > > Thanks, > David > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus From richard.bair at oracle.com Tue Aug 6 10:01:10 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Aug 2013 10:01:10 -0700 Subject: CFV: New OpenJFX Committer:Daniel Blaukopf In-Reply-To: <52011317.6020006@Oracle.com> References: <52011317.6020006@Oracle.com> Message-ID: <0EB36FA9-4E09-4A65-A7E6-D49A47297728@oracle.com> Vote: yes On Aug 6, 2013, at 8:15 AM, David Hill wrote: > I hereby nominate Daniel Blaukopf to OpenJFX Committer. > Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the "embedded device" space. > > His recent work can be seen here: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf > > Votes are due by Aug 21, 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]. > > Thanks, > David > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus From richard.bair at oracle.com Tue Aug 6 10:04:21 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Aug 2013 10:04:21 -0700 Subject: CFV: New OpenJFX Committer: Seeon Birger In-Reply-To: <52011364.4050207@Oracle.com> References: <52011364.4050207@Oracle.com> Message-ID: <92FD73D1-095D-425B-8D10-607A1603BA39@oracle.com> Vote: yes On Aug 6, 2013, at 8:16 AM, David Hill wrote: > I hereby nominate Seeon Birger to OpenJFX Committer. > Seeon is a member of the Embedded Device team, which means he works across various aspects of the platform, but in particular, Lens and Virtual Keyboard. > > His recent work can be seen here: > > http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=seeon.birger > > Votes are due by Aug 21, 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]. > > Thanks, > Dave > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus From hang.vo at oracle.com Tue Aug 6 10:33:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 17:33:22 +0000 Subject: hg: openjfx/8/graphics/rt: 40 new changesets Message-ID: <20130806174347.257284861B@hg.openjdk.java.net> Changeset: 5a2bdb89b8a1 Author: hudson Date: 2013-08-01 08:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5a2bdb89b8a1 Added tag 8.0-b101 for changeset fe19fc3820f3 ! .hgtags Changeset: 1881571d12e6 Author: mv157916 Date: 2013-08-02 00:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1881571d12e6 RT-32076: Update the JDK build number to b101 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 02439ac5011b Author: jgiles Date: 2013-07-30 12:32 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/02439ac5011b RT-31577: Clearing the selection in TableView doesn't call ChangeListener on SelectionModel selectedItemProperty ! 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/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: 908485f56f7f Author: jgiles Date: 2013-07-30 15:22 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/908485f56f7f RT-30253: [TreeView] graphics is not rendered immediately when prebuilt cell factory is used. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: be80dfafbd68 Author: jgiles Date: 2013-07-30 15:38 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/be80dfafbd68 RT-30754: ComboBox doesn't align properly with baseline ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java Changeset: f0fb93f22f9b Author: jgiles Date: 2013-07-31 09:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f0fb93f22f9b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 60e14d6f298e Author: jgiles Date: 2013-07-31 10:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/60e14d6f298e RT-31570: Make some VirtualFlow method protected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 0b89acf5c119 Author: jgiles Date: 2013-07-31 11:26 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0b89acf5c119 RT-31901: Regression: scrollbar issue with TitledPane ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 32a15e40d649 Author: jgiles Date: 2013-07-31 12:23 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/32a15e40d649 RT-31997: ChoiceBox and ComboBox popup menu appear shifted vertically (by ~5px) ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! modules/graphics/src/main/java/com/sun/javafx/Utils.java Changeset: 4f3014d423e9 Author: jgiles Date: 2013-07-31 14:10 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4f3014d423e9 Partial fix for RT-31918: ComboBox doesn't render scroll bars The exception listed in the jira issue no longer occurs. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 6ac8a1f0708d Author: jgiles Date: 2013-07-31 14:36 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6ac8a1f0708d RT-30400: ProgressBar cell factory renders progress bars in empty cells ! modules/controls/src/main/java/javafx/scene/control/cell/ProgressBarTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ProgressBarTreeTableCell.java ! modules/controls/src/test/java/javafx/scene/control/cell/ProgressBarTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ProgressBarTreeTableCellTest.java Changeset: 1468c900ae93 Author: jgiles Date: 2013-07-31 14:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1468c900ae93 RT-30394: TreeTableView focus model returns wrong focused index ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.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/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java Changeset: 30bec5fde344 Author: jgiles Date: 2013-07-31 15:17 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/30bec5fde344 RT-25975: [DOC] : Class SkinBase needs to be documented ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java Changeset: a8987ec491ac Author: jgiles Date: 2013-08-01 10:02 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a8987ec491ac RT-30156: Sorting a table column leaves the selection model inconsistent with the display in the UI ! modules/controls/src/main/java/javafx/scene/control/ListView.java ! 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/TreeItem.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java Changeset: 4d59d24f0d8b Author: mickf Date: 2013-08-01 14:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4d59d24f0d8b RT-30871 : indeterminate progress bar causes memory leak ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 3aadad7d5904 Author: mickf Date: 2013-08-01 14:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3aadad7d5904 RT-27791 :ProgressBar keeps animating when in ScrollPane and scrolled out of view ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 42157cdefd1a Author: mickf Date: 2013-08-01 16:35 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/42157cdefd1a RT-31661 : Docs : Missing description in ScrollBar API - in constructor ! modules/controls/src/main/java/javafx/scene/control/ScrollBar.java Changeset: d9f804166732 Author: mickf Date: 2013-08-01 17:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d9f804166732 Revert DefaultTreeCell name change to enable building ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: d4657711e052 Author: jgiles Date: 2013-08-02 08:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d4657711e052 Backed out changeset: d9f804166732 ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: 970027341fc2 Author: jgiles Date: 2013-08-02 08:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/970027341fc2 Adding in missing DefaultTreeCell impl + modules/controls/src/main/java/javafx/scene/control/cell/DefaultTreeCell.java Changeset: 72059831a447 Author: rbair Date: 2013-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/72059831a447 Minor Intellij project update ! .idea/vcs.xml Changeset: 7b779c15ce73 Author: rbair Date: 2013-08-01 18:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7b779c15ce73 RT-24400: Incorrect work ctrl+backspace and ctrl+delete in TextArea. Summary: The problem is that the nextWord / previousWord methods on TextInputControl did not correctly handle cases where numbers are in the stream of characters. There may be additional issues related to symbols and how breaking should occur. Also some of this might be OS specific (on Mac it breaks in some places, on Windows someplace else). However this should fix the SQE tests. ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/test/java/javafx/scene/control/TextInputControlTest.java Changeset: a4d7b7b2daa2 Author: rbair Date: 2013-08-02 09:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a4d7b7b2daa2 Made some fields final, fixed a javadoc issue. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: 97ff822bb664 Author: rbair Date: 2013-08-02 09:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/97ff822bb664 Removed EMPTY_BINDINGS and use instead Collections.emptyList(). One less field, but more important, the EMPTY_BINDINGS wasn't immutable so there was a possibility of a bug there, whereas now there is not. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: a01a090e0477 Author: rbair Date: 2013-08-02 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a01a090e0477 RT-32102: TreeView on Mac does not use cmd+ctrl+space for toggling selection ! 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: 226250c9e7f9 Author: rbair Date: 2013-08-02 11:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/226250c9e7f9 Minor fixes to BehaviorBase. Made convenience traverse methods final, all pointing to the single non-final method that does all the work. Made sure the keyBindings field is unmodifiable. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: 44af70149f3b Author: rbair Date: 2013-08-02 14:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/44af70149f3b RT-32103: Behaviors should remove listeners when Skin is disposed. I believe this is mostly complete other than for TableViewBehavior and TreeTableViewBehavior. Tests forthcoming. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboBehavior.java - modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusListBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusPopupBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java + modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/AccordionBehaviorTest.java + modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java Changeset: e8ccb3fa27cc Author: rbair Date: 2013-08-02 20:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e8ccb3fa27cc RT-32110: Cleanup BehaviorBase by passing key bindings in the constructor ! apps/experiments/ConferenceScheduleApp/src/main/java/com/javafx/experiments/scheduleapp/control/VirtualKeyboardSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ColorPickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DatePickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/MenuButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/MenuButtonBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ProgressBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ProgressIndicatorBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SplitMenuButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.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/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TitledPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ToolBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabelSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SeparatorSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/BehaviorSkinBaseTest.java ! modules/web/src/main/java/com/sun/javafx/scene/web/behavior/HTMLEditorBehavior.java ! modules/web/src/main/java/com/sun/javafx/webkit/theme/RenderThemeImpl.java Changeset: 5c98da320f07 Author: rbair Date: 2013-08-02 21:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5c98da320f07 Remove unused method from BehaviorBase ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: 2f80082e42ef Author: rbair Date: 2013-08-05 13:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2f80082e42ef Added some more tests for BehaviorBase, added comments to BehaviorBase. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java Changeset: 0dc911479304 Author: rbair Date: 2013-08-05 13:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0dc911479304 Reduced redundant method invocations in TabPaneBehavior. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TraversalEngine.java Changeset: b939cc31d31c Author: rbair Date: 2013-08-05 14:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b939cc31d31c Added tests to test BehaviorBase focus / mouse events are handled correctly ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java ! modules/controls/src/test/java/javafx/scene/control/ButtonTest.java ! modules/controls/src/test/java/javafx/scene/control/ColorPickerTest.java Changeset: 5752e8bc7cb7 Author: jgiles Date: 2013-08-05 15:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5752e8bc7cb7 RT-19487: TableView: Support returning to unsorted state. For more information, I blogged about this feature here: http://fxexperience.com/2013/08/returning-a-tableview-back-to-an-unsorted-state-in-javafx-8-0/ ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java Changeset: 83a5c0ffd155 Author: jgiles Date: 2013-08-06 10:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/83a5c0ffd155 RT-30484: updateItem is not called at startup on virtualised controls, leading to invalid graphical states. ! 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/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.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: 905b63f0c057 Author: jgiles Date: 2013-08-06 10:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/905b63f0c057 RT-31907: Cleanup control code (part seven: generics cleanup for TableView / TreeTableView skin code) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.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/TreeTableViewSkin.java Changeset: 2a33523022aa Author: jgiles Date: 2013-08-06 11:30 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2a33523022aa RT-31907: Cleanup control code (part eight: Small TreeTableRow cleanup) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java Changeset: cecdbd12e168 Author: jgiles Date: 2013-08-06 11:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cecdbd12e168 RT-31907: Cleanup control code (part nine: Clean up generic warnings in TableRow) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TableRow.java Changeset: 3268003fe9c0 Author: jgiles Date: 2013-08-06 13:11 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3268003fe9c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java Changeset: d0ecfb9f77d6 Author: David Grieve Date: 2013-08-06 08:57 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d0ecfb9f77d6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java Changeset: 324f1d41fc48 Author: kcr Date: 2013-08-06 10:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/324f1d41fc48 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/CheckBoxTableCell.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/EditingCell.java - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupScene.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupStage.java - netbeans/android/glass-lib-lens/Android.mk - netbeans/android/glass-lib-lens/nbproject/configurations.xml - netbeans/android/glass-lib-lens/nbproject/project.xml From hang.vo at oracle.com Tue Aug 6 13:47:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 06 Aug 2013 20:47:26 +0000 Subject: hg: openjfx/8/graphics/rt: Fix to RT-32129: Light's scope optimization Message-ID: <20130806204757.51EE54862D@hg.openjdk.java.net> Changeset: 2fa94a5ed08f Author: Chien Yang Date: 2013-08-06 13:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2fa94a5ed08f Fix to RT-32129: Light's scope optimization Reviewed by Kevin and Thor ! modules/graphics/src/main/java/com/sun/javafx/scene/DirtyBits.java ! modules/graphics/src/main/java/javafx/scene/LightBase.java From pedro.duquevieira at gmail.com Tue Aug 6 15:43:17 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 6 Aug 2013 23:43:17 +0100 Subject: Swing and JavaFX thread merge Message-ID: Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance, -- Pedro Duque Vieira From John_Smith at symantec.com Tue Aug 6 16:49:57 2013 From: John_Smith at symantec.com (John Smith) Date: Tue, 6 Aug 2013 16:49:57 -0700 Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) In-Reply-To: References: Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221685BF5BE2@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > . . . imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general strategy? I'd use some like yworks yfiles for this, it seems pretty similar => http://www.yworks.com/en/products_yfiles_practicalinfo_gallery.html (this page is a very nice example of a showcase by the way :-) Sebastian Rheinnecker from yworks created a prototype of their tool in JavaFX. He has posted on this list before, so you can find his email in the archives if you want to ask questions about it. The yworks stuff is a very nice graphing system that scales to very large graphs and is implemented in lots of different technologies, so perhaps a good contact point if they are willing to discuss implementation details. There is also the primarily JavaFX based Dex Data Explorer which also seems pretty similar (albeit using a polyglot programming approach) => http://www.javainc.com/projects/dex/ -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Monday, August 05, 2013 5:39 PM To: Jonathan Giles Cc: openjfx-dev at openjdk.java.net List Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) Sneaking in here, as you've given an opening with "if implemented wisely, there is very little that a scenegraph-based approach can't do". The question I've been asking for a while is what does "implemented wisely" look like in JFX. This has come up in the performance conversations, the game conversations, the CAD conversations, and many other places. No one seems to have an answer, but you're building extremely complex stuff on a regular basis - what's your tips? When you say you only have "20 visible nodes" out of 1000's in general are the other nodes: a) in the scenegraph and set to not visible b) in memory but not in the scenegraph - added/removed when scrolled into view and out of view c) not in memory, created, added and then removed, destroyed when scrolled into view and out of view d) something else? I know Table uses a rubber stamp approach, where it re-uses cell views where possible, but let's say every row in my 100,000 row Table was uniquely rendered using a different cell. What would happen under the covers? How do you work out the scroll range as well? Each cell can be a unique height right? How do you know the extents of the vertical scrolling without instantiating and rendering everything? Is this what you do? What if a cell is changing size (has a collapsable pane in it, etc) - what happens to the vertical scroll range? Do any of the controls have zooming on them? Have you had to deal with this and have you got a strategy for handling this with respect to scroll bounds, working out which nodes are in view, scaling fonts, etc? Could you hazard a guess at what you would do if you had to implement zooming on a Table for example? Maybe the Table is lucky with its restrictive grid like layout but imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general strategy? On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles wrote: > I think it would pay to take a step back and understand why you think > a 'traditional' scenegraph-based (or retained mode) control is not > sufficient for your needs? > Unfortunately you've not detailed your use case, so it is hard to give > any specific advice. Are you able to give any details about what it is > you're trying to build and why you think the normal approach to > building controls is not sufficient? > > We've built some fairly complex controls using this approach, and if > implemented wisely, there is very little that a scenegraph-based > approach can't do. Specifically, do you think your control will render > all of the 'thousands of nodes' at once, or will many of these nodes > be off screen or otherwise not visible at any one time? For things > like the TableView we only render the nodes that are visible. This > means that regardless of whether there are 100 or 1,000,000 rows of > data, we only have visual nodes for the 20 visible rows, for example. > Keeping your scenegraph as minimal as possible is always a very wise idea, if performance is a concern. > > As you note, the other problem is that you will run into issues if you > want to mix canvas rendering with the scenegraph-based controls like > Button. The best you're likely to achieve (having not tried it > personally) is to position the control on top of the canvas, rather > than attempting to render the control inside the canvas (and having to > then deal with event handling, etc). This will likely prove to be > finicky, and more cumbersome than simply using an entirely > canvas-based or entirely scenegraph-based approach. > > -- Jonathan > > > On 5/08/2013 10:11 p.m., Felix Bembrick wrote: > >> I am investigating the feasibility of developing a JavaFX 8 control >> based on Canvas. I have chosen Canvas as the base class as this >> control is of a very dynamic nature and would not be easy to >> implement with a retained mode style ancestor (at least as far as I >> can tell). >> >> So is this feasible? While I can readily see how to render the >> visual aspects of the control, I am not sure how to best "embed" >> other controls within it should that become necessary (and almost certainly will). >> >> For example, how would I go about embedding a Button within my control? >> It >> looks to me like I would need to create an actual Button node >> somewhere else in the scenegraph and then perhaps render it within my >> control using >> gc.drawImage() passing in a snapshot of the Button node. That's OK >> but then I have to somehow handle events and I am not sure how best >> to do that. >> >> Another issue I see is that there seems to be no way to apply effects >> to individual graphic elements within the Canvas as the applyEffect() >> method applies to the entire Canvas. >> >> Finally, a significant obstacle is this issue: >> >> https://javafx-jira.kenai.com/**browse/RT-23822> enai.com/browse/RT-23822> >> >> This issue relates to the lack of support for LCD font smoothing >> within Canvas. This may not sound that serious but the difference >> between LCD font-smoothed text in other controls and the grey-scale >> text in Canvas is so distinct on my current machine that a control >> based on Canvas would really stick out like a sore thumb and appear >> significantly less appealing than a "standard" control. >> >> So, am I wasting my time? >> Are there any other issues I am likely to face? >> Are there other ways to develop dynamic controls which may involve >> thousands of nodes (such as lines, curves etc.)? >> >> Thanks, >> >> Felix >> > > From hang.vo at oracle.com Tue Aug 6 18:47:51 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Aug 2013 01:47:51 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20130807014923.5042A48649@hg.openjdk.java.net> Changeset: 925eeb161438 Author: jgiles Date: 2013-08-07 09:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/925eeb161438 RT-32139: Can't change ComboBox value in change listener ! modules/controls/src/main/java/javafx/scene/control/SingleSelectionModel.java ! modules/controls/src/test/java/javafx/scene/control/ComboBoxTest.java Changeset: 84847b5a5dbc Author: jgiles Date: 2013-08-07 09:50 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/84847b5a5dbc RT-32119: ListView doesn't unselect correct items when Shift + left mouse btn is used (Same bug also existed for TableView, TreeView and TreeTableView, so it has been fixed there too) ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.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/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java Changeset: 210aa0f86593 Author: jgiles Date: 2013-08-07 13:24 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/210aa0f86593 RT-27156: Animated TitledPane does not synch animation with its content RT-30566: Opening/Closing Animation of TitledPane in nested Accordions with some Controls not working as expected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: f63ed218267f Author: jgiles Date: 2013-08-07 13:32 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f63ed218267f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From tobi at ultramixer.com Wed Aug 7 00:15:08 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 7 Aug 2013 09:15:08 +0200 Subject: Fwd: hg: openjfx/8/graphics/rt: RT-32032 Android: VM hangs when application finishes. References: <20130806063346.C67C9485F8@hg.openjdk.java.net> Message-ID: <65357A20-C9E4-4DD2-A512-910CAFCAE6A7@ultramixer.com> Tomas, which VM do you mean in this bug report ;)? Tobi Anfang der weitergeleiteten Nachricht: > Von: hang.vo at oracle.com > Betreff: hg: openjfx/8/graphics/rt: RT-32032 Android: VM hangs when application finishes. > Datum: 6. August 2013 08:33:26 MESZ > An: openjfx-dev at openjdk.java.net > > Changeset: 521cced8d920 > Author: tb115823 > Date: 2013-08-06 08:26 +0200 > URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/521cced8d920 > > RT-32032 Android: VM hangs when application finishes. > Detach correctly all threads. > Send notification to FXActivity that VM has shutdown. > > ! modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java > ! modules/graphics/src/android/java/com/oracle/dalvik/NativePipeReader.java > ! modules/graphics/src/android/java/com/oracle/dalvik/VMLauncher.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/input/android/androidInput.c > ! modules/graphics/src/main/native-glass/lens/input/android/androidInput.h > ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c > From tobi at ultramixer.com Wed Aug 7 00:19:53 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 7 Aug 2013 09:19:53 +0200 Subject: JavaFX and iOS - it will remain a dream In-Reply-To: References: <48A47A75-7C7A-429E-9833-2BF1C47B2CEE@ultramixer.com> Message-ID: <8152C2BD-2D54-413A-931C-6A28DF9209BE@ultramixer.com> Yes Felix, it *has* to be this year?. We do not port our swing based commercial apps if JavaFX does not run on tablets as well. Am 30.07.2013 um 21:06 schrieb Felix Bembrick : > Hi Tobi, > > I know how you feel. As much as I am impressed with JavaFX, clearly its long-term survival does depend on it being viable on mobiles and tablets. > > All I can say is don't give up yet. I am certainly not giving up. I really hope we see something at JavaOne this year that will please us all. > > It *has* to be this year! > > Felix > > > > On 31 July 2013 02:40, Tobias Bley wrote: > Hi, > > after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I?m very frustrated because of the following things: > > Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don?t know the reason - maybe it?s the rendering model of JavaFX - maybe it?s the currently unoptimized RoboVM > One big problem of RoboVM is it?s dependence of the Android library, it does not support the OpenJDK. That?s a big reason for many many problems when using JavaFX. So currently it?s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library? > Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT compiling? we hade no success?too complicated build process?no demos available for iOS? > > So in my opinion ?JavaFX on iOS? will remain a dream?If there will be no big company like Oracle or IBM who actively develops a VM for iOS and Android, JavaFX will be useless, also on Desktop, then HTML5 or QT will be the big winner for the most use cases on Desktop and mobile? > > Best, > Tobi > > From tobi at ultramixer.com Wed Aug 7 00:35:04 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 7 Aug 2013 09:35:04 +0200 Subject: current state of gradle script for Android? In-Reply-To: <51FB74EE.9050505@oracle.com> References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> <51FA69F9.1040402@oracle.com> <51FB74EE.9050505@oracle.com> Message-ID: Hi Tomas, thanks for your hints. Where can I find the ?FXApplication? class? There is only a ?FXActivity? and a ?VMLauncher? class? Could you please give me a hint how to start to build a JavaFX launcher for Dalvik? Thanks, Tobi Am 02.08.2013 um 10:59 schrieb tomas.brandalik : > On 08/01/2013 11:41 PM, Tobias Bley wrote: >> Thanks Tomas, >> >> after changing android.gradle script line "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.4.3?)? to "defineProperty("ANDROID_CROSS_TOOLS_VER", > If toolchain version changed you just need to pass property -PANDROID_CROSS_TOOLS_VER=arm-linux-androideabi-4.6 >> "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could successfully build OpenJFX for Android von Mac OS X 10.9! > I will have a look at it. >> >> So now I?m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in ?com.oracle.dalvik? package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? > The fx project for android looks like usual android project except that it bundles with the vm image. All essential parameters (main class, debug port, parametets etc) are in AndroidManifest.xml > If you look at FXApplication you will realize that it installs vm first and then launches fx application on that vm. FXApplication activity does very little just prepares a surface where to draw opengl stuff. I'm sure you see the catch ... the vm is not available yet. > Another option to consider is to run on dalvik which I think is doable with a rewriting the launcher and using compatibility project javafx78 (or how's that called). > > -Tomas > >> >> Best regards, >> Tobi >> >> >> Am 01.08.2013 um 16:00 schrieb tomas.brandalik : >> >>> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. >>> http://developer.android.com/sdk/index.html >>> http://developer.android.com/tools/sdk/ndk/index.html >>> -Tomas >>> >>> On 08/01/2013 03:41 PM, Tobias Bley wrote: >>>> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? >>>> >>>> Thanks! >>>> Tobi >>>> >>>> >>>> Am 31.07.2013 um 16:42 schrieb tomas.brandalik : >>>> >>>>> Hi Tobi, >>>>> it works on linux only right now. >>>>> Set properties for cross build and android sdk/ndk. >>>>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >>>>> Closed source parts web and font-t2k will be missing. >>>>> >>>>> -Tomas >>>>> >>>>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>>>> Hi, >>>>>> >>>>>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>>>>> >>>>>> Best regards, >>>>>> Tobi >>>>>> > From zonski at gmail.com Wed Aug 7 00:50:23 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 7 Aug 2013 17:50:23 +1000 Subject: JavaFX and iOS - it will remain a dream In-Reply-To: <8152C2BD-2D54-413A-931C-6A28DF9209BE@ultramixer.com> References: <48A47A75-7C7A-429E-9833-2BF1C47B2CEE@ultramixer.com> <8152C2BD-2D54-413A-931C-6A28DF9209BE@ultramixer.com> Message-ID: <0B54EE35-584F-4178-AC3B-8AE1AE18B6E8@gmail.com> How did you go with using Maven for your iOS stuff Tobi? Did it work out for you? Has anyone else had a chance to get into it? I was hoping for more feedback on what works and what doesn't. Also hoping to see some open source demo iOS apps popup to start highlighting what works and what doesn't. http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/ We all know 'Oracle' has a stupid stance on this, and reading between the lines the 'JFX' team are more on our side of the fence but are hamstrung. My personal feel is that the only hope is for the community to get the momentum going and to use that to then pressure Oracle into doing more. I've done what I can on the Maven front, trying to make it easy for developers to build apps. It's taken a lot of late nights and burnt up a lot of weekends (I even had to go buy a friggen Mac). I've reached my max for investing at this stage and need to take a little time to catch up on slipping day job work before the next round of fixes and enhancements. It would be great to see a real community effort here and see some people take up the baton and run the next leg of the relay. Both Niklas and Danno have done massive contributions so far too and I don't think they can be expected to carry the load alone. If you want to help give jfx iOS an actual fighting chance then consider: - writing some demo apps using the maven stuff, blogging about it, feeding back problems and issues so we can start fixing them - helping Niklas get robovm performant and feature rich (eg build a bundle for deployment to the app store) - talk to Niklas about financially sponsoring his work - if a company or two were willing to pay for him to work on it an extra day or two a week I suspect we'd see rapid gains - help maintain the backport run by Danno. Every time there are changes to the main jfx code we need to merge these into the backport. This is no small task. - help document the Maven plugin and generate usage information including a getting started guide and show how to do things like use FXML, change the app icon, change plists, run on older versions of ios, etc. On 07/08/2013, at 5:19 PM, Tobias Bley wrote: > Yes Felix, it *has* to be this year?. We do not port our swing based commercial apps if JavaFX does not run on tablets as well. > > > > > Am 30.07.2013 um 21:06 schrieb Felix Bembrick : > >> Hi Tobi, >> >> I know how you feel. As much as I am impressed with JavaFX, clearly its long-term survival does depend on it being viable on mobiles and tablets. >> >> All I can say is don't give up yet. I am certainly not giving up. I really hope we see something at JavaOne this year that will please us all. >> >> It *has* to be this year! >> >> Felix >> >> >> >> On 31 July 2013 02:40, Tobias Bley wrote: >> Hi, >> >> after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I?m very frustrated because of the following things: >> >> Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don?t know the reason - maybe it?s the rendering model of JavaFX - maybe it?s the currently unoptimized RoboVM >> One big problem of RoboVM is it?s dependence of the Android library, it does not support the OpenJDK. That?s a big reason for many many problems when using JavaFX. So currently it?s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library? >> Avian: we tried to use JavaFX in conjunction with Avian + OpenJDK and AOT compiling? we hade no success?too complicated build process?no demos available for iOS? >> >> So in my opinion ?JavaFX on iOS? will remain a dream?If there will be no big company like Oracle or IBM who actively develops a VM for iOS and Android, JavaFX will be useless, also on Desktop, then HTML5 or QT will be the big winner for the most use cases on Desktop and mobile? >> >> Best, >> Tobi >> >> > From tobi at ultramixer.com Wed Aug 7 00:58:22 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 7 Aug 2013 09:58:22 +0200 Subject: JavaFX for Android build is broken Message-ID: <2BEC65EB-F388-47E4-978A-F02E2828FC70@ultramixer.com> Hi (Tomas), I tried to build JavaFX for Android again but was getting the follow build errors: /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c: In function 'Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onKeyEventNative': /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c:240:5: warning: implicit declaration of function 'describe_key_action' [-Wimplicit-function-declaration] /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c: At top level: /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c:332:7: error: conflicting types for 'describe_key_action' /Applications/Developer/Java/open-jfx-graphics/rt/modules/graphics/src/main/native-glass/lens/android/android.c:240:5: note: previous implicit declaration of 'describe_key_action' was here :graphics:ccAndroidSurface FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':graphics:ccAndroidSurface'. > org.gradle.process.internal.ExecException: Process 'command '/Applications/Developer/Java/android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-gcc'' finished with non-zero exit value 1 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. From tomas.brandalik at oracle.com Wed Aug 7 01:15:25 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Wed, 07 Aug 2013 10:15:25 +0200 Subject: current state of gradle script for Android? In-Reply-To: References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> <51FA69F9.1040402@oracle.com> <51FB74EE.9050505@oracle.com> Message-ID: <5202021D.3090905@oracle.com> Hi, this was a typo :( I meant FXActivity not FXApplication. You can get some hints from FXActivity.java.jfx78 source file if you look at launchFXApplication(). But this is just an old launcher which is not functional now. I will to give it a try when there is backport of javafx (https://bitbucket.org/narya/jfx78) updated to latest status of openjfx. It should be fairly easy to write launcher for dalvik. -Tomas On 08/07/2013 09:35 AM, Tobias Bley wrote: > Hi Tomas, > > thanks for your hints. Where can I find the ?FXApplication? class? There is only a ?FXActivity? and a ?VMLauncher? class? > > Could you please give me a hint how to start to build a JavaFX launcher for Dalvik? > > Thanks, > Tobi > > > Am 02.08.2013 um 10:59 schrieb tomas.brandalik : > >> On 08/01/2013 11:41 PM, Tobias Bley wrote: >>> Thanks Tomas, >>> >>> after changing android.gradle script line "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.4.3?)? to "defineProperty("ANDROID_CROSS_TOOLS_VER", >> If toolchain version changed you just need to pass property -PANDROID_CROSS_TOOLS_VER=arm-linux-androideabi-4.6 >>> "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could successfully build OpenJFX for Android von Mac OS X 10.9! >> I will have a look at it. >>> So now I?m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in ?com.oracle.dalvik? package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? >> The fx project for android looks like usual android project except that it bundles with the vm image. All essential parameters (main class, debug port, parametets etc) are in AndroidManifest.xml >> If you look at FXApplication you will realize that it installs vm first and then launches fx application on that vm. FXApplication activity does very little just prepares a surface where to draw opengl stuff. I'm sure you see the catch ... the vm is not available yet. >> Another option to consider is to run on dalvik which I think is doable with a rewriting the launcher and using compatibility project javafx78 (or how's that called). >> >> -Tomas >> >>> Best regards, >>> Tobi >>> >>> >>> Am 01.08.2013 um 16:00 schrieb tomas.brandalik : >>> >>>> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. >>>> http://developer.android.com/sdk/index.html >>>> http://developer.android.com/tools/sdk/ndk/index.html >>>> -Tomas >>>> >>>> On 08/01/2013 03:41 PM, Tobias Bley wrote: >>>>> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? >>>>> >>>>> Thanks! >>>>> Tobi >>>>> >>>>> >>>>> Am 31.07.2013 um 16:42 schrieb tomas.brandalik : >>>>> >>>>>> Hi Tobi, >>>>>> it works on linux only right now. >>>>>> Set properties for cross build and android sdk/ndk. >>>>>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >>>>>> Closed source parts web and font-t2k will be missing. >>>>>> >>>>>> -Tomas >>>>>> >>>>>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>>>>> Hi, >>>>>>> >>>>>>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>>>>>> >>>>>>> Best regards, >>>>>>> Tobi >>>>>>> From tobi at ultramixer.com Wed Aug 7 01:35:21 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 7 Aug 2013 10:35:21 +0200 Subject: Fwd: current state of gradle script for Android? References: <5202021D.3090905@oracle.com> Message-ID: Hey Danno, could you please merge the latest changes to your jfx78 project? Thank you very much! Tobi Anfang der weitergeleiteten Nachricht: > Von: "tomas.brandalik" > Betreff: Aw: current state of gradle script for Android? > Datum: 7. August 2013 10:15:25 MESZ > An: Tobias Bley > Kopie: "openjfx-dev at openjdk.java.net Mailing" > > Hi, > this was a typo :( I meant FXActivity not FXApplication. > You can get some hints from FXActivity.java.jfx78 source file if you look at launchFXApplication(). But this is just an old launcher which is not functional now. I will to give it a try when there is backport of javafx (https://bitbucket.org/narya/jfx78) updated to latest status of openjfx. It should be fairly easy to write launcher for dalvik. > > -Tomas > > On 08/07/2013 09:35 AM, Tobias Bley wrote: >> Hi Tomas, >> >> thanks for your hints. Where can I find the ?FXApplication? class? There is only a ?FXActivity? and a ?VMLauncher? class? >> >> Could you please give me a hint how to start to build a JavaFX launcher for Dalvik? >> >> Thanks, >> Tobi >> >> >> Am 02.08.2013 um 10:59 schrieb tomas.brandalik : >> >>> On 08/01/2013 11:41 PM, Tobias Bley wrote: >>>> Thanks Tomas, >>>> >>>> after changing android.gradle script line "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.4.3?)? to "defineProperty("ANDROID_CROSS_TOOLS_VER", >>> If toolchain version changed you just need to pass property -PANDROID_CROSS_TOOLS_VER=arm-linux-androideabi-4.6 >>>> "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could successfully build OpenJFX for Android von Mac OS X 10.9! >>> I will have a look at it. >>>> So now I?m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in ?com.oracle.dalvik? package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? >>> The fx project for android looks like usual android project except that it bundles with the vm image. All essential parameters (main class, debug port, parametets etc) are in AndroidManifest.xml >>> If you look at FXApplication you will realize that it installs vm first and then launches fx application on that vm. FXApplication activity does very little just prepares a surface where to draw opengl stuff. I'm sure you see the catch ... the vm is not available yet. >>> Another option to consider is to run on dalvik which I think is doable with a rewriting the launcher and using compatibility project javafx78 (or how's that called). >>> >>> -Tomas >>> >>>> Best regards, >>>> Tobi >>>> >>>> >>>> Am 01.08.2013 um 16:00 schrieb tomas.brandalik : >>>> >>>>> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. >>>>> http://developer.android.com/sdk/index.html >>>>> http://developer.android.com/tools/sdk/ndk/index.html >>>>> -Tomas >>>>> >>>>> On 08/01/2013 03:41 PM, Tobias Bley wrote: >>>>>> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? >>>>>> >>>>>> Thanks! >>>>>> Tobi >>>>>> >>>>>> >>>>>> Am 31.07.2013 um 16:42 schrieb tomas.brandalik : >>>>>> >>>>>>> Hi Tobi, >>>>>>> it works on linux only right now. >>>>>>> Set properties for cross build and android sdk/ndk. >>>>>>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >>>>>>> Closed source parts web and font-t2k will be missing. >>>>>>> >>>>>>> -Tomas >>>>>>> >>>>>>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Tobi >>>>>>>> > From artem.ananiev at oracle.com Wed Aug 7 03:06:07 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 07 Aug 2013 14:06:07 +0400 Subject: Swing and JavaFX thread merge In-Reply-To: References: Message-ID: <52021C0F.2090608@oracle.com> Hi, Pedro Duque Vieira, this is in progress. JDK part is tracked in 8015477: http://bugs.sun.com/view_bug.do?bug_id=8015477 JavaFX part is described in RT-30694: https://javafx-jira.kenai.com/browse/RT-30694 Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. Thanks, Artem On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: > Hi, > > Some time ago there was a patch submitted which for all purposes merged the > swing and javafx thread, making it easier for developers working on a > swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX > > Is this available now (I was under the impression it is)? How do I use it? > > Thanks in advance, > From klaus.eckelt at gmail.com Wed Aug 7 04:34:11 2013 From: klaus.eckelt at gmail.com (Klaus Eckelt) Date: Wed, 7 Aug 2013 13:34:11 +0200 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) Message-ID: Hi, as i moved our MusicPlayer Project to SourceForge yesterday, I saw you can't select JavaFX as used GUI technology. I guess this should be added (i'll try to suggest it somewhere) and would allow to filter for FX Applications there. Regards //Klaus From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Sven Reimers > Sent: Dienstag, 6. August 2013 07:55 > To: Richard Bair > Cc: openjfx mailing list; Pedro Duque Vieira > Subject: > Re: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) > > So we should start and assemble them on a community JavaFX showcase page? > > Should we try to get Jim Weaver and Gerrit involved? > > -Sven > Am 06.08.2013 06:19 schrieb "Richard Bair" : > > > Here is another one on the Oracle page: > > http://www.oracle.com/technetwork/java/javafx/codelse-1984189.html > > > > Richard > > > > On Aug 4, 2013, at 6:15 AM, Sven Reimers wrote: > > > > Hi, > > > > from my perspective a showcase list saying technology X is used by the > > top ten largest engineering companies is always very nice to convince > > people they are not basing a long term project/product on an used, not > > widespread technology. > > > > So for me building a showcase page is a key thing for helping in the > > decision making process. > > > > -Sven > > > > > > On Sun, Aug 4, 2013 at 10:12 AM, Johan Vos wrote: > > > >> Hi, > >> > >> I agree such an overview page would definitely help, but the go/no-go > >> decisions I often see have less to do with convincing customers about > >> JavaFX being the right technology. Customers have a number of > >> requirements, and if I can tell them JavaFX is capable of doing that, > >> they trust me (and they will blame me when I'm wrong). > >> > >> The key bummer I've seen so far is (yet again) wide deployment. "It > >> should run on tablets" and "Our Customers should be able to use > >> [install] this very easily". > >> I am very much aware of the progress being made in both areas, so I'm > >> not complaining at all -- but there is a lot of work to be done. > >> Just want to set expectations right: a cool overview of what is > >> already achieved with JavaFX is not going to convince all potential > >> customers -- in my experience the deployment is still the major > >> reasons why a number of companies are not in favor of JavaFX yet. > >> > >> - Johan > >> > >> > >> > >> 2013/8/4 Anton Epple > >> > >> > A combination of a page describing an individual application, like > >> > the > >> one > >> > you linked here, would be one part and -more important- a page that > >> lists > >> > *all* the applications with a screenshot and a short description. > >> > The latter would be important, because it's a showcase for decision > >> > makers > >> who > >> > are yet undecided if JavaFX is the right technology. > >> > > >> > Before that page existed for NB Platform, I had the same > >> > discussions I > >> now > >> > have for potential JavaFX projects. Developers are in doubt if the > >> > technology is mature/performant/secure/whatever enough for their > >> > large/unique/graphically demanding/etc. project. After they see the > >> page, > >> > they're convinced that it can be done. > >> > > >> > It's especially useful if you need to convince a team. Typically > >> > there's at least one person in favor of a different technology (for > >> > JavaFX it's typically GWT) and such a page is a great FUD-killer. > >> > > >> > Am 01.08.2013 um 22:40 schrieb Richard Bair >: > >> > > >> > > Something I guess would go on such a page? > >> > > > >> > > http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ > >> > > > >> > > On Aug 1, 2013, at 3:21 AM, Anton Epple > >> wrote: > >> > > > >> > >> Great idea, there's a site that does the same for NetBeans > >> > >> Platform > >> > Apps: > >> > >> > >> > >> https://platform.netbeans.org/screenshots.html > >> > >> > >> > >> I can tell from my own experience that it helps a lot in > >> > >> discussions > >> > with customers to show them that NASA, NATO, Boeing, UNO, US Army, > >> > and > >> many > >> > others are building on top of NB Platform. > >> > >> > >> > >> From the maintainer of this site, I know there's a lot of work > >> involved > >> > though, and you have to be very active in identifying users, and > >> reaching > >> > out to them. It's definitely not sufficient to wait for users to > >> > submit their applications. Sometimes it can take a couple of years > >> > from first contact to a screenshot. That said it's absolutely worth > >> > it, and I would volunteer to help in any way I can. > >> > >> > >> > >> Toni > >> > >> > >> > >> -- > >> > >> Anton Epple > >> > >> > >> > >> > >> > >> > >> > >> Am 28.07.2013 um 02:38 schrieb Jonathan Giles < > >> > jonathan.giles at oracle.com>: > >> > >> > >> > >>> This is something that Jasper actually brought up just this > >> > >>> morning > >> > with Richard and I (wrt fxexperience hosting it). I suspect we may > >> > get something underway in the coming weeks. Of course, it depends > >> > on the community getting in touch with us and letting us talk about > >> > them - so > >> much > >> > of the JavaFX world is behind corporate firewalls, where talking > >> > about > >> your > >> > work is generally frowned upon. In any case, for those of you that > >> > can > >> talk > >> > about your work, please email one of us off-list. > >> > >>> -- Jonathan > >> > >>> Sent from a touch device. Please excuse my brevity. > >> > >>> > >> > >>> "John C. Turnbull" wrote: > >> > >>>> +1 > >> > >>>> > >> > >>>> Such a site could be very useful. > >> > >>>> > >> > >>>> -----Original Message----- > >> > >>>> From: openjfx-dev-bounces at openjdk.java.net > >> > >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of > >> > >>>> Daniel Zwolenski > >> > >>>> Sent: Sunday, 28 July 2013 09:56 > >> > >>>> To: Pedro Duque Vieira > >> > >>>> Cc: OpenJFX Mailing List > >> > >>>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) > >> > >>>> > >> > >>>> The idea of a JFX Sightings page (in the tradition of the > >> > >>>> Swing Sightings > >> > >>>> page) has been raised before and I think is a good one. > >> > >>>> > >> > >>>> It deserves it's own page though, that technet section isn't > >> > >>>> up to > >> it > >> > >>>> in my > >> > >>>> opinion. > >> > >>>> > >> > >>>> Personally I think this would be great under the fxexperience > >> > >>>> site > >> as > >> > >>>> it > >> > >>>> partners nicely with the links of the week? > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira > >> > >>>> > >> > >>>> wrote: > >> > >>>> > >> > >>>>> I have an Swing/JavaFX app, the site is: http://modellus.co > >> > >>>>> > >> > >>>>> How can I get it to be on that real world usecases section? > >> > >>>>> Or > >> does > >> > >>>> it > >> > >>>>> not have the necessary requirements to be in it? > >> > >>>>> > >> > >>>>> Thanks, best regards, > >> > >>>>> > >> > >>>>> @John: On the JavaFx community site they have a section with > >> > >>>>> references to > >> > >>>>>> real world usecases. > >> > >>>>>> > >> http://www.oracle.com/technetwork/java/javafx/community/index.html > >> > >>>>>> > >> > >>>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull > >> > >>>>>> >> > >>>>>>> wrote: > >> > >>>>>>> Like Daniel said, none of what we say is in any way a > >> > >>>>>>> criticism > >> of > >> > >>>>>>> the JavaFX development team who, in my view and that of the > >> entire > >> > >>>>>>> community, are doing an awesome job. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> For mine, all the shortcomings of JavaFX (perceived or > >> > >>>>>>> actual) > >> can > >> > >>>>>>> be > >> > >>>>>> blown > >> > >>>>>>> away if I could just demonstrate what JavaFX is really > >> > >>>>>>> capable > >> of. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras > >> (whose > >> > >>>>>>> demo incidentally doesn't run since Java 7 Update 21). > >> > >>>>>>> With > >> Oracle > >> > >>>> > >> > >>>>>>> Ensemble > >> > >>>>>> we > >> > >>>>>>> can see that JavaFX has quite a nice set of basic controls > >> > >>>>>>> and > >> that > >> > >>>> > >> > >>>>>>> it at least supports very simple animations. With JFXtras > >> Ensemble > >> > >>>> > >> > >>>>>>> we can see that very nice controls are possible but > >> unfortunately > >> > >>>>>>> many of these are > >> > >>>>>> of > >> > >>>>>>> a rather "whimsical" nature and not the kind of control you > >> would > >> > >>>>>>> use in everyday business apps. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> What else is there? > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> Of course we have rock stars like Gerrit Grunwald who > >> > >>>>>>> frequently post awesome controls and code snippets but we > >> > >>>>>>> really need > >> > >>>> something > >> > >>>>>>> that > >> > >>>>>> brings > >> > >>>>>>> it altogether in a kick-arse showcase. Preferably a whole > >> suite of > >> > >>>>>> killer > >> > >>>>>>> apps that highlights everything JavaFX is capable of. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> Yes, that would require a lot of effort but IMHO it is > >> absolutely > >> > >>>>>>> worth > >> > >>>>>> it. > >> > >>>>>>> Without it, people like me really struggle to sell JavaFX > >> > >>>>>>> or > >> even > >> > >>>>>>> get a handle on its true potential. I can promise people > >> > >>>>>>> that > >> more > >> > >>>> > >> > >>>>>>> advanced things are "possible" but given that they write > >> > >>>>>>> the cheques, they need to see it for themselves. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> And how about a website of JavaFX reference sites? There > >> > >>>>>>> must > >> be > >> > >>>>>>> big companies out there using it right? > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> In the end it doesn't matter if I personally see enormous > >> potential > >> > >>>> > >> > >>>>>>> for JavaFX if I cannot convince others to see what I see. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> -jct > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] > >> > >>>>>>> Sent: Saturday, 27 July 2013 09:12 > >> > >>>>>>> To: John C. Turnbull > >> > >>>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net > >> > >>>>>>> Subject: Re: Can JavaFX do CAD? > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> +1 > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> I've failed to convince multiple clients that they should > >> > >>>>>>> use > >> JFX > >> > >>>>>>> because of > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> a) lack of examples of what it can really do, and how to > >> > >>>>>>> make > >> it do > >> > >>>> > >> > >>>>>>> that (e.g. in enterprise space we have > >> > >>>>>>> http://static.springsource.org/docs/petclinic.html) > >> > >>>>>>> > >> > >>>>>>> b) lack of any big or notable players out there actually > >> > >>>>>>> using > >> it, > >> > >>>>>>> or at least publicly saying they are using it > >> > >>>>>>> > >> > >>>>>>> c) the deployment hassles vs the ease of html app > >> > >>>>>>> deployment and > >> > >>>> the > >> > >>>>>>> true cross-platform-ness of html > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> After actually getting one client to trust me on it and use > >> > >>>>>>> it > >> on a > >> > >>>> > >> > >>>>>>> real, commercial app (startup), I hit problems with > >> > >>>>>>> performance (broad interpretation of the term, not > >> > >>>>>>> 'framerate'), crippling deployment and > >> > >>>>>> auto > >> > >>>>>>> updating issues, missing basic features (e.g. maximise > >> > >>>>>>> button, coming in > >> > >>>>>>> 2014 I believe?), unpredictability of CSS styling, and a > >> > >>>>>>> lack of best practices for things like how to do CAD-like > >> > >>>>>>> diagrams (not > >> so > >> > >>>>>>> much render performance but zooming, panning, mouse input, > >> > >>>> layering, > >> > >>>> dragging, etc). > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> Like John, I've been guilty of letting my frustration show > >> > >>>>>>> in > >> these > >> > >>>>>> forums. > >> > >>>>>>> Like John, it's because I want so badly for JavaFX to be > >> > >>>>>>> the platform I develop on, it has the potential to be > >> > >>>>>>> awesome, but things (that seem obvious and small to me) > >> > >>>>>>> completely stop it > >> from > >> > >>>>>>> being usable in a real world situation for me. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> It's not that we think the JFX team aren't slogging their > >> > >>>>>>> guts > >> out, > >> > >>>>>> clearly > >> > >>>>>>> you are. It's just that in some key areas, there are > >> > >>>>>>> small-ish blocks > >> > >>>>>> that > >> > >>>>>>> stop the whole rocket from launching. To then see a whole > >> > >>>>>>> lot of effort > >> > >>>>>> be > >> > >>>>>>> poured into things like binary CSS/FXML compilation, Pi > >> > >>>>>>> platform support (that's more important than iOS/Android, > >> > >>>>>>> really?), web deployment > >> > >>>>>> patches, > >> > >>>>>>> or even 3D (as cool as that is), just knocks me about. > >> > >>>>>>> Obviously your priorities are coming from somewhere > >> > >>>>>>> different to ours, but > >> > >>>> the > >> > >>>>>>> way you prioritise is unfathomable to me and that > >> > >>>>>>> definitely > >> adds > >> > >>>> to > >> > >>>>>>> the frustration. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> At this stage, I am not suggesting my clients use JFX (I > >> actively > >> > >>>>>>> discourage them from it, in their interest). Mobile is the > >> > >>>>>>> area > >> > >>>> that > >> > >>>>>>> has the > >> > >>>>>> potential > >> > >>>>>>> to bring JFX back into usable for me as it can compete > >> > >>>>>>> easier > >> with > >> > >>>>>>> the current technologies (which are all crap). Maybe if > >> > >>>>>>> that > >> ends > >> > >>>> up > >> > >>>>>>> working > >> > >>>>>> (a > >> > >>>>>>> long, long road to go on that and very much an 'if') then > >> > >>>>>>> it > >> will > >> > >>>>>>> seep > >> > >>>>>> back > >> > >>>>>>> into the desktop for me, but at a minimum the desktop > >> > >>>>>>> deployment options will need to be improved before that's > >> > >>>>>>> even a > >> possibility. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> I've come to accept that I am not in the primary target > >> > >>>>>>> audience > >> > >>>> for > >> > >>>>>>> JavaFX, maybe a secondary target. I don't understand who > >> > >>>>>>> the > >> > >>>> primary > >> > >>>>>>> target is though, and knowing/accepting doesn't make it any > >> > >>>>>>> less frustrating. I > >> > >>>>>> keep > >> > >>>>>>> involved in the hope that I might get a usable platform > >> somewhere > >> > >>>>>>> along > >> > >>>>>> the > >> > >>>>>>> way but it's more of a hope than a belief. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> So nothing really new above, but just adding my voice to > John's. > >> > >>>>>>> JavaFX > >> > >>>>>> is > >> > >>>>>>> definitely not production ready for me, my clients and the > >> types of > >> > >>>> > >> > >>>>>>> apps > >> > >>>>>> I > >> > >>>>>>> build (e.g. consumer facing online systems, > >> enterprise/backoffice > >> > >>>>>> systems, > >> > >>>>>>> form/data systems, diagramming systems). One day I hope it > >> > >>>>>>> will > >> be, > >> > >>>> > >> > >>>>>>> but it's moving extremely slowly or not at all in the areas > >> > >>>>>>> that would make it so for me. Meanwhile the competitors > >> > >>>>>>> (primarily JavaScript based solutions) are improving > >> > >>>>>>> rapidly in the areas > >> > >>>> where > >> > >>>>>>> they have traditionally been weak. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < > >> > >>>>>> ozemale at ozemail.com.au > >> > >>>>>>> > wrote: > >> > >>>>>>> > >> > >>>>>>> Hi Richard, > >> > >>>>>>> > >> > >>>>>>> I have to stop posting late at night, that one came across > >> > >>>>>>> as > >> > >>>> really > >> > >>>>>> ANGRY! > >> > >>>>>>> > >> > >>>>>>> It's not anger, it's passion... and frustration. > >> > >>>>>>> > >> > >>>>>>> I am frustrated because I spend much of my day trying to > >> convince > >> > >>>> my > >> > >>>>>>> employer that we should be using JavaFX. They ask me > >> > >>>>>>> questions > >> > >>>> like: > >> > >>>>>>> > >> > >>>>>>> "What happens if Oracle abandons JavaFX just like Sun did > >> > >>>>>>> with > >> JMF, > >> > >>>>>> Java3D, > >> > >>>>>>> JOGL etc. ?" > >> > >>>>>>> > >> > >>>>>>> I say: > >> > >>>>>>> > >> > >>>>>>> "This is Oracle, not Sun." > >> > >>>>>>> > >> > >>>>>>> They say: > >> > >>>>>>> > >> > >>>>>>> "Can you show me what JavaFX can do? There must be examples > >> > >>>>>>> out there right?" > >> > >>>>>>> > >> > >>>>>>> And I say: > >> > >>>>>>> > >> > >>>>>>> "Sure, here's Ensemble." > >> > >>>>>>> > >> > >>>>>>> They say: > >> > >>>>>>> > >> > >>>>>>> "OK, so it has a nice set of basic controls and can do > >> > >>>>>>> simple animations but what about more complex things like > Flash?" > >> > >>>>>>> > >> > >>>>>>> ...hence the dancing cat reference. > >> > >>>>>>> > >> > >>>>>>> It's not that my employer *needs* dancing cats, it's just > >> > >>>>>>> that > >> they > >> > >>>> > >> > >>>>>>> need > >> > >>>>>> to > >> > >>>>>>> see that there is more to JavaFX than red circle > >> > >>>>>>> transitions. I can't > >> > >>>>>> even > >> > >>>>>>> prove to them that JavaFX is capable of dancing cats. They > >> don't > >> > >>>>>>> have > >> > >>>>>> the > >> > >>>>>>> resources to fund me to develop something more > >> > >>>>>>> sophisticated but they > >> > >>>>>> tell > >> > >>>>>>> me that if JavaFX truly was a "mature" technology (like I > >> > >>>>>>> tell > >> > >>>> them) > >> > >>>>>>> then where are all the examples? > >> > >>>>>>> > >> > >>>>>>> I am finding it difficult to convince them that JavaFX is > >> > >>>> production > >> > >>>>>> ready > >> > >>>>>>> and is not still in "experimental" mode because I am unable > >> > >>>>>>> to > >> > >>>>>> demonstrate > >> > >>>>>>> its true capabilities or refer them to many examples of > >> > >>>>>>> people > >> (and > >> > >>>> > >> > >>>>>>> I > >> > >>>>>> mean > >> > >>>>>>> big companies) actually using it. > >> > >>>>>>> > >> > >>>>>>> The main concerns of my employer and I think many companies > >> > >>>>>>> in a similar situation is that JavaFX won't survive long > >> > >>>>>>> term and > >> that > >> > >>>> it > >> > >>>>>>> is only > >> > >>>>>> really > >> > >>>>>>> suitable for form based applications. Then of course there > >> > >>>>>>> is > >> the > >> > >>>>>>> whole > >> > >>>>>>> "HTML5 runs on all platforms" argument but that's another > >> story... > >> > >>>>>>> > >> > >>>>>>> So this is why I think it's imperative that Oracle invests > >> > >>>>>>> in developing > >> > >>>>>> a > >> > >>>>>>> true showcase application for JavaFX. Something that > >> non-technical > >> > >>>>>> people > >> > >>>>>>> (like managers who make decisions about where the money > >> > >>>>>>> goes) > >> can > >> > >>>>>>> look at it and go "wow!". > >> > >>>>>>> > >> > >>>>>>> I am just not getting my managers to go "wow" at what I can > >> > >>>>>>> show them > >> > >>>>>> with > >> > >>>>>>> JavaFX at the moment. > >> > >>>>>>> > >> > >>>>>>> Every comment or apparent criticism I post about JavaFX is > >> > >>>>>>> from > >> the > >> > >>>> > >> > >>>>>>> perspective that I am trying to deal with real-world > >> > >>>>>>> problems > >> and > >> > >>>>>>> people who require proof (such as demos, reference sites > >> > >>>>>>> etc.) > >> and > >> > >>>>>>> not because I myself think JavaFX is not up to scratch. > >> > >>>>>>> > >> > >>>>>>> It's quite the opposite actually. > >> > >>>>>>> > >> > >>>>>>> I am a very, very strong believer and supporter of JavaFX > >> > >>>>>>> and > >> have > >> > >>>>>>> many reasons both personal and professional as to why I > >> > >>>>>>> want it > >> to > >> > >>>>>>> be a > >> > >>>>>> massive > >> > >>>>>>> success. As I have said before, there are plenty of people > >> > >>>>>>> who praise JavaFX and tend to avoid the very real issues > >> > >>>>>>> that are restricting its adoption. I just think we have to > >> > >>>>>>> face these > >> > >>>> issues > >> > >>>>>>> head on if we are to compete in what is a very cut-throat > >> industry. > >> > >>>>>>> > >> > >>>>>>> -jct > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> -----Original Message----- > >> > >>>>>>> From: Richard Bair [mailto:richard.bair at oracle.com > >> > >>>>>>> ] > >> > >>>>>>> Sent: Saturday, 27 July 2013 01:40 > >> > >>>>>>> To: John C. Turnbull > >> > >>>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net > >> > >>>>>>> > >> > >>>>>>> Subject: Re: Can JavaFX do CAD? > >> > >>>>>>> > >> > >>>>>>>> For Flash, there are literally millions of examples of > >> > >>>>>>>> fancy/complex/impressive graphics and animations out there > >> > >>>>>>>> that > >> > >>>> can > >> > >>>>>>>> be really impressive at times. I have not seen ONE such > >> example > >> > >>>> in > >> > >>>>>> JavaFX! > >> > >>>>>>> > >> > >>>>>>> Point to one? > >> > >>>>>>> > >> > >>>>>>> Have you seen any of the JavaOne examples? The movie wall > >> > >>>>>>> or > >> movies > >> > >>>> > >> > >>>>>>> on a stack of 3D cubes was pretty good. But I guess you're > >> > >>>>>>> not interested in > >> > >>>>>> the > >> > >>>>>>> 3D aspect? What is it you are looking for exactly? > >> > >>>>>>> Different > >> people > >> > >>>> > >> > >>>>>>> (on this > >> > >>>>>>> list) have had different perceptions on both (a) what's > >> important > >> > >>>>>>> and (b) what kind of graphics they're interested in. Most > >> > >>>>>>> people would deride the dancing cat as being totally > >> > >>>>>>> irrelevant to the types of applications they're trying to > >> > >>>>>>> build (the basis for > >> much > >> > >>>> of > >> > >>>>>>> flash animations is shape > >> > >>>>>> morphing, > >> > >>>>>>> you can find some code here > >> > >>>> https://gist.github.com/gontard/5029764). > >> > >>>>>>> > >> > >>>>>>> On the other hand, JavaFX is not a replacement for OpenGL. > >> Drawing > >> > >>>>>>> 25 million lines is just not something we can do right now, > >> > >>>>>>> especially in a resource constrained environment. I've > >> > >>>>>>> already commented on the memory overhead (which would > >> > >>>>>>> continue to be an issue even if the drawing part of the > problem were solved). > >> > >>>>>>> > >> > >>>>>>> I've pushed to graphics repo the StretchyGrid, which is > >> > >>>>>>> about > >> 300k > >> > >>>>>>> line nodes (the actual amount is variable, see the javadoc > >> > >>>>>>> comments). At 300k nodes the scene graph overhead is > >> > >>>>>>> negligible > >> on > >> > >>>>>>> the FX side, dirty opts > >> > >>>>>> is > >> > >>>>>>> taking a long time to run, and painting is really slow. > >> > >>>>>>> > >> > >>>>>>> PULSE: 347 [122ms:222ms] > >> > >>>>>>> T12 (8 +0ms): CSS Pass > >> > >>>>>>> T12 (8 +0ms): Layout Pass > >> > >>>>>>> T12 (47 +53ms): Waiting for previous rendering > >> > >>>>>>> T12 (100 +1ms): Copy state to render graph > >> > >>>>>>> T10 (101 +16ms): Dirty Opts Computed > >> > >>>>>>> T10 (117 +105ms): Painted > >> > >>>>>>> Counters: > >> > >>>>>>> Nodes rendered: 306565 > >> > >>>>>>> Nodes visited during render: 306565 > >> > >>>>>>> > >> > >>>>>>> If I were doing this by hand in open GL, I think the > >> > >>>>>>> drawing > >> would > >> > >>>>>>> be essentially free, if I used LINES with GL anti-aliasing, > >> > >>>>>>> I > >> could > >> > >>>> > >> > >>>>>>> send 'em all down to the card in a single shot (and if I > >> > >>>>>>> had a modern GL I could > >> > >>>>>> do > >> > >>>>>>> LINES + FXAA or one of the other per-pixel AA algorithms > >> available > >> > >>>>>>> and it would turn out pretty nice). Because our shapes > >> > >>>>>>> don't implement the > >> > >>>>>> non-AA > >> > >>>>>>> path, and our AA involves software rasterization and > >> > >>>>>>> uploading > >> of > >> > >>>>>> pixels, I > >> > >>>>>>> expect that to be the main source of the 105ms time being > >> > >>>>>>> spent > >> > >>>> here. > >> > >>>>>>> > >> > >>>>>>> Also I noticed (by turning on prism.showdirty=true) that > >> > >>>>>>> the > >> entire > >> > >>>> > >> > >>>>>>> grid > >> > >>>>>> is > >> > >>>>>>> being painted every time, even though visually it looks > >> > >>>>>>> like > >> only a > >> > >>>> > >> > >>>>>>> small subset actually needs to be changed. But that's > >> > >>>>>>> really a > >> > >>>> minor > >> > >>>>>>> thing, as > >> > >>>>>> I > >> > >>>>>>> said, drawing this many lines should basically be free if I > >> > >>>>>>> configure "smooth" to false in the app. Except that right > >> > >>>>>>> now > >> it is > >> > >>>> > >> > >>>>>>> totally not implemented (in NGShape): > >> > >>>>>>> > >> > >>>>>>> public void setAntialiased(boolean aa) { > >> > >>>>>>> // We don't support aliased shapes at this time } > >> > >>>>>>> > >> > >>>>>>> The point of stretchy grid is not to say "wow look at this > >> amazing > >> > >>>> demo". > >> > >>>>>>> The point is to say "what happens if I put in 300K nodes. > >> > >>>>>>> Where > >> > >>>> does > >> > >>>>>>> the system start to fall over?". > >> > >>>>>>> > >> > >>>>>>> Richard= > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>> -- > >> > >>>>> Pedro Duque Vieira > >> > >> > >> > > > >> > > >> > > >> > > > > > > > > -- > > 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 > > > > > > > -- Klaus Eckelt Brigittaplatz 23/7 1200 Wien Klaus.Eckelt at gmail.com From hang.vo at oracle.com Wed Aug 7 05:03:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Aug 2013 12:03:09 +0000 Subject: hg: openjfx/8/graphics/rt: Android: Handle back key. Map it to javafx ESC keyode. It doesn't have default behaviour like on Android application has to handle it. Message-ID: <20130807120326.D9E4548673@hg.openjdk.java.net> Changeset: 7b91d799fbda Author: tb115823 Date: 2013-08-07 13:50 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7b91d799fbda Android: Handle back key. Map it to javafx ESC keyode. It doesn't have default behaviour like on Android application has to handle it. ! 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/input/android/androidLens.c ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.h From hang.vo at oracle.com Wed Aug 7 04:17:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Aug 2013 11:17:49 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32168 Android: Build has to better support various toolchains. Message-ID: <20130807111821.5ABD84866A@hg.openjdk.java.net> Changeset: 3f66d861ed68 Author: tb115823 Date: 2013-08-07 13:00 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3f66d861ed68 RT-32168 Android: Build has to better support various toolchains. ! buildSrc/android.gradle From hang.vo at oracle.com Wed Aug 7 05:33:28 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Aug 2013 12:33:28 +0000 Subject: hg: openjfx/8/controls/rt: 59 new changesets Message-ID: <20130807124918.5689248678@hg.openjdk.java.net> Changeset: d8637798fb3e Author: dmasada Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d8637798fb3e RT-31630 Ensemble8 CurveFittedAreaChart and some others get NPE in NGRegion ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/charts/area/curvefitted/CurveFittedAreaChart.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/searchbox/SearchBox.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/alphamediaplayer/AlphaMediaPlayer.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/overlaymediaplayer/OverlayMediaPlayer.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/streamingmediaplayer/StreamingMediaPlayer.css Changeset: 430db69d45c7 Author: Chien Yang Date: 2013-07-30 14:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/430db69d45c7 Fix to RT-31914: occlusion culling fails to work correctly on pure 2d shapes scene with 3d transform Reviewed by Kevin and Martin ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: 673aece90319 Author: Chien Yang Date: 2013-07-30 14:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/673aece90319 Fix to RT-30829: DepthTest flag on Graphics is set by Node but never cleared, misbehaving with multiple dirty regions Reviewed by Kevin ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: a9eb573ffc6e Author: tb115823 Date: 2013-07-31 09:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a9eb573ffc6e Android: Add vmlauncher netbeans project. + netbeans/android/vmlauncher/Android.mk + netbeans/android/vmlauncher/nbproject/configurations.xml + netbeans/android/vmlauncher/nbproject/project.xml Changeset: 4f9d8e9fb4aa Author: tb115823 Date: 2013-07-31 09:25 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4f9d8e9fb4aa Android: Rename netbeans projects. - netbeans/android/glass-lib-lens/Android.mk - netbeans/android/glass-lib-lens/nbproject/configurations.xml - netbeans/android/glass-lib-lens/nbproject/project.xml + netbeans/android/native-glass/Android.mk + netbeans/android/native-glass/nbproject/configurations.xml + netbeans/android/native-glass/nbproject/project.xml = netbeans/android/native-vmlauncher/Android.mk < netbeans/android/vmlauncher/Android.mk = netbeans/android/native-vmlauncher/nbproject/configurations.xml < netbeans/android/vmlauncher/nbproject/configurations.xml ! netbeans/android/native-vmlauncher/nbproject/project.xml < netbeans/android/vmlauncher/nbproject/project.xml Changeset: fbd46f5535b5 Author: tb115823 Date: 2013-07-31 09:59 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fbd46f5535b5 Android: Add netbeans project native-prism-es2. + netbeans/android/native-prism-es2/Android.mk + netbeans/android/native-prism-es2/nbproject/configurations.xml + netbeans/android/native-prism-es2/nbproject/project.xml Changeset: 74cc6f8d1fc9 Author: Artem Ananiev Date: 2013-07-31 14:03 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/74cc6f8d1fc9 RT-31964: Quantum cleanup: don't force headless AWT on Mac Reviewed-by: Kevin Rushforth ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: 61bcda9f2a59 Author: tb115823 Date: 2013-07-31 13:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/61bcda9f2a59 Android: Fix hyphens in native libraries names. Remove absolete NativeActivity class. ! buildSrc/android.gradle - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java Changeset: fda3c077e769 Author: tb115823 Date: 2013-07-31 13:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fda3c077e769 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java Changeset: 4d6d71a5fdb5 Author: David Pulkrabek Date: 2013-07-31 13:28 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4d6d71a5fdb5 iOS build: introduced a new property for closed build ! buildSrc/ios.gradle Changeset: dd02ad45b83c Author: flar Date: 2013-07-31 06:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dd02ad45b83c Fix RT-30223, RT-30826, RT-31044 - Canvas clears clip on Windows/D3D ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DContext.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderContext.java Changeset: 0bd782657481 Author: snorthov Date: 2013-07-31 13:39 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0bd782657481 ECLIPSE ONLY: work around strange crash in webnode (html editor) that occurs when deploy.jar is before web on the class path. This began happening when I upgraded to b100. Did not investigate further to see whether it is an Eclipse issue or a JDK one. ! .classpath ! modules/web/.classpath Changeset: f7baf984824c Author: kcr Date: 2013-07-31 11:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f7baf984824c RT-32017: Gradle: closed build should fail if jfxrt.jar is present in the JDK ! build.gradle Changeset: 2ad0bb31c1bc Author: peterz Date: 2013-08-01 12:17 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2ad0bb31c1bc RT-32010 Gradle build fails with BINARY_STUB ! build.gradle ! buildSrc/linux.gradle Changeset: 49a2c50e80dc Author: Martin Sladecek Date: 2013-08-01 10:54 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/49a2c50e80dc RT-32001 SubScene is broken in recent code merge for 8.0-b99 ! 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/SubScene.java ! modules/graphics/src/stub/java/javafx/scene/SubSceneTest.java Changeset: 18ba5b7ba24c Author: snorthov Date: 2013-08-01 07:09 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/18ba5b7ba24c RT-31920: Allow Application name to be set and queried and implement app data directory ! modules/graphics/src/main/java/com/sun/glass/ui/Application.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/native-glass/mac/GlassApplication.m Changeset: c8b408109a3a Author: tb115823 Date: 2013-08-01 13:18 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c8b408109a3a Android: webnode moved to opensource. Updated java and native projects. ! buildSrc/android.gradle + modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java.jfx78 + modules/web/src/android/java/com/sun/javafx/scene/web/Debugger.java + modules/web/src/android/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java + modules/web/src/android/java/com/sun/javafx/sg/prism/NGWebView.java + modules/web/src/android/java/com/sun/javafx/webkit/Accessor.java + modules/web/src/android/java/com/sun/javafx/webkit/prism/PrismInvoker.java + modules/web/src/android/java/com/sun/webkit/BackForwardList.java + modules/web/src/android/java/com/sun/webkit/Disposer.java + modules/web/src/android/java/com/sun/webkit/DisposerRecord.java + modules/web/src/android/java/com/sun/webkit/InspectorClient.java + modules/web/src/android/java/com/sun/webkit/Invoker.java + modules/web/src/android/java/com/sun/webkit/LoadListenerClient.java + modules/web/src/android/java/com/sun/webkit/NativeWebView.java + modules/web/src/android/java/com/sun/webkit/Timer.java + modules/web/src/android/java/com/sun/webkit/WebPage.java + modules/web/src/android/java/com/sun/webkit/event/WCChangeEvent.java + modules/web/src/android/java/com/sun/webkit/event/WCChangeListener.java + modules/web/src/android/java/com/sun/webkit/graphics/WCImage.java + modules/web/src/android/java/com/sun/webkit/network/URLs.java + modules/web/src/android/java/com/sun/webkit/network/Util.java + modules/web/src/android/java/javafx/scene/web/HTMLEditor.java + modules/web/src/android/java/javafx/scene/web/PopupFeatures.java + modules/web/src/android/java/javafx/scene/web/PromptData.java + modules/web/src/android/java/javafx/scene/web/WebEngine.java + modules/web/src/android/java/javafx/scene/web/WebEvent.java + modules/web/src/android/java/javafx/scene/web/WebHistory.java + modules/web/src/android/java/javafx/scene/web/WebView.java + modules/web/src/android/java/netscape/javascript/JSException.java + modules/web/src/android/java/netscape/javascript/JSObject.java + modules/web/src/android/native/android_log.h + modules/web/src/android/native/android_webview.c + modules/web/src/android/native/android_webview.h + modules/web/src/android/native/native_webview.c + modules/web/src/android/native/symbol.h + netbeans/android/native-webnode/Android.mk + netbeans/android/native-webnode/nbproject/configurations.xml + netbeans/android/native-webnode/nbproject/project.xml + netbeans/android/webnode/build.xml + netbeans/android/webnode/local.properties + netbeans/android/webnode/nbproject/project.xml Changeset: 675b95a2ac37 Author: tb115823 Date: 2013-08-01 13:23 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/675b95a2ac37 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: 812ccc5dcaf0 Author: snorthov Date: 2013-08-01 07:26 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/812ccc5dcaf0 ECLIPSE ONLY: fix .classpath compile error ! .classpath ! modules/web/.classpath Changeset: 44f6ba54dcde Author: snorthov Date: 2013-08-01 08:11 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/44f6ba54dcde RT-31249: Mechanism to identify application [udpate SWT] ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java Changeset: 7b0d4ac76c35 Author: Artem Ananiev Date: 2013-08-01 16:22 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7b0d4ac76c35 RT-32012: Quantum cleanup: remove PopupScene and PopupStage Reviewed-by: Kevin Rushforth, Steve Northover ! modules/graphics/src/main/java/com/sun/javafx/tk/DummyToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupScene.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupStage.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java ! modules/graphics/src/main/java/javafx/stage/PopupWindow.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubToolkit.java Changeset: b4a3b80a0783 Author: Martin Sladecek Date: 2013-08-01 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b4a3b80a0783 RT-31464 Custom node sample in Ensemble8 is broken ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/node/customnode/MyNode.java Changeset: fbaef718694c Author: Martin Sladecek Date: 2013-08-01 16:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fbaef718694c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: c14cc7cd7d5c Author: peterz Date: 2013-08-01 18:44 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c14cc7cd7d5c Restored accidental change made in changeset #4514 ! buildSrc/linux.gradle Changeset: dff7ba8f08ec Author: Yao Wang Date: 2013-08-01 10:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dff7ba8f08ec RT-26111 Use glyph bounding boxes to get visual bounds ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java ! modules/graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java ! modules/graphics/src/main/java/javafx/scene/text/Text.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubTextLayout.java Changeset: 350038269859 Author: Felipe Heidrich Date: 2013-08-01 11:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/350038269859 minor fix for StubTextLayout caused by RT-26111 ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubTextLayout.java Changeset: 6279340ebb9d Author: Felipe Heidrich Date: 2013-08-01 14:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6279340ebb9d [eclipse only] Adding RegionTests to the classpath ! .classpath Changeset: 9c612891d297 Author: flar Date: 2013-08-01 14:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9c612891d297 Fix RT-31998, forward port of RT-31701: HiDPI: Effects position are wrong ! modules/graphics/src/main/jsl-decora/InvertMask.jsl Changeset: 469677a7c799 Author: flar Date: 2013-08-01 16:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/469677a7c799 Fix RT-24343: missing doc comments in PixelFormat classes ! modules/graphics/src/main/java/javafx/scene/image/PixelFormat.java ! modules/graphics/src/main/java/javafx/scene/image/WritablePixelFormat.java Changeset: 83f1dd37a34d Author: kcr Date: 2013-08-01 17:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/83f1dd37a34d RT-31249: Mechanism to identify application ! modules/graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java Changeset: d0e9bba74866 Author: Chien Yang Date: 2013-08-01 18:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d0e9bba74866 Add Netbeans project for 3D apps/toys projects Add 3D moving camera tests. + apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCamera.java + apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCameraSubScene.java + netbeans/appsToys/FX8-3DFeatures/build.xml + netbeans/appsToys/FX8-3DFeatures/manifest.mf + netbeans/appsToys/FX8-3DFeatures/nbproject/build-impl.xml + netbeans/appsToys/FX8-3DFeatures/nbproject/genfiles.properties + netbeans/appsToys/FX8-3DFeatures/nbproject/project.properties + netbeans/appsToys/FX8-3DFeatures/nbproject/project.xml + netbeans/appsToys/ShapeT3D/build.xml + netbeans/appsToys/ShapeT3D/manifest.mf + netbeans/appsToys/ShapeT3D/nbproject/build-impl.xml + netbeans/appsToys/ShapeT3D/nbproject/genfiles.properties + netbeans/appsToys/ShapeT3D/nbproject/project.properties + netbeans/appsToys/ShapeT3D/nbproject/project.xml Changeset: a22540914163 Author: Chien Yang Date: 2013-08-01 18:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a22540914163 Change title name ! apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCameraSubScene.java Changeset: c6ca49ab6269 Author: Alexander Zvegintsev Date: 2013-08-02 15:41 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c6ca49ab6269 RT-26551 Gtk: Behavior of events sending changed RT-29576 Gtk: Scrolling stops in the combobox popup when the pointer leaves the slider box ! modules/graphics/src/main/native-glass/gtk/glass_gtkcompat.cpp ! modules/graphics/src/main/native-glass/gtk/glass_gtkcompat.h ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp ! modules/graphics/src/main/native-glass/gtk/glass_window.h Changeset: 16f605590496 Author: peterz Date: 2013-08-02 17:56 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/16f605590496 RT-28295 Update libxml2 library to the latest version On Windows, jfxwebkit.dll is now statically linked to the latest libxml2/libxslt ! build.gradle ! modules/web/src/main/native/Source/WebCore/TargetJava.pri Changeset: bfa38efb69fa Author: dmasada Date: 2013-08-02 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bfa38efb69fa RT-31428 TableCellFactory sample doesn't cancel editing completely - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/CheckBoxTableCell.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/EditingCell.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/TableCellFactoryApp.java Changeset: 79cd77093f2d Author: Yao Wang Date: 2013-08-02 14:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/79cd77093f2d RT-30365 FX 8 3D: Remove predefine 3d shapes' local mesh ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGBox.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGCylinder.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGSphere.java Changeset: 673c493e2fd3 Author: dmasada Date: 2013-08-02 14:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/673c493e2fd3 RT-31428 TableCellFactory sample doesn't cancel editing completely-update desc and regen sample info to get new desc ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/TableCellFactoryApp.java Changeset: dfbaa5afdd53 Author: flar Date: 2013-08-02 16:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dfbaa5afdd53 Fix RT-23581 - add 9-slice render methods to Prism Graphics ! modules/graphics/src/main/java/com/sun/prism/Graphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/TestGraphics.java Changeset: 2c8227ed3cf0 Author: flar Date: 2013-08-02 17:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2c8227ed3cf0 Fix RT-27752 - PixelWriter on WritableImage cannot write BYTE_INDEXED image data ! modules/graphics/src/main/java/com/sun/javafx/image/PixelUtils.java + modules/graphics/src/main/java/com/sun/javafx/image/impl/ByteIndexed.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java ! modules/graphics/src/main/java/javafx/scene/image/Image.java ! modules/graphics/src/main/java/javafx/scene/image/PixelFormat.java Changeset: 7c1ff801571d Author: flar Date: 2013-08-04 02:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7c1ff801571d Fix RT-32111 - slice removal optimizations in 9-slicing methods are overly optimistic ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java Changeset: 6de8fb22ec57 Author: Rafi Tayar Date: 2013-08-04 15:48 +0300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6de8fb22ec57 RT-31892 Tap radius and time out should be configurable and set to a lower default ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensTouchInputSupport.java ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c Changeset: 89345a49e71f Author: kcr Date: 2013-08-05 08:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/89345a49e71f Follow-on fix for RT-31249 to call Application.setName from FX app thread ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java Changeset: c3ffaeb2e609 Author: Chien Yang Date: 2013-08-05 10:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c3ffaeb2e609 Fix to RT-29771: Dirty regions don't work with moving camera Reviewed by Kevin ! modules/graphics/src/main/java/javafx/scene/Camera.java ! modules/graphics/src/main/java/javafx/scene/Scene.java Changeset: fcdb21d8a960 Author: Felipe Heidrich Date: 2013-08-05 14:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fcdb21d8a960 RT-30922: Implement 9-slice region background caching ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 53a4fad540f1 Author: Felipe Heidrich Date: 2013-08-05 14:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/53a4fad540f1 RT-32126: composite glyphs broken after RT-30367 ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontStrike.java ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java Changeset: 3456bb1910d4 Author: Lisa.Selle at oracle.com Date: 2013-08-05 20:14 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3456bb1910d4 Interim fix for rt-32116 - roll back changes from commit: changeset: 4447:ff1219a1e652 parent: 4445:074b23ebf5f1 user: Martin Sladecek date: Mon Jul 29 13:33:12 2013 +0200 summary: RT-31919 ColorPicker, ArrayIndexOutOfBoundsException when saving custom color. which currently cause an NPE with a long press on virtual keyboard. See jira for details, this interim fix can be reverted when the bugs that 32116 depends on are fixed. ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/stub/java/javafx/scene/ParentTest.java Changeset: 521cced8d920 Author: tb115823 Date: 2013-08-06 08:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/521cced8d920 RT-32032 Android: VM hangs when application finishes. Detach correctly all threads. Send notification to FXActivity that VM has shutdown. ! modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java ! modules/graphics/src/android/java/com/oracle/dalvik/NativePipeReader.java ! modules/graphics/src/android/java/com/oracle/dalvik/VMLauncher.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/input/android/androidInput.c ! modules/graphics/src/main/native-glass/lens/input/android/androidInput.h ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c Changeset: bd6f656cd8a9 Author: Pavel Safrata Date: 2013-08-06 10:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bd6f656cd8a9 RT-32123: Clip properly synced after parent visibility change. Contributed-by: Tom Schindl Added unit test. ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/stub/java/javafx/scene/NodeTest.java Changeset: b0e96ed06cce Author: Pavel Safrata Date: 2013-08-06 11:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b0e96ed06cce RT-32125: Removed unnecessary call to getParent. Contributed-by: Tom Schindl ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: 91a8ecbea96e Author: Vasiliy Baranov Date: 2013-08-06 15:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/91a8ecbea96e RT-32039: Yandex Maps are broken after sync with WebKit trunk ! modules/web/src/main/native/Source/WebCore/DerivedSourcesJava.pri ! modules/web/src/main/native/Source/WebCore/page/java/ChromeClientJava.cpp ! modules/web/src/main/native/Source/WebCore/page/java/ChromeClientJava.h ! modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.cpp ! modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.h Changeset: 891fda941088 Author: Chien Yang Date: 2013-08-06 07:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/891fda941088 Fix to RT-30270: FX 8 3D: dirtyopts doesn't work for 3D rendering Reviewed by Kevin + apps/toys/FX8-3DFeatures/src/fx83dfeatures/LightMotion.java ! modules/graphics/src/main/java/javafx/scene/LightBase.java Changeset: 1661f722d536 Author: Vasiliy Baranov Date: 2013-08-06 19:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1661f722d536 Fix Mac build broken by the recent fix for RT-32039 ! modules/web/src/main/native/Source/WebCore/mapfile-macosx ! modules/web/src/main/native/Source/WebCore/mapfile-vers Changeset: 59419bdda806 Author: Felipe Heidrich Date: 2013-08-06 08:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/59419bdda806 RT-27541: Add RTL support to TextFlow ! modules/graphics/src/main/java/javafx/scene/text/TextFlow.java Changeset: 0a2b4115d537 Author: Felipe Heidrich Date: 2013-08-06 08:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0a2b4115d537 Removing out-of-date comment in checkOrientation + dosmetic changes (trailing whitespace) ! modules/graphics/src/main/java/javafx/scene/text/Text.java Changeset: 324f1d41fc48 Author: kcr Date: 2013-08-06 10:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/324f1d41fc48 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/CheckBoxTableCell.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/EditingCell.java - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupScene.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupStage.java - netbeans/android/glass-lib-lens/Android.mk - netbeans/android/glass-lib-lens/nbproject/configurations.xml - netbeans/android/glass-lib-lens/nbproject/project.xml Changeset: 147daed4b355 Author: mhowe Date: 2013-08-05 19:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/147daed4b355 RT-31839: Mac native bundle segfaults on application launch [ngthomas] ! buildSrc/mac.gradle Changeset: a010db088f27 Author: ngthomas Date: 2013-08-06 10:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a010db088f27 Merge - modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/AnimationPathHelper.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/Position2D.java - modules/graphics/src/main/java/com/sun/javafx/effect/EffectUtils.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseCacheFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseEffectFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseNodeEffectInput.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/AbstractPainter.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismCameraImpl.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismDefaultCamera.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismParallelCameraImpl.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismPerspectiveCameraImpl.java Changeset: 78a1636e68b1 Author: ngthomas Date: 2013-08-06 14:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/78a1636e68b1 Merge - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/CheckBoxTableCell.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/EditingCell.java - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupScene.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupStage.java - netbeans/android/glass-lib-lens/Android.mk - netbeans/android/glass-lib-lens/nbproject/configurations.xml - netbeans/android/glass-lib-lens/nbproject/project.xml Changeset: 97666cdda3fd Author: David Grieve Date: 2013-08-07 08:29 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/97666cdda3fd Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Wed Aug 7 07:32:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Aug 2013 14:32:50 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130807143337.8C9224867C@hg.openjdk.java.net> Changeset: fbfd5d489bcf Author: peterz Date: 2013-08-07 18:20 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fbfd5d489bcf Upgraded to webview-deps-1.1 ! build.gradle Changeset: 79f9597ebf00 Author: Oldrich Maticka Date: 2013-08-07 16:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/79f9597ebf00 iOS: updating crosslibs to ios-libs-06; adjusting JavaFXMain, launcher ! buildSrc/ios.gradle From anton.tarasov at oracle.com Wed Aug 7 07:39:54 2013 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 07 Aug 2013 14:39:54 -0000 Subject: Multiple JFXPanel? In-Reply-To: References: <51FB65F8.6090300@oracle.com> Message-ID: <51D82C31.1030509@oracle.com> Hi Pedro, On 05.08.2013 2:13, Pedro Duque Vieira wrote: > Hi Anton, > > Thanks for your reply. > > Actually I wasn't clear enough when I explained my app. > My app is composed of a MDI style interface but each window belongs to the same JFrame, so there > is only one JFrame but multiple internal frames. One of these internal frames has a JFXPanel with > a scene in it. I intend to migrate the rest of the internal frames to javafx one by one using this > approach. Sorry, I didn't get it. > > My question was is this a viable way to do this? Or am I going to pay a performance penalty from > having multiple JFXPanels (hence multiple scenes) inside the same app (the same JFrame)? Actually, it doesn't matter for an embedded scene where you embed it, to a separate frame or to an internal one. In both the cases the embedded scene will have the same machinery behind. Just for curiosity, I've modified my testcase to be MDI like and got the same performance scores. So, your case should not bring any additional performance decrease, except for the difference b/w your fx & swing implementations which may depend. Thanks, Anton. > > From what people have told me in this mailing list, they are using multiple JFXPanels without any > significant performance penalty, anyway it would be interesting hearing the opinion from you, > JavaFX dev team guys. > > Thanks once again for your replies, best regards, > > On Fri, Aug 2, 2013 at 8:55 AM, Anton V. Tarasov > wrote: > > Hi Pedro, > > I've made the following experiment. I've created two simple test cases: one is pure fx stage > showing WebView which animated some guimark2 benchmarks, another one is the same WebView > wrapped with JFXPanel put in JFrame. > > I ran each test case with a single, two or four toplevels (Stages or JFrames, appropriately) > and measured performance difference. I noticed that for the swing test case, adding more > toplevels decreased performance with the same proportion like the fx test case did (despite > the fact that fx performed relatively faster, of course). For instance, for the Vector > Charting Test the ratio was directly proportional to the number of toplevels, that is doubling > the toplevels decreased performance by two times equally for both fx and swing cases. > > This more or less proves the fact that adding another embedded scene into your app doesn't > bring anything except another scene. > > Thanks, > Anton. > > > On 01.08.2013 2:45, Pedro Duque Vieira wrote: > > Hi, > > I have a doubt. I have a swing app with embed javafx scene. My app has kind > of a MDI style interface. Right now only one window has been converted to > JavaFX, basically it's a window with a JFXPanel in it. > My question is if I want to convert the other windows as well should I also > put a JFXPanel in them? I would than have 2 JFXPanels in my app, does that > mean I would have 2 JavaFX scenes? Is that the way to do it? Would that > seriously hurt performance? > > Thank you in advance, best regards, > > > > > > -- > Pedro Duque Vieira From phidias51 at gmail.com Wed Aug 7 07:54:37 2013 From: phidias51 at gmail.com (Mark Fortner) Date: Wed, 7 Aug 2013 07:54:37 -0700 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: References: Message-ID: The showcase sounds like a good idea, but if the goal is to be able to use it to convince people that JavaFX is a viable platform, wouldn't it be better if you could download and try the application (maybe even web start it)? After all, the proof of the pudding is in the eating. What about component developers? Wouldn't it be nice to showcase components (complete with screenshots and maven/gradle snippets ala mvnrepository.com)? Perhaps taking that a step further, wouldn't it be nice if there was a simple way to deploy a component so that you could play with it in an interactive showcase like Ensemble? Component developers might be able to simply register their components on the server as Ensemble plugins. As the user browses through the component catalog in Ensemble, they simply select a component and it's automatically downloaded and started. They could begin playing with it almost immediately. What if all of that were part of a "Java Start" menu item or dock item. Whenever you install Java, rather than being asked to install "Ask" or some other bloatware, you get the option of installing the catalog. Anyway, just a few ideas for getting the word out about Java (and JavaFX) on the desktop. Cheers, Mark On Wed, Aug 7, 2013 at 4:34 AM, Klaus Eckelt wrote: > Hi, > > as i moved our MusicPlayer Project to SourceForge yesterday, I saw you > can't select JavaFX as used GUI technology. > I guess this should be added (i'll try to suggest it somewhere) and would > allow to filter for FX Applications there. > > Regards > //Klaus > > From: openjfx-dev-bounces at openjdk.java.net [mailto: > > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Sven Reimers > > Sent: Dienstag, 6. August 2013 07:55 > > To: Richard Bair > > Cc: openjfx mailing list; Pedro Duque Vieira > > Subject: > > Re: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) > > > > So we should start and assemble them on a community JavaFX showcase page? > > > > Should we try to get Jim Weaver and Gerrit involved? > > > > -Sven > > Am 06.08.2013 06:19 schrieb "Richard Bair" : > > > > > Here is another one on the Oracle page: > > > http://www.oracle.com/technetwork/java/javafx/codelse-1984189.html > > > > > > Richard > > > > > > On Aug 4, 2013, at 6:15 AM, Sven Reimers > wrote: > > > > > > Hi, > > > > > > from my perspective a showcase list saying technology X is used by the > > > top ten largest engineering companies is always very nice to convince > > > people they are not basing a long term project/product on an used, not > > > widespread technology. > > > > > > So for me building a showcase page is a key thing for helping in the > > > decision making process. > > > > > > -Sven > > > > > > > > > On Sun, Aug 4, 2013 at 10:12 AM, Johan Vos wrote: > > > > > >> Hi, > > >> > > >> I agree such an overview page would definitely help, but the go/no-go > > >> decisions I often see have less to do with convincing customers about > > >> JavaFX being the right technology. Customers have a number of > > >> requirements, and if I can tell them JavaFX is capable of doing that, > > >> they trust me (and they will blame me when I'm wrong). > > >> > > >> The key bummer I've seen so far is (yet again) wide deployment. "It > > >> should run on tablets" and "Our Customers should be able to use > > >> [install] this very easily". > > >> I am very much aware of the progress being made in both areas, so I'm > > >> not complaining at all -- but there is a lot of work to be done. > > >> Just want to set expectations right: a cool overview of what is > > >> already achieved with JavaFX is not going to convince all potential > > >> customers -- in my experience the deployment is still the major > > >> reasons why a number of companies are not in favor of JavaFX yet. > > >> > > >> - Johan > > >> > > >> > > >> > > >> 2013/8/4 Anton Epple > > >> > > >> > A combination of a page describing an individual application, like > > >> > the > > >> one > > >> > you linked here, would be one part and -more important- a page that > > >> lists > > >> > *all* the applications with a screenshot and a short description. > > >> > The latter would be important, because it's a showcase for decision > > >> > makers > > >> who > > >> > are yet undecided if JavaFX is the right technology. > > >> > > > >> > Before that page existed for NB Platform, I had the same > > >> > discussions I > > >> now > > >> > have for potential JavaFX projects. Developers are in doubt if the > > >> > technology is mature/performant/secure/whatever enough for their > > >> > large/unique/graphically demanding/etc. project. After they see the > > >> page, > > >> > they're convinced that it can be done. > > >> > > > >> > It's especially useful if you need to convince a team. Typically > > >> > there's at least one person in favor of a different technology (for > > >> > JavaFX it's typically GWT) and such a page is a great FUD-killer. > > >> > > > >> > Am 01.08.2013 um 22:40 schrieb Richard Bair < > Richard.Bair at oracle.com > > >: > > >> > > > >> > > Something I guess would go on such a page? > > >> > > > > >> > > http://fxexperience.com/2013/08/javafx-hd-menus-on-raspberrypi/ > > >> > > > > >> > > On Aug 1, 2013, at 3:21 AM, Anton Epple > > >> wrote: > > >> > > > > >> > >> Great idea, there's a site that does the same for NetBeans > > >> > >> Platform > > >> > Apps: > > >> > >> > > >> > >> https://platform.netbeans.org/screenshots.html > > >> > >> > > >> > >> I can tell from my own experience that it helps a lot in > > >> > >> discussions > > >> > with customers to show them that NASA, NATO, Boeing, UNO, US Army, > > >> > and > > >> many > > >> > others are building on top of NB Platform. > > >> > >> > > >> > >> From the maintainer of this site, I know there's a lot of work > > >> involved > > >> > though, and you have to be very active in identifying users, and > > >> reaching > > >> > out to them. It's definitely not sufficient to wait for users to > > >> > submit their applications. Sometimes it can take a couple of years > > >> > from first contact to a screenshot. That said it's absolutely worth > > >> > it, and I would volunteer to help in any way I can. > > >> > >> > > >> > >> Toni > > >> > >> > > >> > >> -- > > >> > >> Anton Epple > > >> > >> > > >> > >> > > >> > >> > > >> > >> Am 28.07.2013 um 02:38 schrieb Jonathan Giles < > > >> > jonathan.giles at oracle.com>: > > >> > >> > > >> > >>> This is something that Jasper actually brought up just this > > >> > >>> morning > > >> > with Richard and I (wrt fxexperience hosting it). I suspect we may > > >> > get something underway in the coming weeks. Of course, it depends > > >> > on the community getting in touch with us and letting us talk about > > >> > them - so > > >> much > > >> > of the JavaFX world is behind corporate firewalls, where talking > > >> > about > > >> your > > >> > work is generally frowned upon. In any case, for those of you that > > >> > can > > >> talk > > >> > about your work, please email one of us off-list. > > >> > >>> -- Jonathan > > >> > >>> Sent from a touch device. Please excuse my brevity. > > >> > >>> > > >> > >>> "John C. Turnbull" wrote: > > >> > >>>> +1 > > >> > >>>> > > >> > >>>> Such a site could be very useful. > > >> > >>>> > > >> > >>>> -----Original Message----- > > >> > >>>> From: openjfx-dev-bounces at openjdk.java.net > > >> > >>>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of > > >> > >>>> Daniel Zwolenski > > >> > >>>> Sent: Sunday, 28 July 2013 09:56 > > >> > >>>> To: Pedro Duque Vieira > > >> > >>>> Cc: OpenJFX Mailing List > > >> > >>>> Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) > > >> > >>>> > > >> > >>>> The idea of a JFX Sightings page (in the tradition of the > > >> > >>>> Swing Sightings > > >> > >>>> page) has been raised before and I think is a good one. > > >> > >>>> > > >> > >>>> It deserves it's own page though, that technet section isn't > > >> > >>>> up to > > >> it > > >> > >>>> in my > > >> > >>>> opinion. > > >> > >>>> > > >> > >>>> Personally I think this would be great under the fxexperience > > >> > >>>> site > > >> as > > >> > >>>> it > > >> > >>>> partners nicely with the links of the week? > > >> > >>>> > > >> > >>>> > > >> > >>>> > > >> > >>>> On 28/07/2013, at 4:17 AM, Pedro Duque Vieira > > >> > >>>> > > >> > >>>> wrote: > > >> > >>>> > > >> > >>>>> I have an Swing/JavaFX app, the site is: http://modellus.co > > >> > >>>>> > > >> > >>>>> How can I get it to be on that real world usecases section? > > >> > >>>>> Or > > >> does > > >> > >>>> it > > >> > >>>>> not have the necessary requirements to be in it? > > >> > >>>>> > > >> > >>>>> Thanks, best regards, > > >> > >>>>> > > >> > >>>>> @John: On the JavaFx community site they have a section with > > >> > >>>>> references to > > >> > >>>>>> real world usecases. > > >> > >>>>>> > > >> http://www.oracle.com/technetwork/java/javafx/community/index.html > > >> > >>>>>> > > >> > >>>>>> On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull > > >> > >>>>>> > >> > >>>>>>> wrote: > > >> > >>>>>>> Like Daniel said, none of what we say is in any way a > > >> > >>>>>>> criticism > > >> of > > >> > >>>>>>> the JavaFX development team who, in my view and that of the > > >> entire > > >> > >>>>>>> community, are doing an awesome job. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> For mine, all the shortcomings of JavaFX (perceived or > > >> > >>>>>>> actual) > > >> can > > >> > >>>>>>> be > > >> > >>>>>> blown > > >> > >>>>>>> away if I could just demonstrate what JavaFX is really > > >> > >>>>>>> capable > > >> of. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> We have Ensemble from Oracle and also Ensemble from JFXtras > > >> (whose > > >> > >>>>>>> demo incidentally doesn't run since Java 7 Update 21). > > >> > >>>>>>> With > > >> Oracle > > >> > >>>> > > >> > >>>>>>> Ensemble > > >> > >>>>>> we > > >> > >>>>>>> can see that JavaFX has quite a nice set of basic controls > > >> > >>>>>>> and > > >> that > > >> > >>>> > > >> > >>>>>>> it at least supports very simple animations. With JFXtras > > >> Ensemble > > >> > >>>> > > >> > >>>>>>> we can see that very nice controls are possible but > > >> unfortunately > > >> > >>>>>>> many of these are > > >> > >>>>>> of > > >> > >>>>>>> a rather "whimsical" nature and not the kind of control you > > >> would > > >> > >>>>>>> use in everyday business apps. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> What else is there? > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> Of course we have rock stars like Gerrit Grunwald who > > >> > >>>>>>> frequently post awesome controls and code snippets but we > > >> > >>>>>>> really need > > >> > >>>> something > > >> > >>>>>>> that > > >> > >>>>>> brings > > >> > >>>>>>> it altogether in a kick-arse showcase. Preferably a whole > > >> suite of > > >> > >>>>>> killer > > >> > >>>>>>> apps that highlights everything JavaFX is capable of. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> Yes, that would require a lot of effort but IMHO it is > > >> absolutely > > >> > >>>>>>> worth > > >> > >>>>>> it. > > >> > >>>>>>> Without it, people like me really struggle to sell JavaFX > > >> > >>>>>>> or > > >> even > > >> > >>>>>>> get a handle on its true potential. I can promise people > > >> > >>>>>>> that > > >> more > > >> > >>>> > > >> > >>>>>>> advanced things are "possible" but given that they write > > >> > >>>>>>> the cheques, they need to see it for themselves. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> And how about a website of JavaFX reference sites? There > > >> > >>>>>>> must > > >> be > > >> > >>>>>>> big companies out there using it right? > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> In the end it doesn't matter if I personally see enormous > > >> potential > > >> > >>>> > > >> > >>>>>>> for JavaFX if I cannot convince others to see what I see. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> -jct > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> From: Daniel Zwolenski [mailto:zonski at gmail.com] > > >> > >>>>>>> Sent: Saturday, 27 July 2013 09:12 > > >> > >>>>>>> To: John C. Turnbull > > >> > >>>>>>> Cc: Richard Bair; openjfx-dev at openjdk.java.net > > >> > >>>>>>> Subject: Re: Can JavaFX do CAD? > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> +1 > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> I've failed to convince multiple clients that they should > > >> > >>>>>>> use > > >> JFX > > >> > >>>>>>> because of > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> a) lack of examples of what it can really do, and how to > > >> > >>>>>>> make > > >> it do > > >> > >>>> > > >> > >>>>>>> that (e.g. in enterprise space we have > > >> > >>>>>>> http://static.springsource.org/docs/petclinic.html) > > >> > >>>>>>> > > >> > >>>>>>> b) lack of any big or notable players out there actually > > >> > >>>>>>> using > > >> it, > > >> > >>>>>>> or at least publicly saying they are using it > > >> > >>>>>>> > > >> > >>>>>>> c) the deployment hassles vs the ease of html app > > >> > >>>>>>> deployment and > > >> > >>>> the > > >> > >>>>>>> true cross-platform-ness of html > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> After actually getting one client to trust me on it and use > > >> > >>>>>>> it > > >> on a > > >> > >>>> > > >> > >>>>>>> real, commercial app (startup), I hit problems with > > >> > >>>>>>> performance (broad interpretation of the term, not > > >> > >>>>>>> 'framerate'), crippling deployment and > > >> > >>>>>> auto > > >> > >>>>>>> updating issues, missing basic features (e.g. maximise > > >> > >>>>>>> button, coming in > > >> > >>>>>>> 2014 I believe?), unpredictability of CSS styling, and a > > >> > >>>>>>> lack of best practices for things like how to do CAD-like > > >> > >>>>>>> diagrams (not > > >> so > > >> > >>>>>>> much render performance but zooming, panning, mouse input, > > >> > >>>> layering, > > >> > >>>> dragging, etc). > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> Like John, I've been guilty of letting my frustration show > > >> > >>>>>>> in > > >> these > > >> > >>>>>> forums. > > >> > >>>>>>> Like John, it's because I want so badly for JavaFX to be > > >> > >>>>>>> the platform I develop on, it has the potential to be > > >> > >>>>>>> awesome, but things (that seem obvious and small to me) > > >> > >>>>>>> completely stop it > > >> from > > >> > >>>>>>> being usable in a real world situation for me. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> It's not that we think the JFX team aren't slogging their > > >> > >>>>>>> guts > > >> out, > > >> > >>>>>> clearly > > >> > >>>>>>> you are. It's just that in some key areas, there are > > >> > >>>>>>> small-ish blocks > > >> > >>>>>> that > > >> > >>>>>>> stop the whole rocket from launching. To then see a whole > > >> > >>>>>>> lot of effort > > >> > >>>>>> be > > >> > >>>>>>> poured into things like binary CSS/FXML compilation, Pi > > >> > >>>>>>> platform support (that's more important than iOS/Android, > > >> > >>>>>>> really?), web deployment > > >> > >>>>>> patches, > > >> > >>>>>>> or even 3D (as cool as that is), just knocks me about. > > >> > >>>>>>> Obviously your priorities are coming from somewhere > > >> > >>>>>>> different to ours, but > > >> > >>>> the > > >> > >>>>>>> way you prioritise is unfathomable to me and that > > >> > >>>>>>> definitely > > >> adds > > >> > >>>> to > > >> > >>>>>>> the frustration. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> At this stage, I am not suggesting my clients use JFX (I > > >> actively > > >> > >>>>>>> discourage them from it, in their interest). Mobile is the > > >> > >>>>>>> area > > >> > >>>> that > > >> > >>>>>>> has the > > >> > >>>>>> potential > > >> > >>>>>>> to bring JFX back into usable for me as it can compete > > >> > >>>>>>> easier > > >> with > > >> > >>>>>>> the current technologies (which are all crap). Maybe if > > >> > >>>>>>> that > > >> ends > > >> > >>>> up > > >> > >>>>>>> working > > >> > >>>>>> (a > > >> > >>>>>>> long, long road to go on that and very much an 'if') then > > >> > >>>>>>> it > > >> will > > >> > >>>>>>> seep > > >> > >>>>>> back > > >> > >>>>>>> into the desktop for me, but at a minimum the desktop > > >> > >>>>>>> deployment options will need to be improved before that's > > >> > >>>>>>> even a > > >> possibility. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> I've come to accept that I am not in the primary target > > >> > >>>>>>> audience > > >> > >>>> for > > >> > >>>>>>> JavaFX, maybe a secondary target. I don't understand who > > >> > >>>>>>> the > > >> > >>>> primary > > >> > >>>>>>> target is though, and knowing/accepting doesn't make it any > > >> > >>>>>>> less frustrating. I > > >> > >>>>>> keep > > >> > >>>>>>> involved in the hope that I might get a usable platform > > >> somewhere > > >> > >>>>>>> along > > >> > >>>>>> the > > >> > >>>>>>> way but it's more of a hope than a belief. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> So nothing really new above, but just adding my voice to > > John's. > > >> > >>>>>>> JavaFX > > >> > >>>>>> is > > >> > >>>>>>> definitely not production ready for me, my clients and the > > >> types of > > >> > >>>> > > >> > >>>>>>> apps > > >> > >>>>>> I > > >> > >>>>>>> build (e.g. consumer facing online systems, > > >> enterprise/backoffice > > >> > >>>>>> systems, > > >> > >>>>>>> form/data systems, diagramming systems). One day I hope it > > >> > >>>>>>> will > > >> be, > > >> > >>>> > > >> > >>>>>>> but it's moving extremely slowly or not at all in the areas > > >> > >>>>>>> that would make it so for me. Meanwhile the competitors > > >> > >>>>>>> (primarily JavaScript based solutions) are improving > > >> > >>>>>>> rapidly in the areas > > >> > >>>> where > > >> > >>>>>>> they have traditionally been weak. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> On Sat, Jul 27, 2013 at 8:30 AM, John C. Turnbull < > > >> > >>>>>> ozemale at ozemail.com.au > > >> > >>>>>>> > wrote: > > >> > >>>>>>> > > >> > >>>>>>> Hi Richard, > > >> > >>>>>>> > > >> > >>>>>>> I have to stop posting late at night, that one came across > > >> > >>>>>>> as > > >> > >>>> really > > >> > >>>>>> ANGRY! > > >> > >>>>>>> > > >> > >>>>>>> It's not anger, it's passion... and frustration. > > >> > >>>>>>> > > >> > >>>>>>> I am frustrated because I spend much of my day trying to > > >> convince > > >> > >>>> my > > >> > >>>>>>> employer that we should be using JavaFX. They ask me > > >> > >>>>>>> questions > > >> > >>>> like: > > >> > >>>>>>> > > >> > >>>>>>> "What happens if Oracle abandons JavaFX just like Sun did > > >> > >>>>>>> with > > >> JMF, > > >> > >>>>>> Java3D, > > >> > >>>>>>> JOGL etc. ?" > > >> > >>>>>>> > > >> > >>>>>>> I say: > > >> > >>>>>>> > > >> > >>>>>>> "This is Oracle, not Sun." > > >> > >>>>>>> > > >> > >>>>>>> They say: > > >> > >>>>>>> > > >> > >>>>>>> "Can you show me what JavaFX can do? There must be examples > > >> > >>>>>>> out there right?" > > >> > >>>>>>> > > >> > >>>>>>> And I say: > > >> > >>>>>>> > > >> > >>>>>>> "Sure, here's Ensemble." > > >> > >>>>>>> > > >> > >>>>>>> They say: > > >> > >>>>>>> > > >> > >>>>>>> "OK, so it has a nice set of basic controls and can do > > >> > >>>>>>> simple animations but what about more complex things like > > Flash?" > > >> > >>>>>>> > > >> > >>>>>>> ...hence the dancing cat reference. > > >> > >>>>>>> > > >> > >>>>>>> It's not that my employer *needs* dancing cats, it's just > > >> > >>>>>>> that > > >> they > > >> > >>>> > > >> > >>>>>>> need > > >> > >>>>>> to > > >> > >>>>>>> see that there is more to JavaFX than red circle > > >> > >>>>>>> transitions. I can't > > >> > >>>>>> even > > >> > >>>>>>> prove to them that JavaFX is capable of dancing cats. They > > >> don't > > >> > >>>>>>> have > > >> > >>>>>> the > > >> > >>>>>>> resources to fund me to develop something more > > >> > >>>>>>> sophisticated but they > > >> > >>>>>> tell > > >> > >>>>>>> me that if JavaFX truly was a "mature" technology (like I > > >> > >>>>>>> tell > > >> > >>>> them) > > >> > >>>>>>> then where are all the examples? > > >> > >>>>>>> > > >> > >>>>>>> I am finding it difficult to convince them that JavaFX is > > >> > >>>> production > > >> > >>>>>> ready > > >> > >>>>>>> and is not still in "experimental" mode because I am unable > > >> > >>>>>>> to > > >> > >>>>>> demonstrate > > >> > >>>>>>> its true capabilities or refer them to many examples of > > >> > >>>>>>> people > > >> (and > > >> > >>>> > > >> > >>>>>>> I > > >> > >>>>>> mean > > >> > >>>>>>> big companies) actually using it. > > >> > >>>>>>> > > >> > >>>>>>> The main concerns of my employer and I think many companies > > >> > >>>>>>> in a similar situation is that JavaFX won't survive long > > >> > >>>>>>> term and > > >> that > > >> > >>>> it > > >> > >>>>>>> is only > > >> > >>>>>> really > > >> > >>>>>>> suitable for form based applications. Then of course there > > >> > >>>>>>> is > > >> the > > >> > >>>>>>> whole > > >> > >>>>>>> "HTML5 runs on all platforms" argument but that's another > > >> story... > > >> > >>>>>>> > > >> > >>>>>>> So this is why I think it's imperative that Oracle invests > > >> > >>>>>>> in developing > > >> > >>>>>> a > > >> > >>>>>>> true showcase application for JavaFX. Something that > > >> non-technical > > >> > >>>>>> people > > >> > >>>>>>> (like managers who make decisions about where the money > > >> > >>>>>>> goes) > > >> can > > >> > >>>>>>> look at it and go "wow!". > > >> > >>>>>>> > > >> > >>>>>>> I am just not getting my managers to go "wow" at what I can > > >> > >>>>>>> show them > > >> > >>>>>> with > > >> > >>>>>>> JavaFX at the moment. > > >> > >>>>>>> > > >> > >>>>>>> Every comment or apparent criticism I post about JavaFX is > > >> > >>>>>>> from > > >> the > > >> > >>>> > > >> > >>>>>>> perspective that I am trying to deal with real-world > > >> > >>>>>>> problems > > >> and > > >> > >>>>>>> people who require proof (such as demos, reference sites > > >> > >>>>>>> etc.) > > >> and > > >> > >>>>>>> not because I myself think JavaFX is not up to scratch. > > >> > >>>>>>> > > >> > >>>>>>> It's quite the opposite actually. > > >> > >>>>>>> > > >> > >>>>>>> I am a very, very strong believer and supporter of JavaFX > > >> > >>>>>>> and > > >> have > > >> > >>>>>>> many reasons both personal and professional as to why I > > >> > >>>>>>> want it > > >> to > > >> > >>>>>>> be a > > >> > >>>>>> massive > > >> > >>>>>>> success. As I have said before, there are plenty of people > > >> > >>>>>>> who praise JavaFX and tend to avoid the very real issues > > >> > >>>>>>> that are restricting its adoption. I just think we have to > > >> > >>>>>>> face these > > >> > >>>> issues > > >> > >>>>>>> head on if we are to compete in what is a very cut-throat > > >> industry. > > >> > >>>>>>> > > >> > >>>>>>> -jct > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> -----Original Message----- > > >> > >>>>>>> From: Richard Bair [mailto:richard.bair at oracle.com > > >> > >>>>>>> ] > > >> > >>>>>>> Sent: Saturday, 27 July 2013 01:40 > > >> > >>>>>>> To: John C. Turnbull > > >> > >>>>>>> Cc: 'Daniel Zwolenski'; openjfx-dev at openjdk.java.net > > >> > >>>>>>> > > >> > >>>>>>> Subject: Re: Can JavaFX do CAD? > > >> > >>>>>>> > > >> > >>>>>>>> For Flash, there are literally millions of examples of > > >> > >>>>>>>> fancy/complex/impressive graphics and animations out there > > >> > >>>>>>>> that > > >> > >>>> can > > >> > >>>>>>>> be really impressive at times. I have not seen ONE such > > >> example > > >> > >>>> in > > >> > >>>>>> JavaFX! > > >> > >>>>>>> > > >> > >>>>>>> Point to one? > > >> > >>>>>>> > > >> > >>>>>>> Have you seen any of the JavaOne examples? The movie wall > > >> > >>>>>>> or > > >> movies > > >> > >>>> > > >> > >>>>>>> on a stack of 3D cubes was pretty good. But I guess you're > > >> > >>>>>>> not interested in > > >> > >>>>>> the > > >> > >>>>>>> 3D aspect? What is it you are looking for exactly? > > >> > >>>>>>> Different > > >> people > > >> > >>>> > > >> > >>>>>>> (on this > > >> > >>>>>>> list) have had different perceptions on both (a) what's > > >> important > > >> > >>>>>>> and (b) what kind of graphics they're interested in. Most > > >> > >>>>>>> people would deride the dancing cat as being totally > > >> > >>>>>>> irrelevant to the types of applications they're trying to > > >> > >>>>>>> build (the basis for > > >> much > > >> > >>>> of > > >> > >>>>>>> flash animations is shape > > >> > >>>>>> morphing, > > >> > >>>>>>> you can find some code here > > >> > >>>> https://gist.github.com/gontard/5029764). > > >> > >>>>>>> > > >> > >>>>>>> On the other hand, JavaFX is not a replacement for OpenGL. > > >> Drawing > > >> > >>>>>>> 25 million lines is just not something we can do right now, > > >> > >>>>>>> especially in a resource constrained environment. I've > > >> > >>>>>>> already commented on the memory overhead (which would > > >> > >>>>>>> continue to be an issue even if the drawing part of the > > problem were solved). > > >> > >>>>>>> > > >> > >>>>>>> I've pushed to graphics repo the StretchyGrid, which is > > >> > >>>>>>> about > > >> 300k > > >> > >>>>>>> line nodes (the actual amount is variable, see the javadoc > > >> > >>>>>>> comments). At 300k nodes the scene graph overhead is > > >> > >>>>>>> negligible > > >> on > > >> > >>>>>>> the FX side, dirty opts > > >> > >>>>>> is > > >> > >>>>>>> taking a long time to run, and painting is really slow. > > >> > >>>>>>> > > >> > >>>>>>> PULSE: 347 [122ms:222ms] > > >> > >>>>>>> T12 (8 +0ms): CSS Pass > > >> > >>>>>>> T12 (8 +0ms): Layout Pass > > >> > >>>>>>> T12 (47 +53ms): Waiting for previous rendering > > >> > >>>>>>> T12 (100 +1ms): Copy state to render graph > > >> > >>>>>>> T10 (101 +16ms): Dirty Opts Computed > > >> > >>>>>>> T10 (117 +105ms): Painted > > >> > >>>>>>> Counters: > > >> > >>>>>>> Nodes rendered: 306565 > > >> > >>>>>>> Nodes visited during render: 306565 > > >> > >>>>>>> > > >> > >>>>>>> If I were doing this by hand in open GL, I think the > > >> > >>>>>>> drawing > > >> would > > >> > >>>>>>> be essentially free, if I used LINES with GL anti-aliasing, > > >> > >>>>>>> I > > >> could > > >> > >>>> > > >> > >>>>>>> send 'em all down to the card in a single shot (and if I > > >> > >>>>>>> had a modern GL I could > > >> > >>>>>> do > > >> > >>>>>>> LINES + FXAA or one of the other per-pixel AA algorithms > > >> available > > >> > >>>>>>> and it would turn out pretty nice). Because our shapes > > >> > >>>>>>> don't implement the > > >> > >>>>>> non-AA > > >> > >>>>>>> path, and our AA involves software rasterization and > > >> > >>>>>>> uploading > > >> of > > >> > >>>>>> pixels, I > > >> > >>>>>>> expect that to be the main source of the 105ms time being > > >> > >>>>>>> spent > > >> > >>>> here. > > >> > >>>>>>> > > >> > >>>>>>> Also I noticed (by turning on prism.showdirty=true) that > > >> > >>>>>>> the > > >> entire > > >> > >>>> > > >> > >>>>>>> grid > > >> > >>>>>> is > > >> > >>>>>>> being painted every time, even though visually it looks > > >> > >>>>>>> like > > >> only a > > >> > >>>> > > >> > >>>>>>> small subset actually needs to be changed. But that's > > >> > >>>>>>> really a > > >> > >>>> minor > > >> > >>>>>>> thing, as > > >> > >>>>>> I > > >> > >>>>>>> said, drawing this many lines should basically be free if I > > >> > >>>>>>> configure "smooth" to false in the app. Except that right > > >> > >>>>>>> now > > >> it is > > >> > >>>> > > >> > >>>>>>> totally not implemented (in NGShape): > > >> > >>>>>>> > > >> > >>>>>>> public void setAntialiased(boolean aa) { > > >> > >>>>>>> // We don't support aliased shapes at this time } > > >> > >>>>>>> > > >> > >>>>>>> The point of stretchy grid is not to say "wow look at this > > >> amazing > > >> > >>>> demo". > > >> > >>>>>>> The point is to say "what happens if I put in 300K nodes. > > >> > >>>>>>> Where > > >> > >>>> does > > >> > >>>>>>> the system start to fall over?". > > >> > >>>>>>> > > >> > >>>>>>> Richard= > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>> > > >> > >>>>> > > >> > >>>>> -- > > >> > >>>>> Pedro Duque Vieira > > >> > >> > > >> > > > > >> > > > >> > > > >> > > > > > > > > > > > > -- > > > 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 > > > > > > > > > > > > > > > -- > Klaus Eckelt > Brigittaplatz 23/7 > 1200 Wien > Klaus.Eckelt at gmail.com > From david.grieve at oracle.com Wed Aug 7 08:08:31 2013 From: david.grieve at oracle.com (David Grieve) Date: Wed, 7 Aug 2013 11:08:31 -0400 Subject: Proposal to move default style-class from Control to SkinBase Message-ID: Currently, a control has a default style-class. For example, you can use .button in a style-sheet to style a Button. I propose to move the default style-class from the control to the skin (RT-32186). The impetus for this change is two-fold. Firstly, it can be argued that setting the style-class of a control should be left to the developer, that imposing a default style-class is implementation detail leaking into the public API. Moving the default style-class from the control to the skin addresses this concern. The second motive has to do with CSS processing itself. When a skin is set on a control, the control adopts the styles of the skin and css is reapplied to the control in order to pick up the new styles. Thus, it takes two CSS passes to fully style a control. By moving the default style-class to the skin, the control no longer has to adopt the skin's styles. Styles still have to be applied to the skin, but this can be done from the skinProperty's invalidated method. These subtle changes - not adopting the styles and applying css to the skin from skinProperty's invalidated method - will simplify the code in Control. The reason for moving the default from Control to SkinBase and not Skin is that there is no API in Skin for getting style-class (or any other css selector attributes). Skin could implement the Styleable interface, but that would not be backward compatible. Another issue related to CSS processing has to do with looking up cached, matching styles for a node. When the skin is set on the node and adopts the styles of the skin, css is reapplied. This means that the css implementation will look for matching styles for the control. There is a map that has a node's simple class name, style-class, and id (the 'css selector' aspects of a node) as a key and the matching styles as a value. Since none of the 'css selector' aspects of the node have changed, the previously cached value is returned from the map. Then when the styles are applied to the node, css says 'oh, I've already calculated values for this kind of node' and doesn't bother looking up the properties that were added by the skin. This causes problems such as https://javafx-jira.kenai.com/browse/RT-31691. The cache lookup issue can be resolved in other ways, such as adding the list of properties to the key, or adding a flag to cause css to calculate a value if there is no previously calculated value found. But I believe that moving the default style-class will lead to cleaner code. If a control no longer adopts the skin's styles, then the control and the skin could be styled as separate entities. This would mean that instead of .tool-bar { -fx-orientation: vertical; -fx-spacing: 3; } one would have to write ToolBar { -fx-orientation: vertical; } .tool-bar: { -fx-spacing: 3; } since orientation is a property of ToolBar and spacing a property of ToolBarSkin. This is an issue for maintaining backward compatibility with existing stylesheets. This isn't a issue for caspian or modena but is for author style-sheets and inline styles. I have some ideas here, but all of them rather clunky and kludgey. My question on this point is whether or not this is a real concern. From pedro.duquevieira at gmail.com Wed Aug 7 08:13:02 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 7 Aug 2013 16:13:02 +0100 Subject: Multiple JFXPanel? In-Reply-To: <51D82C31.1030509@oracle.com> References: <51FB65F8.6090300@oracle.com> <51D82C31.1030509@oracle.com> Message-ID: Hi Anton, Thank you very much for your effort! Best regards, On Sat, Jul 6, 2013 at 3:39 PM, Anton V. Tarasov wrote: > Hi Pedro, > > > On 05.08.2013 2:13, Pedro Duque Vieira wrote: > > Hi Anton, > > Thanks for your reply. > > Actually I wasn't clear enough when I explained my app. > My app is composed of a MDI style interface but each window belongs to the > same JFrame, so there is only one JFrame but multiple internal frames. One > of these internal frames has a JFXPanel with a scene in it. I intend to > migrate the rest of the internal frames to javafx one by one using this > approach. > > > Sorry, I didn't get it. > > > > My question was is this a viable way to do this? Or am I going to pay a > performance penalty from having multiple JFXPanels (hence multiple scenes) > inside the same app (the same JFrame)? > > > Actually, it doesn't matter for an embedded scene where you embed it, to a > separate frame or to an internal one. In both the cases the embedded scene > will have the same machinery behind. > Just for curiosity, I've modified my testcase to be MDI like and got the > same performance scores. > > So, your case should not bring any additional performance decrease, except > for the difference b/w your fx & swing implementations which may depend. > > Thanks, > Anton. > > > > From what people have told me in this mailing list, they are using > multiple JFXPanels without any significant performance penalty, anyway it > would be interesting hearing the opinion from you, JavaFX dev team guys. > > Thanks once again for your replies, best regards, > > On Fri, Aug 2, 2013 at 8:55 AM, Anton V. Tarasov > wrote: > >> Hi Pedro, >> >> I've made the following experiment. I've created two simple test cases: >> one is pure fx stage showing WebView which animated some guimark2 >> benchmarks, another one is the same WebView wrapped with JFXPanel put in >> JFrame. >> >> I ran each test case with a single, two or four toplevels (Stages or >> JFrames, appropriately) and measured performance difference. I noticed that >> for the swing test case, adding more toplevels decreased performance with >> the same proportion like the fx test case did (despite the fact that fx >> performed relatively faster, of course). For instance, for the Vector >> Charting Test the ratio was directly proportional to the number of >> toplevels, that is doubling the toplevels decreased performance by two >> times equally for both fx and swing cases. >> >> This more or less proves the fact that adding another embedded scene into >> your app doesn't bring anything except another scene. >> >> Thanks, >> Anton. >> >> >> On 01.08.2013 2:45, Pedro Duque Vieira wrote: >> >>> Hi, >>> >>> I have a doubt. I have a swing app with embed javafx scene. My app has >>> kind >>> of a MDI style interface. Right now only one window has been converted to >>> JavaFX, basically it's a window with a JFXPanel in it. >>> My question is if I want to convert the other windows as well should I >>> also >>> put a JFXPanel in them? I would than have 2 JFXPanels in my app, does >>> that >>> mean I would have 2 JavaFX scenes? Is that the way to do it? Would that >>> seriously hurt performance? >>> >>> Thank you in advance, best regards, >>> >>> >> > > > -- > Pedro Duque Vieira > > > -- Pedro Duque Vieira From Fabrizio.Giudici at tidalwave.it Wed Aug 7 08:35:16 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Wed, 07 Aug 2013 17:35:16 +0200 Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) In-Reply-To: References: Message-ID: On Wed, 07 Aug 2013 16:54:37 +0200, Mark Fortner wrote: > The showcase sounds like a good idea, but if the goal is to be able to > use > it to convince people that JavaFX is a viable platform, wouldn't it be > better if you could download and try the application (maybe even web > start > it)? After all, the proof of the pudding is in the eating. Guys, if the application is available, this is a plus, but there's plenty of non-distributable applications. Even better if the application is open source, so people can check it out, but not all applications are open source. When the interview include the developers, who talk also in name of the company, this is very valuable information. So, let's just provide the best information possible, case by case. Rich client apps are strong mostly in the industry, and most of the stuff here is proprietary. Anyway, let's not forget that in most cases decisions about which technology to use are done and/or approved by managers, and they usually don't download and run applications. They are assured if they see a widespread adoption of the technology. Bad or good, they reason in terms of powerpoint slides and diagrams about the market share. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From grazertwo at gmail.com Wed Aug 7 09:35:37 2013 From: grazertwo at gmail.com (=?ISO-8859-1?Q?Martin_Kl=E4hn?=) Date: Wed, 7 Aug 2013 18:35:37 +0200 Subject: Form of ProgressIndicator Message-ID: Hi guys, I've just realized that the ProgressIndicator in Modena isn't shown as a rotating circle. It looks like somebody pried apart the ProgressWheel and left it apart. Has there been a change in the UI of ProgressIndicator or is this a bug and if so should I file a bug? Regards, Martin From david.grieve at oracle.com Wed Aug 7 09:57:18 2013 From: david.grieve at oracle.com (David Grieve) Date: Wed, 7 Aug 2013 12:57:18 -0400 Subject: Form of ProgressIndicator In-Reply-To: References: Message-ID: https://javafx-jira.kenai.com/browse/RT-31196 On Aug 7, 2013, at 12:35 PM, Martin Kl?hn wrote: > Hi guys, > > I've just realized that the ProgressIndicator in Modena isn't shown as a > rotating circle. It looks like somebody pried apart the ProgressWheel and > left it apart. > > Has there been a change in the UI of ProgressIndicator or is this a bug and > if so should I file a bug? > > Regards, > Martin From mick.fleming at oracle.com Wed Aug 7 10:00:11 2013 From: mick.fleming at oracle.com (mick.fleming) Date: Wed, 07 Aug 2013 18:00:11 +0100 Subject: Form of ProgressIndicator In-Reply-To: References: Message-ID: <52027D1B.4010705@oracle.com> Hi Martin, > I've just realized that the ProgressIndicator in Modena isn't shown as a > rotating circle. It looks like somebody pried apart the ProgressWheel and > left it apart. > it sounds like you're seeing RT-31196 : https://javafx-jira.kenai.com/browse/RT-31196 regards, mick From tbee at tbee.org Wed Aug 7 11:15:23 2013 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 07 Aug 2013 20:15:23 +0200 Subject: Proposal to move default style-class from Control to SkinBase In-Reply-To: References: Message-ID: <52028EBB.3090108@tbee.org> Since day 1 of writing controls for JFX I've used the approach that a skin sets its own style class, and that class is used in the CSS. If a control should not be aware of how it is rendered, what sense does it make to have visual styling set on it? So in a skin I do: this.getStyleClass().add( "AgendaWeekSkin" ); And in the CSS: .AgendaWeekSkin { ... } In this way I already have separate styling between control and the active skin. So I can only +1 any change that more clearly moves any visual aspect closer to the skin. That said, of course there are certain things of a control that are very generic, like a textfield having font styling. These styling could/should still be stylable on the control and not the skin. OTOH, usually such things are set on a more abstract level. Tom On 2013-08-07 17:08, David Grieve wrote: > Currently, a control has a default style-class. For example, you can use .button in a style-sheet to style a Button. I propose to move the default style-class from the control to the skin (RT-32186). The impetus for this change is two-fold. > > Firstly, it can be argued that setting the style-class of a control should be left to the developer, that imposing a default style-class is implementation detail leaking into the public API. Moving the default style-class from the control to the skin addresses this concern. > > The second motive has to do with CSS processing itself. When a skin is set on a control, the control adopts the styles of the skin and css is reapplied to the control in order to pick up the new styles. Thus, it takes two CSS passes to fully style a control. By moving the default style-class to the skin, the control no longer has to adopt the skin's styles. Styles still have to be applied to the skin, but this can be done from the skinProperty's invalidated method. These subtle changes - not adopting the styles and applying css to the skin from skinProperty's invalidated method - will simplify the code in Control. > > The reason for moving the default from Control to SkinBase and not Skin is that there is no API in Skin for getting style-class (or any other css selector attributes). Skin could implement the Styleable interface, but that would not be backward compatible. > > Another issue related to CSS processing has to do with looking up cached, matching styles for a node. When the skin is set on the node and adopts the styles of the skin, css is reapplied. This means that the css implementation will look for matching styles for the control. There is a map that has a node's simple class name, style-class, and id (the 'css selector' aspects of a node) as a key and the matching styles as a value. Since none of the 'css selector' aspects of the node have changed, the previously cached value is returned from the map. Then when the styles are applied to the node, css says 'oh, I've already calculated values for this kind of node' and doesn't bother looking up the properties that were added by the skin. This causes problems such as https://javafx-jira.kenai.com/browse/RT-31691. > > The cache lookup issue can be resolved in other ways, such as adding the list of properties to the key, or adding a flag to cause css to calculate a value if there is no previously calculated value found. But I believe that moving the default style-class will lead to cleaner code. > > If a control no longer adopts the skin's styles, then the control and the skin could be styled as separate entities. This would mean that instead of > > .tool-bar { -fx-orientation: vertical; -fx-spacing: 3; } > > one would have to write > > ToolBar { -fx-orientation: vertical; } .tool-bar: { -fx-spacing: 3; } > > since orientation is a property of ToolBar and spacing a property of ToolBarSkin. This is an issue for maintaining backward compatibility with existing stylesheets. This isn't a issue for caspian or modena but is for author style-sheets and inline styles. I have some ideas here, but all of them rather clunky and kludgey. My question on this point is whether or not this is a real concern. > > From hang.vo at oracle.com Wed Aug 7 13:03:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Aug 2013 20:03:08 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for rt-28851 - gcc compiler bug creates visual defects on DFB and other software rendering pipelines. Message-ID: <20130807200357.C3F13486A0@hg.openjdk.java.net> Changeset: 101df1012d49 Author: Lisa.Selle at oracle.com Date: 2013-08-07 15:54 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/101df1012d49 Fix for rt-28851 - gcc compiler bug creates visual defects on DFB and other software rendering pipelines. ! modules/graphics/src/main/native-prism-sw/PiscesPaint.c From pedro.duquevieira at gmail.com Wed Aug 7 13:41:10 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 7 Aug 2013 21:41:10 +0100 Subject: Proposal to move default style-class from Control to SkinBase Message-ID: Hi David, I'm not going to directly answer your question but I'm rather gonna touch on a problem I see regarding JavaFX CSS. Forgive me for not directly sticking to the subject of your email. The issue I see is that JavaFX CSS significantly differs from W3C CSS, that is the CSS that is used on the web. I've already touch this subject before but didn't have much answer from this mailing list. The reason why I bring it back again is that the more I do web development the more this seems unappropriated. Having JavaFX CSS differ from W3C CSS has the following disadvantages: - Designers coming from web development (they are the majority) will struggle with JavaFX CSS - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing out on this tooling that significantly enhances CSS. You can do really cool stuff with Compass. - Cannot reuse what already is out there on the web. And there are a huge amount of examples there. - Re-inventing the wheel. My personal opinion is that you should try to harness the work that already exists especially when you have few resources. People have already spent some time on this, tested and fixed issues with it. So why not "stand on the shoulder of giants". I'm not saying you should introduce CSS layout, that is a headache and a problem that they're trying to solve in CSS3, but all the rest can be changed to be the same as CSS. You can even have both working side by side, the current JavaFX CSS and a newer more W3C conforming CSS so that you don't break existing apps. I don't see any advantage of having a CSS different from W3C one, if I was going to make one different I would have created a newer more simpler language to express an apps appearance. Not used CSS. Thanks, best regards, -- Pedro Duque Vieira From tom.schindl at bestsolution.at Wed Aug 7 13:56:19 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 07 Aug 2013 22:56:19 +0200 Subject: Proposal to move default style-class from Control to SkinBase In-Reply-To: References: Message-ID: <5202B473.3030805@bestsolution.at> If I get your complain right what you want has nothing to do with CSS but you are requesting that the complete FX API is remodeled, CSS is simply a way to set properties of your Nodes in the SceneGraph, in a none intrusive way. You need to differiate between CSS as a language and the properties one can set on DOM/SceneGraph-Nodes. >From the selector point (language) of view FX-CSS support all important selector types, but because the nodes in the DOM (=SceneGraph in FX) are different you have other properties. So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. Tom On 07.08.13 22:41, Pedro Duque Vieira wrote: > Hi David, > > I'm not going to directly answer your question but I'm rather gonna touch > on a problem I see regarding JavaFX CSS. Forgive me for not directly > sticking to the subject of your email. > > The issue I see is that JavaFX CSS significantly differs from W3C CSS, that > is the CSS that is used on the web. > I've already touch this subject before but didn't have much answer from > this mailing list. The reason why I bring it back again is that the more I > do web development the more this seems unappropriated. > > Having JavaFX CSS differ from W3C CSS has the following disadvantages: > > - Designers coming from web development (they are the majority) will > struggle with JavaFX CSS > - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing > out on this tooling that significantly enhances CSS. You can do really cool > stuff with Compass. > - Cannot reuse what already is out there on the web. And there are a > huge amount of examples there. > - Re-inventing the wheel. My personal opinion is that you should try to > harness the work that already exists especially when you have few > resources. People have already spent some time on this, tested and fixed > issues with it. So why not "stand on the shoulder of giants". > > I'm not saying you should introduce CSS layout, that is a headache and a > problem that they're trying to solve in CSS3, but all the rest can be > changed to be the same as CSS. You can even have both working side by side, > the current JavaFX CSS and a newer more W3C conforming CSS so that you > don't break existing apps. > > I don't see any advantage of having a CSS different from W3C one, if I was > going to make one different I would have created a newer more simpler > language to express an apps appearance. Not used CSS. > > Thanks, best regards, > > > From tom.schindl at bestsolution.at Wed Aug 7 14:00:58 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 07 Aug 2013 23:00:58 +0200 Subject: Proposal to move default style-class from Control to SkinBase In-Reply-To: <5202B473.3030805@bestsolution.at> References: <5202B473.3030805@bestsolution.at> Message-ID: <5202B58A.2020201@bestsolution.at> Oh and one more thing: IIRC you can run e.g. less in rhino so feeding it a less file with -fx properties should get you css file which you can pass on to FX. Tom On 07.08.13 22:56, Tom Schindl wrote: > If I get your complain right what you want has nothing to do with CSS > but you are requesting that the complete FX API is remodeled, CSS is > simply a way to set properties of your Nodes in the SceneGraph, in a > none intrusive way. > > You need to differiate between CSS as a language and the properties one > can set on DOM/SceneGraph-Nodes. > >>From the selector point (language) of view FX-CSS support all important > selector types, but because the nodes in the DOM (=SceneGraph in FX) are > different you have other properties. > > So if you invent the same node-types you have on the web (lets face it > there's only a handful of them most important are most likely div,span) > and give them the same properties you know from the web you can copy > your Web-CSS stylesheet to your FX-Application. > > Tom > > On 07.08.13 22:41, Pedro Duque Vieira wrote: >> Hi David, >> >> I'm not going to directly answer your question but I'm rather gonna touch >> on a problem I see regarding JavaFX CSS. Forgive me for not directly >> sticking to the subject of your email. >> >> The issue I see is that JavaFX CSS significantly differs from W3C CSS, that >> is the CSS that is used on the web. >> I've already touch this subject before but didn't have much answer from >> this mailing list. The reason why I bring it back again is that the more I >> do web development the more this seems unappropriated. >> >> Having JavaFX CSS differ from W3C CSS has the following disadvantages: >> >> - Designers coming from web development (they are the majority) will >> struggle with JavaFX CSS >> - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing >> out on this tooling that significantly enhances CSS. You can do really cool >> stuff with Compass. >> - Cannot reuse what already is out there on the web. And there are a >> huge amount of examples there. >> - Re-inventing the wheel. My personal opinion is that you should try to >> harness the work that already exists especially when you have few >> resources. People have already spent some time on this, tested and fixed >> issues with it. So why not "stand on the shoulder of giants". >> >> I'm not saying you should introduce CSS layout, that is a headache and a >> problem that they're trying to solve in CSS3, but all the rest can be >> changed to be the same as CSS. You can even have both working side by side, >> the current JavaFX CSS and a newer more W3C conforming CSS so that you >> don't break existing apps. >> >> I don't see any advantage of having a CSS different from W3C one, if I was >> going to make one different I would have created a newer more simpler >> language to express an apps appearance. Not used CSS. >> >> Thanks, best regards, >> >> >> > From jeff at reportmill.com Wed Aug 7 14:45:38 2013 From: jeff at reportmill.com (Jeff Martin) Date: Wed, 7 Aug 2013 16:45:38 -0500 Subject: Swing and JavaFX thread merge In-Reply-To: <52021C0F.2090608@oracle.com> References: <52021C0F.2090608@oracle.com> Message-ID: I thought I was getting this automatically - when I run on my desktop, I can bring up a JOptionPane from a Swing thread and JFXPanels (correctly) block. But when I run from Java Web Start, they don't, and I end up with sporadic SwingUtilities.computeIntersection NullPointerException. Is there a secret setting that has a different default with JAWS? jeff On Aug 7, 2013, at 5:06 AM, Artem Ananiev wrote: > Hi, Pedro Duque Vieira, > > this is in progress. JDK part is tracked in 8015477: > > http://bugs.sun.com/view_bug.do?bug_id=8015477 > > JavaFX part is described in RT-30694: > > https://javafx-jira.kenai.com/browse/RT-30694 > > Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. > > Thanks, > > Artem > > On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: >> Hi, >> >> Some time ago there was a patch submitted which for all purposes merged the >> swing and javafx thread, making it easier for developers working on a >> swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX >> >> Is this available now (I was under the impression it is)? How do I use it? >> >> Thanks in advance, >> From hang.vo at oracle.com Wed Aug 7 14:47:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Aug 2013 21:47:50 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32199: drawText doing work when the glyphlist#getGlyphCount() == 0 Message-ID: <20130807214830.7FB4C486A3@hg.openjdk.java.net> Changeset: 747685094fb1 Author: Felipe Heidrich Date: 2013-08-07 14:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/747685094fb1 RT-32199: drawText doing work when the glyphlist#getGlyphCount() == 0 ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGText.java From hang.vo at oracle.com Wed Aug 7 15:51:00 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 07 Aug 2013 22:51:00 +0000 Subject: hg: openjfx/2u/dev/rt: 2 new changesets Message-ID: <20130807225106.0462F486A6@hg.openjdk.java.net> Changeset: aef521116893 Author: hudson Date: 2013-08-02 09:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/aef521116893 Added tag 2.2.40-b37 for changeset c2c325536f52 ! .hgtags Changeset: 34e462c596ce Author: hudson Date: 2013-08-07 11:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/34e462c596ce Added tag 2.2.40-b38 for changeset aef521116893 ! .hgtags From John_Smith at symantec.com Wed Aug 7 16:08:29 2013 From: John_Smith at symantec.com (John Smith) Date: Wed, 7 Aug 2013 16:08:29 -0700 Subject: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase) Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221685BF63AD@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. +1 to this idea (in a 3rd party lib). > The issue I see is that JavaFX CSS significantly differs from W3C CSS It surprises me that this issue comes up so rarely in JavaFX forums (almost never) - perhaps it is because JavaFX developers tend to be Java developers rather than designers. A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 "need to reconcile JavaFX CSS with W3C CSS3" 0 votes (no interest at all?). In terms of conversion of existing html css resources to javafx css, you may be interested in a Q&A with a developer who converted the Foundation look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from his point of view the conversion process was quite straight-forward - though perhaps that was partially luck of the draw. Below is a copy and paste from an earlier JavaFX forum post on this topic: You know, sometimes I find JavaFX's lack of certain css features refreshing. It is nice to have all, well, almost all, of the JavaFX CSS documented on one page. I think if you were to do the same thing for w3c css then it would end up with a much larger, more difficult to understand document and even what the contents of that document should be would probably be pretty controversial, in the same kind of way that the HTML5 specification ended up being. Microsoft contributed over 7000 tests to w3c just to cover only a subset of the css rules available in browsers today. The webkit project lists almost a thousand open CSS bugs: https://bugs.webkit.org/buglist.cgi?product=WebKit&component=CSS&resolution=---. So implementing even partial w3c CSS support is a complex project. When I first started using JavaFX CSS I found the differences to w3c CSS quite jarring, and it was hard to account for them. Now that I am used to JavaFX CSS, I don't have as much of an issue. The difference in names and semantics is going to be an impediment to designers working on JavaFX who are familar with w3c CSS - but the designers will quickly also discover that FXML is not HTML and Java is not JavaScript and JavaFX deployment is not HTML deployment. So, perhaps, in the larger picture, it is not as big a deal as it would seem. Still, one can't help think that any impediment to people easily picking up and adopting JavaFX is doing the technology a disservice. There are other advantages in having the JavaFX CSS in its own namespace to w3c css, in that it can evolve seperately, it is not expected to be exactly the same because it has a different name, it is not expected to fully implement w3c css as browsers do because it's clearly a different thing by name, etc. There is even precedent for it in the use by mozilla of moz- CSS prefixes and webkit css properties http://css-infos.net/properties/webkit - the web as not as standard as a lot of people propose. JavaFX CSS is backing a JavaFX rendering engine and not an HTML rendering engine. It is quite remarkable that Oracle was able to build and make available a CSS model for JavaFX that feels as familiar as it does to w3c css, as w3c css is targeted very strongly toward styling a completely different technology set (HTML markup and document object model). It would be useful to have a tool which translates w3c css to approximations of JavaFX css and vice versa, or the ability for JavaFX to have a mode (perhaps a boolean value when a stylesheet is loaded) to perform an automatic alias or mapping of w3c css to javafx (at least for the subset of w3c css which would make sense to automatically translate to JavaFX css). (David commented on this part previously - "Closing the gap between JavaFX CSS and W3C CSS will be an evolutionary process. It would be nice to use a standard's based stylesheet but there is not always a 1-1 mapping to JavaFX. But for those properties that can be mapped, it is something that should be supported. For example, we should be able to handle "font" or "-fx-font".") Comments above relate to the naming and semantic meanings of css tags, and not the syntax and parsing of css (as both w3c css and javaFX css seem to be equivalent in the later regard). The JavaFX css model is really powerful and I have found really useful some of the additions that it adds above the baseline 2.1 css that is found consistently in browsers. With the upcoming Java CSS object model http://javafx-jira.kenai.com/browse/RT-17293 "CSS Style Object Model in Java" 23 votes, you will also get better programmatic access from Java, which seems to be a highly requested feature. Regards, John -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl Sent: Wednesday, August 07, 2013 2:01 PM To: openjfx-dev at openjdk.java.net Subject: Re: Proposal to move default style-class from Control to SkinBase Oh and one more thing: IIRC you can run e.g. less in rhino so feeding it a less file with -fx properties should get you css file which you can pass on to FX. Tom On 07.08.13 22:56, Tom Schindl wrote: > If I get your complain right what you want has nothing to do with CSS > but you are requesting that the complete FX API is remodeled, CSS is > simply a way to set properties of your Nodes in the SceneGraph, in a > none intrusive way. > > You need to differiate between CSS as a language and the properties > one can set on DOM/SceneGraph-Nodes. > >>From the selector point (language) of view FX-CSS support all >>important > selector types, but because the nodes in the DOM (=SceneGraph in FX) > are different you have other properties. > > So if you invent the same node-types you have on the web (lets face it > there's only a handful of them most important are most likely > div,span) and give them the same properties you know from the web you > can copy your Web-CSS stylesheet to your FX-Application. > > Tom > > On 07.08.13 22:41, Pedro Duque Vieira wrote: >> Hi David, >> >> I'm not going to directly answer your question but I'm rather gonna >> touch on a problem I see regarding JavaFX CSS. Forgive me for not >> directly sticking to the subject of your email. >> >> The issue I see is that JavaFX CSS significantly differs from W3C >> CSS, that is the CSS that is used on the web. >> I've already touch this subject before but didn't have much answer >> from this mailing list. The reason why I bring it back again is that >> the more I do web development the more this seems unappropriated. >> >> Having JavaFX CSS differ from W3C CSS has the following disadvantages: >> >> - Designers coming from web development (they are the majority) will >> struggle with JavaFX CSS >> - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing >> out on this tooling that significantly enhances CSS. You can do really cool >> stuff with Compass. >> - Cannot reuse what already is out there on the web. And there are a >> huge amount of examples there. >> - Re-inventing the wheel. My personal opinion is that you should try to >> harness the work that already exists especially when you have few >> resources. People have already spent some time on this, tested and fixed >> issues with it. So why not "stand on the shoulder of giants". >> >> I'm not saying you should introduce CSS layout, that is a headache >> and a problem that they're trying to solve in CSS3, but all the rest >> can be changed to be the same as CSS. You can even have both working >> side by side, the current JavaFX CSS and a newer more W3C conforming >> CSS so that you don't break existing apps. >> >> I don't see any advantage of having a CSS different from W3C one, if >> I was going to make one different I would have created a newer more >> simpler language to express an apps appearance. Not used CSS. >> >> Thanks, best regards, >> >> >> > From tom.schindl at bestsolution.at Wed Aug 7 16:24:56 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 08 Aug 2013 01:24:56 +0200 Subject: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase) In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D221685BF63AD@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <411E73D23DEC4C46BA48F2B6D8BF3D221685BF63AD@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <5202D748.6000405@bestsolution.at> I couldn't resist - http://tomsondev.bestsolution.at/2013/08/07/using-less-in-javafx/ Tom On 08.08.13 01:08, John Smith wrote: > >> So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. > > +1 to this idea (in a 3rd party lib). > >> The issue I see is that JavaFX CSS significantly differs from W3C CSS > > It surprises me that this issue comes up so rarely in JavaFX forums (almost never) - perhaps it is because JavaFX developers tend to be Java developers rather than designers. > > A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 "need to reconcile JavaFX CSS with W3C CSS3" 0 votes (no interest at all?). > > In terms of conversion of existing html css resources to javafx css, you may be interested in a Q&A with a developer who converted the Foundation look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from his point of view the conversion process was quite straight-forward - though perhaps that was partially luck of the draw. > > Below is a copy and paste from an earlier JavaFX forum post on this topic: > > You know, sometimes I find JavaFX's lack of certain css features refreshing. It is nice to have all, well, almost all, of the JavaFX CSS documented on one page. I think if you were to do the same thing for w3c css then it would end up with a much larger, more difficult to understand document and even what the contents of that document should be would probably be pretty controversial, in the same kind of way that the HTML5 specification ended up being. Microsoft contributed over 7000 tests to w3c just to cover only a subset of the css rules available in browsers today. The webkit project lists almost a thousand open CSS bugs: https://bugs.webkit.org/buglist.cgi?product=WebKit&component=CSS&resolution=---. So implementing even partial w3c CSS support is a complex project. > > When I first started using JavaFX CSS I found the differences to w3c CSS quite jarring, and it was hard to account for them. Now that I am used to JavaFX CSS, I don't have as much of an issue. The difference in names and semantics is going to be an impediment to designers working on JavaFX who are familar with w3c CSS - but the designers will quickly also discover that FXML is not HTML and Java is not JavaScript and JavaFX deployment is not HTML deployment. So, perhaps, in the larger picture, it is not as big a deal as it would seem. Still, one can't help think that any impediment to people easily picking up and adopting JavaFX is doing the technology a disservice. > > There are other advantages in having the JavaFX CSS in its own namespace to w3c css, in that it can evolve seperately, it is not expected to be exactly the same because it has a different name, it is not expected to fully implement w3c css as browsers do because it's clearly a different thing by name, etc. There is even precedent for it in the use by mozilla of moz- CSS prefixes and webkit css properties http://css-infos.net/properties/webkit - the web as not as standard as a lot of people propose. JavaFX CSS is backing a JavaFX rendering engine and not an HTML rendering engine. It is quite remarkable that Oracle was able to build and make available a CSS model for JavaFX that feels as familiar as it does to w3c css, as w3c css is targeted very strongly toward styling a completely different technology set (HTML markup and document object model). > > It would be useful to have a tool which translates w3c css to approximations of JavaFX css and vice versa, or the ability for JavaFX to have a mode (perhaps a boolean value when a stylesheet is loaded) to perform an automatic alias or mapping of w3c css to javafx (at least for the subset of w3c css which would make sense to automatically translate to JavaFX css). (David commented on this part previously - "Closing the gap between JavaFX CSS and W3C CSS will be an evolutionary process. It would be nice to use a standard's based stylesheet but there is not always a 1-1 mapping to JavaFX. But for those properties that can be mapped, it is something that should be supported. For example, we should be able to handle "font" or "-fx-font".") > > Comments above relate to the naming and semantic meanings of css tags, and not the syntax and parsing of css (as both w3c css and javaFX css seem to be equivalent in the later regard). > > The JavaFX css model is really powerful and I have found really useful some of the additions that it adds above the baseline 2.1 css that is found consistently in browsers. With the upcoming Java CSS object model http://javafx-jira.kenai.com/browse/RT-17293 "CSS Style Object Model in Java" 23 votes, you will also get better programmatic access from Java, which seems to be a highly requested feature. > > Regards, > John > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Schindl > Sent: Wednesday, August 07, 2013 2:01 PM > To: openjfx-dev at openjdk.java.net > Subject: Re: Proposal to move default style-class from Control to SkinBase > > Oh and one more thing: IIRC you can run e.g. less in rhino so feeding it a less file with -fx properties should get you css file which you can pass on to FX. > > Tom > > On 07.08.13 22:56, Tom Schindl wrote: >> If I get your complain right what you want has nothing to do with CSS >> but you are requesting that the complete FX API is remodeled, CSS is >> simply a way to set properties of your Nodes in the SceneGraph, in a >> none intrusive way. >> >> You need to differiate between CSS as a language and the properties >> one can set on DOM/SceneGraph-Nodes. >> >> >From the selector point (language) of view FX-CSS support all >>> important >> selector types, but because the nodes in the DOM (=SceneGraph in FX) >> are different you have other properties. >> >> So if you invent the same node-types you have on the web (lets face it >> there's only a handful of them most important are most likely >> div,span) and give them the same properties you know from the web you >> can copy your Web-CSS stylesheet to your FX-Application. >> >> Tom >> >> On 07.08.13 22:41, Pedro Duque Vieira wrote: >>> Hi David, >>> >>> I'm not going to directly answer your question but I'm rather gonna >>> touch on a problem I see regarding JavaFX CSS. Forgive me for not >>> directly sticking to the subject of your email. >>> >>> The issue I see is that JavaFX CSS significantly differs from W3C >>> CSS, that is the CSS that is used on the web. >>> I've already touch this subject before but didn't have much answer >>> from this mailing list. The reason why I bring it back again is that >>> the more I do web development the more this seems unappropriated. >>> >>> Having JavaFX CSS differ from W3C CSS has the following disadvantages: >>> >>> - Designers coming from web development (they are the majority) will >>> struggle with JavaFX CSS >>> - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing >>> out on this tooling that significantly enhances CSS. You can do really cool >>> stuff with Compass. >>> - Cannot reuse what already is out there on the web. And there are a >>> huge amount of examples there. >>> - Re-inventing the wheel. My personal opinion is that you should try to >>> harness the work that already exists especially when you have few >>> resources. People have already spent some time on this, tested and fixed >>> issues with it. So why not "stand on the shoulder of giants". >>> >>> I'm not saying you should introduce CSS layout, that is a headache >>> and a problem that they're trying to solve in CSS3, but all the rest >>> can be changed to be the same as CSS. You can even have both working >>> side by side, the current JavaFX CSS and a newer more W3C conforming >>> CSS so that you don't break existing apps. >>> >>> I don't see any advantage of having a CSS different from W3C one, if >>> I was going to make one different I would have created a newer more >>> simpler language to express an apps appearance. Not used CSS. >>> >>> Thanks, best regards, >>> >>> >>> >> > From pedro.duquevieira at gmail.com Wed Aug 7 17:05:26 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 8 Aug 2013 01:05:26 +0100 Subject: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase) Message-ID: > > > So if you invent the same node-types you have on the web (lets face it > there's only a handful of them most important are most likely div,span) and > give them the same properties you know from the web you can copy your > Web-CSS stylesheet to your FX-Application. > +1 to this idea (in a 3rd party lib). > > The issue I see is that JavaFX CSS significantly differs from W3C CSS > It surprises me that this issue comes up so rarely in JavaFX forums > (almost never) - perhaps it is because JavaFX developers tend to be Java > developers rather than designers. > A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 "need > to reconcile JavaFX CSS with W3C CSS3" 0 votes (no interest at all?). > In terms of conversion of existing html css resources to javafx css, you > may be interested in a Q&A with a developer who converted the Foundation > look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from > his point of view the conversion process was quite straight-forward - > though perhaps that was partially luck of the draw. > Below is a copy and paste from an earlier JavaFX forum post on this topic: > You know, sometimes I find JavaFX's lack of certain css features > refreshing. It is nice to have all, well, almost all, of the JavaFX CSS > documented on one page. I think if you were to do the same thing for w3c > css then it would end up with a much larger, more difficult to understand > document and even what the contents of that document should be would > probably be pretty controversial, in the same kind of way that the HTML5 > specification ended up being. Microsoft contributed over 7000 tests to w3c > just to cover only a subset of the css rules available in browsers today. > The webkit project lists almost a thousand open CSS bugs: > https://bugs.webkit.org/buglist.cgi?product=WebKit&component=CSS&resolution=---. > So implementing even partial w3c CSS support is a complex project. > When I first started using JavaFX CSS I found the differences to w3c CSS > quite jarring, and it was hard to account for them. Now that I am used to > JavaFX CSS, I don't have as much of an issue. The difference in names and > semantics is going to be an impediment to designers working on JavaFX who > are familar with w3c CSS - but the designers will quickly also discover > that FXML is not HTML and Java is not JavaScript and JavaFX deployment is > not HTML deployment. So, perhaps, in the larger picture, it is not as big a > deal as it would seem. Still, one can't help think that any impediment to > people easily picking up and adopting JavaFX is doing the technology a > disservice. > There are other advantages in having the JavaFX CSS in its own namespace > to w3c css, in that it can evolve seperately, it is not expected to be > exactly the same because it has a different name, it is not expected to > fully implement w3c css as browsers do because it's clearly a different > thing by name, etc. There is even precedent for it in the use by mozilla of > moz- CSS prefixes and webkit css properties > http://css-infos.net/properties/webkit - the web as not as standard as a > lot of people propose. JavaFX CSS is backing a JavaFX rendering engine and > not an HTML rendering engine. It is quite remarkable that Oracle was able > to build and make available a CSS model for JavaFX that feels as familiar > as it does to w3c css, as w3c css is targeted very strongly toward styling > a completely different technology set (HTML markup and document object > model). > It would be useful to have a tool which translates w3c css to > approximations of JavaFX css and vice versa, or the ability for JavaFX to > have a mode (perhaps a boolean value when a stylesheet is loaded) to > perform an automatic alias or mapping of w3c css to javafx (at least for > the subset of w3c css which would make sense to automatically translate to > JavaFX css). (David commented on this part previously - "Closing the gap > between JavaFX CSS and W3C CSS will be an evolutionary process. It would be > nice to use a standard's based stylesheet but there is not always a 1-1 > mapping to JavaFX. But for those properties that can be mapped, it is > something that should be supported. For example, we should be able to > handle "font" or "-fx-font".") > Comments above relate to the naming and semantic meanings of css tags, and > not the syntax and parsing of css (as both w3c css and javaFX css seem to > be equivalent in the later regard). > The JavaFX css model is really powerful and I have found really useful > some of the additions that it adds above the baseline 2.1 css that is found > consistently in browsers. With the upcoming Java CSS object model > http://javafx-jira.kenai.com/browse/RT-17293 "CSS Style Object Model in > Java" 23 votes, you will also get better programmatic access from Java, > which seems to be a highly requested feature. > Regards, > John Hi John, Thanks for your input. That's exactly my view on things. I'm also surprised so few people ever talk about this, not wanting to hurt anybody's feelings, I guess the vast majority probably don't do web development or are not really acquainted with CSS and its intricacies, but that's just a guess. Also one more advantage I see if JavaFX complies with w3c CSS (on the things that count) is that CSS is a continuously evolving technology with a lot of people already working on it and evolving it (for instance, the broken layout system is being rewritten with things like the box model), if JavaFX follows along it will benefit from that web of knowledge. @Tom Schindl: I'm not talking about only the "CSS language", there is no such thing (I guess its also a bit controversial to call "JavaFX CSS", "CSS" at all). W3C CSS is much more than a "language", what good would CSS be if you hand't got keywords, like "font", "color", "margin", etc. You also don't have to invent all the nodes "div", etc, to rip the benefits of having a more compliant W3C CSS. These can come later. One of the problems is that JavaFX adds a "-fx-" prefix to every keyword, the use of this prefix was meant to distinguish experimental browser new specific features during their testing, experimentation period. This was during an experimental phase, and was meant to be dropped as soon as all browser implementations of that new feature work the same. In JavaFX by contrast, this was added for the purposes of being able to write in the same stylesheet file both web w3c css and JavaFX css without the 2 clashing into each other. But I don't agree with this, and I think it's such a minor use case that the disadvantages clearly outweigh the advantages. For this use case why not have 2 separate stylesheets, what's the issue of separating things into 2 distinct files and also I think that it's much simpler to read and maintain 2 different stylesheets that cram everything into 1. But all this can be changed, we can have both -fx- prefixed properties and non -fx- prefixed properties and with this not breaking backwards compatibility. Thanks, regards, -- Pedro Duque Vieira From pedro.duquevieira at gmail.com Wed Aug 7 17:11:49 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 8 Aug 2013 01:11:49 +0100 Subject: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase) In-Reply-To: References: Message-ID: I might have jumped the gun when talking about LESS, I'm not actually familiar with it and thought it would be along the same lines like SASS. But still you can't use SASS or Compass with JavaFX CSS. Cheers, On Thu, Aug 8, 2013 at 1:05 AM, Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > > So if you invent the same node-types you have on the web (lets face it >> there's only a handful of them most important are most likely div,span) and >> give them the same properties you know from the web you can copy your >> Web-CSS stylesheet to your FX-Application. >> +1 to this idea (in a 3rd party lib). >> > The issue I see is that JavaFX CSS significantly differs from W3C CSS >> It surprises me that this issue comes up so rarely in JavaFX forums >> (almost never) - perhaps it is because JavaFX developers tend to be Java >> developers rather than designers. >> A related open jira request is >> http://javafx-jira.kenai.com/browse/RT-9272 "need to reconcile JavaFX >> CSS with W3C CSS3" 0 votes (no interest at all?). >> In terms of conversion of existing html css resources to javafx css, you >> may be interested in a Q&A with a developer who converted the Foundation >> look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - >> from his point of view the conversion process was quite straight-forward - >> though perhaps that was partially luck of the draw. >> Below is a copy and paste from an earlier JavaFX forum post on this topic: >> You know, sometimes I find JavaFX's lack of certain css features >> refreshing. It is nice to have all, well, almost all, of the JavaFX CSS >> documented on one page. I think if you were to do the same thing for w3c >> css then it would end up with a much larger, more difficult to understand >> document and even what the contents of that document should be would >> probably be pretty controversial, in the same kind of way that the HTML5 >> specification ended up being. Microsoft contributed over 7000 tests to w3c >> just to cover only a subset of the css rules available in browsers today. >> The webkit project lists almost a thousand open CSS bugs: >> https://bugs.webkit.org/buglist.cgi?product=WebKit&component=CSS&resolution=---. >> So implementing even partial w3c CSS support is a complex project. >> When I first started using JavaFX CSS I found the differences to w3c CSS >> quite jarring, and it was hard to account for them. Now that I am used to >> JavaFX CSS, I don't have as much of an issue. The difference in names and >> semantics is going to be an impediment to designers working on JavaFX who >> are familar with w3c CSS - but the designers will quickly also discover >> that FXML is not HTML and Java is not JavaScript and JavaFX deployment is >> not HTML deployment. So, perhaps, in the larger picture, it is not as big a >> deal as it would seem. Still, one can't help think that any impediment to >> people easily picking up and adopting JavaFX is doing the technology a >> disservice. >> There are other advantages in having the JavaFX CSS in its own namespace >> to w3c css, in that it can evolve seperately, it is not expected to be >> exactly the same because it has a different name, it is not expected to >> fully implement w3c css as browsers do because it's clearly a different >> thing by name, etc. There is even precedent for it in the use by mozilla of >> moz- CSS prefixes and webkit css properties >> http://css-infos.net/properties/webkit - the web as not as standard as a >> lot of people propose. JavaFX CSS is backing a JavaFX rendering engine and >> not an HTML rendering engine. It is quite remarkable that Oracle was able >> to build and make available a CSS model for JavaFX that feels as familiar >> as it does to w3c css, as w3c css is targeted very strongly toward styling >> a completely different technology set (HTML markup and document object >> model). >> It would be useful to have a tool which translates w3c css to >> approximations of JavaFX css and vice versa, or the ability for JavaFX to >> have a mode (perhaps a boolean value when a stylesheet is loaded) to >> perform an automatic alias or mapping of w3c css to javafx (at least for >> the subset of w3c css which would make sense to automatically translate to >> JavaFX css). (David commented on this part previously - "Closing the gap >> between JavaFX CSS and W3C CSS will be an evolutionary process. It would be >> nice to use a standard's based stylesheet but there is not always a 1-1 >> mapping to JavaFX. But for those properties that can be mapped, it is >> something that should be supported. For example, we should be able to >> handle "font" or "-fx-font".") >> Comments above relate to the naming and semantic meanings of css tags, >> and not the syntax and parsing of css (as both w3c css and javaFX css seem >> to be equivalent in the later regard). >> The JavaFX css model is really powerful and I have found really useful >> some of the additions that it adds above the baseline 2.1 css that is found >> consistently in browsers. With the upcoming Java CSS object model >> http://javafx-jira.kenai.com/browse/RT-17293 "CSS Style Object Model in >> Java" 23 votes, you will also get better programmatic access from Java, >> which seems to be a highly requested feature. >> Regards, >> John > > > Hi John, > > Thanks for your input. That's exactly my view on things. > > I'm also surprised so few people ever talk about this, not wanting to hurt > anybody's feelings, I guess the vast majority probably don't do web > development or are not really acquainted with CSS and its intricacies, but > that's just a guess. > > Also one more advantage I see if JavaFX complies with w3c CSS (on the > things that count) is that CSS is a continuously evolving technology with a > lot of people already working on it and evolving it (for instance, the > broken layout system is being rewritten with things like the box model), if > JavaFX follows along it will benefit from that web of knowledge. > > @Tom Schindl: I'm not talking about only the "CSS language", there is no > such thing (I guess its also a bit controversial to call "JavaFX CSS", > "CSS" at all). W3C CSS is much more than a "language", what good would CSS > be if you hand't got keywords, like "font", "color", "margin", etc. > You also don't have to invent all the nodes "div", etc, to rip the > benefits of having a more compliant W3C CSS. These can come later. > > One of the problems is that JavaFX adds a "-fx-" prefix to every keyword, > the use of this prefix was meant to distinguish experimental browser new > specific features during their testing, experimentation period. This was > during an experimental phase, and was meant to be dropped as soon as all > browser implementations of that new feature work the same. > In JavaFX by contrast, this was added for the purposes of being able to > write in the same stylesheet file both web w3c css and JavaFX css without > the 2 clashing into each other. But I don't agree with this, and I think > it's such a minor use case that the disadvantages clearly outweigh the > advantages. For this use case why not have 2 separate stylesheets, what's > the issue of separating things into 2 distinct files and also I think that > it's much simpler to read and maintain 2 different stylesheets that cram > everything into 1. > But all this can be changed, we can have both -fx- prefixed properties and > non -fx- prefixed properties and with this not breaking backwards > compatibility. > > Thanks, regards, > > -- > Pedro Duque Vieira -- Pedro Duque Vieira From hang.vo at oracle.com Wed Aug 7 18:03:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 01:03:09 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31689 NPE when laying out AdvancedMediaPlayer after fullscreen Message-ID: <20130808010343.55D0D486B7@hg.openjdk.java.net> Changeset: 4fc452b6d918 Author: dmasada Date: 2013-08-07 17:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4fc452b6d918 RT-31689 NPE when laying out AdvancedMediaPlayer after fullscreen ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/media/advancedmedia/MediaControl.java From david.grieve at oracle.com Wed Aug 7 18:09:18 2013 From: david.grieve at oracle.com (David Grieve) Date: Wed, 7 Aug 2013 21:09:18 -0400 Subject: Proposal to move default style-class from Control to SkinBase In-Reply-To: References: Message-ID: I appreciate the feedback and would like to point you to https://javafx-jira.kenai.com/browse/RT-9272. Your constructive criticism and input is welcome there, too. On Aug 7, 2013, at 4:41 PM, Pedro Duque Vieira wrote: > Hi David, > > I'm not going to directly answer your question but I'm rather gonna touch > on a problem I see regarding JavaFX CSS. Forgive me for not directly > sticking to the subject of your email. > > The issue I see is that JavaFX CSS significantly differs from W3C CSS, that > is the CSS that is used on the web. > I've already touch this subject before but didn't have much answer from > this mailing list. The reason why I bring it back again is that the more I > do web development the more this seems unappropriated. > > Having JavaFX CSS differ from W3C CSS has the following disadvantages: > > - Designers coming from web development (they are the majority) will > struggle with JavaFX CSS > - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing > out on this tooling that significantly enhances CSS. You can do really cool > stuff with Compass. > - Cannot reuse what already is out there on the web. And there are a > huge amount of examples there. > - Re-inventing the wheel. My personal opinion is that you should try to > harness the work that already exists especially when you have few > resources. People have already spent some time on this, tested and fixed > issues with it. So why not "stand on the shoulder of giants". > > I'm not saying you should introduce CSS layout, that is a headache and a > problem that they're trying to solve in CSS3, but all the rest can be > changed to be the same as CSS. You can even have both working side by side, > the current JavaFX CSS and a newer more W3C conforming CSS so that you > don't break existing apps. > > I don't see any advantage of having a CSS different from W3C one, if I was > going to make one different I would have created a newer more simpler > language to express an apps appearance. Not used CSS. > > Thanks, best regards, > > > > -- > Pedro Duque Vieira From richard.bair at oracle.com Wed Aug 7 20:11:15 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 7 Aug 2013 20:11:15 -0700 Subject: Proposal to move default style-class from Control to SkinBase In-Reply-To: References: Message-ID: <3DFDFD0C-B960-415F-AF12-18397CC9789D@oracle.com> Hi David, > Currently, a control has a default style-class. For example, you can use .button in a style-sheet to style a Button. I propose to move the default style-class from the control to the skin (RT-32186). The impetus for this change is two-fold. > > Firstly, it can be argued that setting the style-class of a control should be left to the developer, that imposing a default style-class is implementation detail leaking into the public API. Moving the default style-class from the control to the skin addresses this concern. > > The second motive has to do with CSS processing itself. When a skin is set on a control, the control adopts the styles of the skin and css is reapplied to the control in order to pick up the new styles. Thus, it takes two CSS passes to fully style a control. By moving the default style-class to the skin, the control no longer has to adopt the skin's styles. Styles still have to be applied to the skin, but this can be done from the skinProperty's invalidated method. These subtle changes - not adopting the styles and applying css to the skin from skinProperty's invalidated method - will simplify the code in Control. It seems like removing the built-in style classes would be quite a breaking change. One pattern used today in order to "turn off" the default styles (without having to wholly replace the skins) is to clear the styleClass list. But if the styleClass list is already empty, this pattern won't work and existing code will break. Another problem is that existing CSS styles just say .tool-bar { -fx-orientation: vertical; }, and those would no longer work. Is there another way to accomplish your second motive? I need more time to work through the rest of this, maybe we can chat offline to get me up to speed, but my initial concern is that removing the style class will break people fairly substantially. Richard From richard.bair at oracle.com Wed Aug 7 20:21:13 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 7 Aug 2013 20:21:13 -0700 Subject: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase) In-Reply-To: References: Message-ID: > Also one more advantage I see if JavaFX complies with w3c CSS (on the > things that count) is that CSS is a continuously evolving technology with a > lot of people already working on it and evolving it (for instance, the > broken layout system is being rewritten with things like the box model), if > JavaFX follows along it will benefit from that web of knowledge. One misconception here is that there is any way for us to follow along for free. There is not an existing CSS engine that we can reuse. They are all heavily tied to their native C/C++ browser implementations and are all based on DOM nodes, not scene graph nodes. When the W3C or WhatWG adds new CSS capabilities, we don't get those for free, regardless of the syntax that we were to use. As for following the standard, we do intend to do that (and always have), at least insofar as it makes sense. But some things in Web CSS just don't make sense in the FX scene graph (layout being an obvious example, but some of the CSS selectors that allow you to insert dynamic nodes into the system don't directly map unless we were to implement it via FXML instead of HTML). > @Tom Schindl: I'm not talking about only the "CSS language", there is no > such thing That is not correct. There is a CSS language (syntax) which is independent of the various specific pseudo-classes or declarations supported by a specific target (node type). You can find grammars on the internet. > One of the problems is that JavaFX adds a "-fx-" prefix to every keyword, > the use of this prefix was meant to distinguish experimental browser new > specific features during their testing, experimentation period. This was > during an experimental phase, and was meant to be dropped as soon as all > browser implementations of that new feature work the same. As a practical matter, it is hard for the browsers to ever drop the extension syntax, they just add in the new standard (dropping the existing syntax breaks untold millions of websites). The same is true for FX, we can't drop the -fx- prefix. And in fact we *added* the -fx- prefix at the last minute before we shipped 2.0 (iirc). We didn't used to have the -fx- prefix for everything. The problem was the the CSS standard was a moving target, and we have to maintain compatibility, so we just put -fx- in front of everything to make sure that we wouldn't be burned (as we already had been once or twice) when the at-the-time unfinished CSS 3 backgrounds and borders specification changed out from under us. In fact, the reason we put in -fx- was *exactly* to allow us to have CSS-compliant non-fx- rules later on. > In JavaFX by contrast, this was added for the purposes of being able to > write in the same stylesheet file both web w3c css and JavaFX css without > the 2 clashing into each other. That isn't really the reason why. It was so that we could be standards compliant. We shipped before the CSS 3 spec was completed, so we needed to use the vender extension prefix to make sure that we could later be spec compliant (to the degree that makes sense). > But all this can be changed, we can have both -fx- prefixed properties and > non -fx- prefixed properties and with this not breaking backwards > compatibility. That's correct, and has always been the plan. But in practice (and as John pointed out) this isn't really that big of a deal -- I'd rather have CSS animations before we dealt with this, to be honest. Cheers Richard From hang.vo at oracle.com Wed Aug 7 22:17:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 05:17:49 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130808051914.B874D486C4@hg.openjdk.java.net> Changeset: 779268099d54 Author: jgiles Date: 2013-08-08 09:47 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/779268099d54 [DOC ONLY] Added javadoc to TableView to explain the new sorted list functionality. ! modules/controls/src/main/java/javafx/scene/control/TableView.java Changeset: 41bec1a02dd2 Author: jgiles Date: 2013-08-08 10:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/41bec1a02dd2 RT-32201: 8.0-controls-scrum-702: Controls.TableView-Sort performance benchmark fails with ClassCastException ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java Changeset: bfc4fa2ec8fd Author: jgiles Date: 2013-08-08 17:01 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bfc4fa2ec8fd RT-31015: javafx.scene.control.TableView: TableCell.cancelEdit should not be called twice on cancelling editing ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java From tomas.brandalik at oracle.com Thu Aug 8 00:59:07 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Thu, 08 Aug 2013 09:59:07 +0200 Subject: current state of gradle script for Android? In-Reply-To: References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> <51FA69F9.1040402@oracle.com> Message-ID: <52034FCB.1000207@oracle.com> Hi Tobi, shouldn't be necessary to patch android.gradle file or set ANDROID_CROSS_TOOLS_VER anymore. The latest changes resolve path to a toolchain taking into account variants of NDK. Thank you for testing it. -Tomas On 08/01/2013 11:41 PM, Tobias Bley wrote: > Thanks Tomas, > > after changing android.gradle script line "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.4.3?)? to "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could successfully build OpenJFX for Android von Mac OS X 10.9! > > So now I?m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in ?com.oracle.dalvik? package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? > > Best regards, > Tobi > > > Am 01.08.2013 um 16:00 schrieb tomas.brandalik : > >> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. >> http://developer.android.com/sdk/index.html >> http://developer.android.com/tools/sdk/ndk/index.html >> -Tomas >> >> On 08/01/2013 03:41 PM, Tobias Bley wrote: >>> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? >>> >>> Thanks! >>> Tobi >>> >>> >>> Am 31.07.2013 um 16:42 schrieb tomas.brandalik : >>> >>>> Hi Tobi, >>>> it works on linux only right now. >>>> Set properties for cross build and android sdk/ndk. >>>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >>>> Closed source parts web and font-t2k will be missing. >>>> >>>> -Tomas >>>> >>>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>>> Hi, >>>>> >>>>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>>>> >>>>> Best regards, >>>>> Tobi >>>>> From tobi at ultramixer.com Thu Aug 8 01:05:21 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Thu, 8 Aug 2013 10:05:21 +0200 Subject: current state of gradle script for Android? In-Reply-To: <52034FCB.1000207@oracle.com> References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> <51FA69F9.1040402@oracle.com> <52034FCB.1000207@oracle.com> Message-ID: <60C32EA4-DB90-46A9-9EF0-DBB8C793BF25@ultramixer.com> Hi Tomas, yes, I was able to build JavaFX for Android, but I would like to start JavaFX on Dalvik?You said its necessary to update the jfx78 backport to the latest openjfx code changes?? btw: I just saw your very interesting JavaOne track ;) Am 08.08.2013 um 09:59 schrieb tomas.brandalik : > Hi Tobi, > shouldn't be necessary to patch android.gradle file or set ANDROID_CROSS_TOOLS_VER anymore. The latest changes resolve path to a toolchain taking into account variants of NDK. Thank you for testing it. > > -Tomas > > On 08/01/2013 11:41 PM, Tobias Bley wrote: >> Thanks Tomas, >> >> after changing android.gradle script line "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.4.3?)? to "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could successfully build OpenJFX for Android von Mac OS X 10.9! >> >> So now I?m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in ?com.oracle.dalvik? package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? >> >> Best regards, >> Tobi >> >> >> Am 01.08.2013 um 16:00 schrieb tomas.brandalik : >> >>> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. >>> http://developer.android.com/sdk/index.html >>> http://developer.android.com/tools/sdk/ndk/index.html >>> -Tomas >>> >>> On 08/01/2013 03:41 PM, Tobias Bley wrote: >>>> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? >>>> >>>> Thanks! >>>> Tobi >>>> >>>> >>>> Am 31.07.2013 um 16:42 schrieb tomas.brandalik : >>>> >>>>> Hi Tobi, >>>>> it works on linux only right now. >>>>> Set properties for cross build and android sdk/ndk. >>>>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >>>>> Closed source parts web and font-t2k will be missing. >>>>> >>>>> -Tomas >>>>> >>>>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>>>> Hi, >>>>>> >>>>>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>>>>> >>>>>> Best regards, >>>>>> Tobi >>>>>> > From tom.schindl at bestsolution.at Thu Aug 8 01:22:35 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 08 Aug 2013 10:22:35 +0200 Subject: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase) In-Reply-To: References: Message-ID: <5203554B.60308@bestsolution.at> Hi Pedro, on CSS as a spec: You are right the spec does not only hold a language definition but also the definition of e.g. the box-model, ... who simply can not be applied to FX unless you completely revamp how it works on CSS: The grammer of the CSS-Language is at http://www.w3.org/TR/CSS2/grammar.html with a descrption at http://www.w3.org/TR/CSS2/syndata.html with updates in later specs and CSS can not only be applied to HTML-Doms but e.g. also to SVG where you have completely different attributes. See www.w3.org/TR/2011/REC-SVG11-20110816/styling.html how few properties SVG and HTML-CSS share! So to me it looks like the authors of SVG see CSS in the same way the JavaFX-Team does it as a styleing DSL leaving out things like the Box-Model, ... on SASS: I see no reason it can not be used. Like I said SASS is simply syntatic sugar above the CSS Language, but it does not really care about how the properties are named! I've attached you a sample of scss file derived from the projects website using JavaFX properties and to me the output looks correct, maybe there are advanced features I'm not aware of - I haven't used SASS at all on Compass: This one does not work with FX because it somehow deals with the properties on reusing CSS-HTML-Properties: I think the confusion would be getting worse if we'd start mixing HTML-CSS-Property names with -fx ones (which we need in any case) - even if we can get them 100% HTML-CSS compliant. I don't see me blindly copying a HTML-CSS which assumes the Box-Model, element-types who are not existing in FX at all Tom On 08.08.13 02:58, Pedro Duque Vieira wrote: > Go to the CSS W3C website and read the spec, you'll see that it's not > only a language. > > No SASS can't be used with JavaFX unless you make a SASS of your own > that works like the original but with JavaFX CSS files. > > Thanks, regards, > > On Thu, Aug 8, 2013 at 1:38 AM, Tom Schindl > wrote: > > SASS can be used as well in fx, it is simply a preprocessor, like > LESS, and for CSS the language and selectors there is a grammer! > > CSS is simply a DSL and its most important part are the selectors > and its cascading nature. > > Tom > > Von meinem iPhone gesendet > > Am 08.08.2013 um 02:11 schrieb Pedro Duque Vieira > >: > >> I might have jumped the gun when talking about LESS, I'm not >> actually familiar with it and thought it would be along the same >> lines like SASS. >> But still you can't use SASS or Compass with JavaFX CSS. >> >> Cheers, >> >> On Thu, Aug 8, 2013 at 1:05 AM, Pedro Duque Vieira >> > >> wrote: >> >> > So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. >> +1 to this idea (in a 3rd party lib). >> > The issue I see is that JavaFX CSS significantly differs from W3C CSS >> It surprises me that this issue comes up so rarely in >> JavaFX forums (almost never) - perhaps it is because >> JavaFX developers tend to be Java developers rather than >> designers. >> A related open jira request >> is http://javafx-jira.kenai.com/browse/RT-9272 "need to >> reconcile JavaFX CSS with W3C CSS3" 0 votes (no interest >> at all?). >> In terms of conversion of existing html css resources to >> javafx css, you may be interested in a Q&A with a >> developer who converted the Foundation look and feel to >> JavaFX (https://forums.oracle.com/thread/2490009) - from >> his point of view the conversion process was quite >> straight-forward - though perhaps that was partially luck >> of the draw. >> Below is a copy and paste from an earlier JavaFX forum >> post on this topic: >> You know, sometimes I find JavaFX's lack of certain css >> features refreshing. It is nice to have all, well, almost >> all, of the JavaFX CSS documented on one page. I think if >> you were to do the same thing for w3c css then it would >> end up with a much larger, more difficult to understand >> document and even what the contents of that document >> should be would probably be pretty controversial, in the >> same kind of way that the HTML5 specification ended up >> being. Microsoft contributed over 7000 tests to w3c just >> to cover only a subset of the css rules available in >> browsers today. The webkit project lists almost a thousand >> open CSS >> bugs: https://bugs.webkit.org/buglist.cgi?product=WebKit&component=CSS&resolution=---. >> So implementing even partial w3c CSS support is a complex >> project. >> When I first started using JavaFX CSS I found the >> differences to w3c CSS quite jarring, and it was hard to >> account for them. Now that I am used to JavaFX CSS, I >> don't have as much of an issue. The difference in names >> and semantics is going to be an impediment to designers >> working on JavaFX who are familar with w3c CSS - but the >> designers will quickly also discover that FXML is not HTML >> and Java is not JavaScript and JavaFX deployment is not >> HTML deployment. So, perhaps, in the larger picture, it is >> not as big a deal as it would seem. Still, one can't help >> think that any impediment to people easily picking up and >> adopting JavaFX is doing the technology a disservice. >> There are other advantages in having the JavaFX CSS in its >> own namespace to w3c css, in that it can evolve >> seperately, it is not expected to be exactly the same >> because it has a different name, it is not expected to >> fully implement w3c css as browsers do because it's >> clearly a different thing by name, etc. There is even >> precedent for it in the use by mozilla of moz- CSS >> prefixes and webkit css >> properties http://css-infos.net/properties/webkit - the >> web as not as standard as a lot of people propose. JavaFX >> CSS is backing a JavaFX rendering engine and not an HTML >> rendering engine. It is quite remarkable that Oracle was >> able to build and make available a CSS model for JavaFX >> that feels as familiar as it does to w3c css, as w3c css >> is targeted very strongly toward styling a completely >> different technology set (HTML markup and document object >> model). >> It would be useful to have a tool which translates w3c css >> to approximations of JavaFX css and vice versa, or the >> ability for JavaFX to have a mode (perhaps a boolean value >> when a stylesheet is loaded) to perform an automatic alias >> or mapping of w3c css to javafx (at least for the subset >> of w3c css which would make sense to automatically >> translate to JavaFX css). (David commented on this part >> previously - "Closing the gap between JavaFX CSS and W3C >> CSS will be an evolutionary process. It would be nice to >> use a standard's based stylesheet but there is not always >> a 1-1 mapping to JavaFX. But for those properties that can >> be mapped, it is something that should be supported. For >> example, we should be able to handle "font" or "-fx-font".") >> Comments above relate to the naming and semantic meanings >> of css tags, and not the syntax and parsing of css (as >> both w3c css and javaFX css seem to be equivalent in the >> later regard). >> The JavaFX css model is really powerful and I have found >> really useful some of the additions that it adds above the >> baseline 2.1 css that is found consistently in browsers. >> With the upcoming Java CSS object >> model http://javafx-jira.kenai.com/browse/RT-17293 "CSS >> Style Object Model in Java" 23 votes, you will also get >> better programmatic access from Java, which seems to be a >> highly requested feature. >> Regards, >> John >> >> >> Hi John, >> >> Thanks for your input. That's exactly my view on things. >> >> I'm also surprised so few people ever talk about this, not >> wanting to hurt anybody's feelings, I guess the vast majority >> probably don't do web development or are not really acquainted >> with CSS and its intricacies, but that's just a guess. >> >> Also one more advantage I see if JavaFX complies with w3c CSS >> (on the things that count) is that CSS is a continuously >> evolving technology with a lot of people already working on it >> and evolving it (for instance, the broken layout system is >> being rewritten with things like the box model), if JavaFX >> follows along it will benefit from that web of knowledge. >> >> @Tom Schindl: I'm not talking about only the "CSS language", >> there is no such thing (I guess its also a bit controversial >> to call "JavaFX CSS", "CSS" at all). W3C CSS is much more than >> a "language", what good would CSS be if you hand't got >> keywords, like "font", "color", "margin", etc. >> You also don't have to invent all the nodes "div", etc, to rip >> the benefits of having a more compliant W3C CSS. These can >> come later. >> >> One of the problems is that JavaFX adds a "-fx-" prefix to >> every keyword, the use of this prefix was meant to distinguish >> experimental browser new specific features during their >> testing, experimentation period. This was during an >> experimental phase, and was meant to be dropped as soon as all >> browser implementations of that new feature work the same. >> In JavaFX by contrast, this was added for the purposes of >> being able to write in the same stylesheet file both web w3c >> css and JavaFX css without the 2 clashing into each other. But >> I don't agree with this, and I think it's such a minor use >> case that the disadvantages clearly outweigh the advantages. >> For this use case why not have 2 separate stylesheets, what's >> the issue of separating things into 2 distinct files and also >> I think that it's much simpler to read and maintain 2 >> different stylesheets that cram everything into 1. >> But all this can be changed, we can have both -fx- prefixed >> properties and non -fx- prefixed properties and with this not >> breaking backwards compatibility. >> >> Thanks, regards, >> >> -- >> Pedro Duque Vieira >> >> >> >> >> -- >> Pedro Duque Vieira > > > > > -- > Pedro Duque Vieira -------------- next part -------------- .button { -fx-font: { family: serif; weight: bold; size: 1.2em; } } .error { -fx-border-width: 1px; -fx-border-color: #fdd; -fx-background-color: #fdd; } .error.intrusion { -fx-font-size: 1.3em; -fx-font-weight: bold; } .badError { @extend .error; -fx-border-width: 3px; } From hang.vo at oracle.com Thu Aug 8 02:32:51 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 09:32:51 +0000 Subject: hg: openjfx/8/graphics/rt: Android: Implement loadContent() on webview. Use default encoding set to null instead base64. Message-ID: <20130808093318.B3AF8486CC@hg.openjdk.java.net> Changeset: 158e4ee0658a Author: tb115823 Date: 2013-08-08 11:17 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/158e4ee0658a Android: Implement loadContent() on webview. Use default encoding set to null instead base64. ! modules/graphics/src/android/java/com/oracle/dalvik/InternalWebView.java ! modules/web/src/android/native/native_webview.c From hang.vo at oracle.com Thu Aug 8 03:17:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 10:17:49 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31966 Null-screen error on WebEngine.print() Message-ID: <20130808101824.E01FE486CE@hg.openjdk.java.net> Changeset: 1d7e167d5300 Author: peterz Date: 2013-08-08 14:15 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1d7e167d5300 RT-31966 Null-screen error on WebEngine.print() ! modules/web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java From tomas.brandalik at oracle.com Thu Aug 8 04:10:48 2013 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Thu, 08 Aug 2013 13:10:48 +0200 Subject: current state of gradle script for Android? In-Reply-To: <60C32EA4-DB90-46A9-9EF0-DBB8C793BF25@ultramixer.com> References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> <51FA69F9.1040402@oracle.com> <52034FCB.1000207@oracle.com> <60C32EA4-DB90-46A9-9EF0-DBB8C793BF25@ultramixer.com> Message-ID: <52037CB8.2020606@oracle.com> Hi, I have hardly any info about the project jfx78 backport and its status. I've just had a look at it and saw that last sync happened in beginning of July. It's good if somebody is willing to put his effort into that. In order to run on dalvik we need to compile jfx with jdk1.6 (I suppose 1.7 would do as well). Then there will be some packages missing for example java.beans or sun.misc but it could be fixed somehow. -Tomas On 08/08/2013 10:05 AM, Tobias Bley wrote: > Hi Tomas, > > yes, I was able to build JavaFX for Android, but I would like to start JavaFX on Dalvik?You said its necessary to update the jfx78 backport to the latest openjfx code changes?? > > btw: I just saw your very interesting JavaOne track ;) > > > Am 08.08.2013 um 09:59 schrieb tomas.brandalik : > >> Hi Tobi, >> shouldn't be necessary to patch android.gradle file or set ANDROID_CROSS_TOOLS_VER anymore. The latest changes resolve path to a toolchain taking into account variants of NDK. Thank you for testing it. >> >> -Tomas >> >> On 08/01/2013 11:41 PM, Tobias Bley wrote: >>> Thanks Tomas, >>> >>> after changing android.gradle script line "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.4.3?)? to "defineProperty("ANDROID_CROSS_TOOLS_VER", "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could successfully build OpenJFX for Android von Mac OS X 10.9! >>> >>> So now I?m trying to use Android Studio and the Emulator to start a JavaFX test application on Android. I tried to start my activity which extends from FXActivity class in ?com.oracle.dalvik? package. But how do I have to specify the JavaFX application class or main method? How do I have to bind the FXActivity with the JavaFX app (Stage / Application)? Is there any demo code available? >>> >>> Best regards, >>> Tobi >>> >>> >>> Am 01.08.2013 um 16:00 schrieb tomas.brandalik : >>> >>>> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 and ndk r7c and r8e. >>>> http://developer.android.com/sdk/index.html >>>> http://developer.android.com/tools/sdk/ndk/index.html >>>> -Tomas >>>> >>>> On 08/01/2013 03:41 PM, Tobias Bley wrote: >>>>> Which android SDK do I need? Could you please give me the URL to the correct android SDK and NDK? >>>>> >>>>> Thanks! >>>>> Tobi >>>>> >>>>> >>>>> Am 31.07.2013 um 16:42 schrieb tomas.brandalik : >>>>> >>>>>> Hi Tobi, >>>>>> it works on linux only right now. >>>>>> Set properties for cross build and android sdk/ndk. >>>>>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-sdk-linux -PANDROID_NDK=/opt/android-ndk-r7c -PCOMPILE_GSTREAMER=false -PSKIP_JAVADOC=true >>>>>> Closed source parts web and font-t2k will be missing. >>>>>> >>>>>> -Tomas >>>>>> >>>>>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>>>>> Hi, >>>>>>> >>>>>>> can anyone say something about the current state of the gradle android support? Is it possible to build OpenJFX for Android now via gradle? >>>>>>> >>>>>>> Best regards, >>>>>>> Tobi >>>>>>> From grazertwo at gmail.com Thu Aug 8 04:17:09 2013 From: grazertwo at gmail.com (=?ISO-8859-1?Q?Martin_Kl=E4hn?=) Date: Thu, 8 Aug 2013 13:17:09 +0200 Subject: Rowsorting of TableView with SortedList/FilteredList Message-ID: Hi guys, I'm working on a business application that makes use of TableView and I'm working with JDK 8 build b101. Displaying the data works like a charm. Row sorting for ordinary ObservableLists is fine too. Then I've set TableView.items to FilteredList and row sorting was disabled. replacing TableView.item with SortedList does not allow row sorting as well. Binding the comparator of SortedList to the TableView.comparator has no effect either. // row sorting possible //final TableView tableView = new TableView<>(FXCollections.observableArrayList(2, 1, 3)); // row sorting not possible (SortedList) // create a TableView with the sorted list set as the items it will show // bind the sortedList comparator to the TableView comparator //SortedList sortedList = new SortedList<>(FXCollections.observableArrayList(2, 1, 3)); //sortedList.comparatorProperty().bind(tableView.comparatorProperty()); //final TableView tableView = new TableView<>(sortedList); // row sorting not possible (FilteredList) //FilteredList filteredList = new FilteredList<>(FXCollections.observableArrayList(2, 1, 3), (e) -> true); //final TableView tableView = new TableView<>(filteredList ); // Don't forget to define columns! final TableColumn integerColumn = new TableColumn<>("Integer"); final TableColumn hexColumn = new TableColumn<>("Integer Hex"); integerColumn.setCellValueFactory(javaClass -> new SimpleLongProperty(javaClass.getValue())); hexColumn.setCellValueFactory(javaClass -> new SimpleStringProperty(Integer.toHexString(javaClass.getValue()))); tableView.getColumns().addAll(integerColumn, hexColumn); Any pointers on what I'm doing wrong or where I have to adapt my expectations. Is it correct that row sorting in a TableView is only possible for ordinary ObservableLists? With Regards Martin From hang.vo at oracle.com Thu Aug 8 04:47:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 11:47:53 +0000 Subject: hg: openjfx/8/graphics/rt: RT-21125 Mac: Native menus don't show the correct symbol for some Unicode chars. Message-ID: <20130808114843.78E57486D3@hg.openjdk.java.net> Changeset: 97a393b3f64d Author: Petr Pchelko Date: 2013-08-08 15:34 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/97a393b3f64d RT-21125 Mac: Native menus don't show the correct symbol for some Unicode chars. RT-21945 Mac: Menu accelerator badly rendered when using system menu bar Reviewed-by: anthony, art ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java ! modules/graphics/src/main/native-glass/mac/GlassKey.h ! modules/graphics/src/main/native-glass/mac/GlassKey.m ! modules/graphics/src/main/native-glass/mac/GlassMenu.m From artem.ananiev at oracle.com Thu Aug 8 04:50:10 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Thu, 08 Aug 2013 15:50:10 +0400 Subject: Swing and JavaFX thread merge In-Reply-To: References: <52021C0F.2090608@oracle.com> Message-ID: <520385F2.4050309@oracle.com> On 8/8/2013 1:45 AM, Jeff Martin wrote: > I thought I was getting this automatically - when I run on my > desktop, I can bring up a JOptionPane from a Swing thread and > JFXPanels (correctly) block. But when I run from Java Web Start, they > don't, and I end up with sporadic SwingUtilities.computeIntersection > NullPointerException. Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). > Is there a secret setting that has a different default with JAWS? NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? Thanks, Artem > jeff > > > On Aug 7, 2013, at 5:06 AM, Artem Ananiev wrote: > >> Hi, Pedro Duque Vieira, >> >> this is in progress. JDK part is tracked in 8015477: >> >> http://bugs.sun.com/view_bug.do?bug_id=8015477 >> >> JavaFX part is described in RT-30694: >> >> https://javafx-jira.kenai.com/browse/RT-30694 >> >> Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. >> >> Thanks, >> >> Artem >> >> On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: >>> Hi, >>> >>> Some time ago there was a patch submitted which for all purposes merged the >>> swing and javafx thread, making it easier for developers working on a >>> swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX >>> >>> Is this available now (I was under the impression it is)? How do I use it? >>> >>> Thanks in advance, >>> > From hang.vo at oracle.com Thu Aug 8 05:03:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 12:03:34 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31861: Examine commented-out thread checks in Glass Message-ID: <20130808120405.AB0C7486D4@hg.openjdk.java.net> Changeset: 1d86b2b314e3 Author: Petr Pchelko Date: 2013-08-08 15:52 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1d86b2b314e3 RT-31861: Examine commented-out thread checks in Glass Reviewed-by: anthony, art ! modules/graphics/src/main/java/com/sun/glass/ui/Application.java ! modules/graphics/src/main/java/com/sun/glass/ui/View.java ! modules/graphics/src/main/java/com/sun/glass/ui/Window.java From hang.vo at oracle.com Thu Aug 8 05:33:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 12:33:03 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30694: Add support for a single threaded mode for FX/AWT interop Message-ID: <20130808123348.76D1C486D8@hg.openjdk.java.net> Changeset: c122b03b13e5 Author: Petr Pchelko Date: 2013-08-08 16:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c122b03b13e5 RT-30694: Add support for a single threaded mode for FX/AWT interop Reviewed-by: anthony, art, ant, snorthov ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java ! modules/swing/src/main/java/javafx/embed/swing/JFXPanel.java ! modules/swing/src/main/java/javafx/embed/swing/SwingFXUtils.java From petr.pchelko at oracle.com Thu Aug 8 05:43:51 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 8 Aug 2013 16:43:51 +0400 Subject: Swing and JavaFX thread merge In-Reply-To: <520385F2.4050309@oracle.com> References: <52021C0F.2090608@oracle.com> <520385F2.4050309@oracle.com> Message-ID: <1989F36B-6475-4F64-A37A-7697D0E8D4A1@oracle.com> Hello. I've just pushed the fix to the repo, so it should be available in a couple of builds. However, it is an experimental feature, so we lack the documentation or examples on it. If you experience any issues with it - please contact me. > As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true) It's -Djavafx.embed.singleThread=true With best regards. Petr. On Aug 8, 2013, at 3:50 PM, Artem Ananiev wrote: > > On 8/8/2013 1:45 AM, Jeff Martin wrote: >> I thought I was getting this automatically - when I run on my >> desktop, I can bring up a JOptionPane from a Swing thread and >> JFXPanels (correctly) block. But when I run from Java Web Start, they >> don't, and I end up with sporadic SwingUtilities.computeIntersection >> NullPointerException. > > Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). > >> Is there a secret setting that has a different default with JAWS? > > NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? > > Thanks, > > Artem > >> jeff >> >> >> On Aug 7, 2013, at 5:06 AM, Artem Ananiev wrote: >> >>> Hi, Pedro Duque Vieira, >>> >>> this is in progress. JDK part is tracked in 8015477: >>> >>> http://bugs.sun.com/view_bug.do?bug_id=8015477 >>> >>> JavaFX part is described in RT-30694: >>> >>> https://javafx-jira.kenai.com/browse/RT-30694 >>> >>> Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. >>> >>> Thanks, >>> >>> Artem >>> >>> On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: >>>> Hi, >>>> >>>> Some time ago there was a patch submitted which for all purposes merged the >>>> swing and javafx thread, making it easier for developers working on a >>>> swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX >>>> >>>> Is this available now (I was under the impression it is)? How do I use it? >>>> >>>> Thanks in advance, >>>> >> From jeff at reportmill.com Thu Aug 8 06:17:16 2013 From: jeff at reportmill.com (Jeff Martin) Date: Thu, 8 Aug 2013 08:17:16 -0500 Subject: Swing and JavaFX thread merge In-Reply-To: <520385F2.4050309@oracle.com> References: <52021C0F.2090608@oracle.com> <520385F2.4050309@oracle.com> Message-ID: <4E90E3AA-7D35-4813-8E82-0B912699CB3D@reportmill.com> It looks like this is specific to MacOSX 7u25+, if you run Java Inventor from the JAWS link on MacOSX (I'm using JVM 1.7.0_25 or 40-ea): prompt> javaws http://reportmill.com/javi/javi1/JavaInventor1.jnlp Here are the steps: 1. Create New Project and Open 2. Click on large, animated "New Java Starter File" to bring up JOptionPane Then if you move the mouse around, you should see the other buttons on the screen still animate or illuminate in the FX thread. Whereas on 7u20 or Windows or non-JAWS launch, the JavaFX effects are not triggered while the modal panel is up. If you dismiss the option pane with the escape key and quickly re-click the New Starter File button repeatedly, eventually the SwingUtilities.computeIntersection NPE will manifest (sooner if you are doing a sales demo). Any thoughts on what would make the FX thread ignore the modal state in this configuration? jeff On Aug 8, 2013, at 6:50 AM, Artem Ananiev wrote: > > On 8/8/2013 1:45 AM, Jeff Martin wrote: >> I thought I was getting this automatically - when I run on my >> desktop, I can bring up a JOptionPane from a Swing thread and >> JFXPanels (correctly) block. But when I run from Java Web Start, they >> don't, and I end up with sporadic SwingUtilities.computeIntersection >> NullPointerException. > > Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). > >> Is there a secret setting that has a different default with JAWS? > > NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? > > Thanks, > > Artem > >> jeff >> >> >> On Aug 7, 2013, at 5:06 AM, Artem Ananiev wrote: >> >>> Hi, Pedro Duque Vieira, >>> >>> this is in progress. JDK part is tracked in 8015477: >>> >>> http://bugs.sun.com/view_bug.do?bug_id=8015477 >>> >>> JavaFX part is described in RT-30694: >>> >>> https://javafx-jira.kenai.com/browse/RT-30694 >>> >>> Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. >>> >>> Thanks, >>> >>> Artem >>> >>> On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: >>>> Hi, >>>> >>>> Some time ago there was a patch submitted which for all purposes merged the >>>> swing and javafx thread, making it easier for developers working on a >>>> swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX >>>> >>>> Is this available now (I was under the impression it is)? How do I use it? >>>> >>>> Thanks in advance, From petr.pchelko at oracle.com Thu Aug 8 06:33:51 2013 From: petr.pchelko at oracle.com (Petr Pchelko) Date: Thu, 8 Aug 2013 17:33:51 +0400 Subject: Glass thread checks In-Reply-To: <52039D9C.7080206@oracle.com> References: <52039D9C.7080206@oracle.com> Message-ID: <76992F1E-EF52-4E56-904D-83A1262BD7DC@oracle.com> Hello, OpenJFX Team. As you know, the previous attempt to switch on the thread checks have failed. The problems were fixed, so I'm going to enable them again tomorrow morning if nobody objects. With best regards. Petr. From pedro.duquevieira at gmail.com Thu Aug 8 06:35:14 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 8 Aug 2013 14:35:14 +0100 Subject: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase) Message-ID: Richard, John and Tom thanks for your input. > > Also one more advantage I see if JavaFX complies with w3c CSS (on the > > things that count) is that CSS is a continuously evolving technology > with a > > lot of people already working on it and evolving it (for instance, the > > broken layout system is being rewritten with things like the box model), > if > > JavaFX follows along it will benefit from that web of knowledge. > One misconception here is that there is any way for us to follow along for > free. There is not an existing CSS engine that we can reuse. They are all > heavily tied to their native C/C++ browser implementations and are all > based on DOM nodes, not scene graph nodes. When the W3C or WhatWG adds new > CSS capabilities, we don't get those for free, regardless of the syntax > that we were to use. That's not what I meant. What I meant is that you build on the existing knowledge surrounding a technology that is meant to define the appearance of applications. Of course, unfortunately you can not build on the implementation. As for following the standard, we do intend to do that (and always have), > at least insofar as it makes sense. But some things in Web CSS just don't > make sense in the FX scene graph (layout being an obvious example, but some > of the CSS selectors that allow you to insert dynamic nodes into the system > don't directly map unless we were to implement it via FXML instead of HTML). Yes I would discard layout and inserting dynamic nodes as well. I'm talking about what already exists in JavaFX CSS and that does not follow the CSS specification. For instance: margins, effects, the "-fx-" prefix everywhere, etc.. There are clearly some decisions being made that go against the spec and not because it would be hard or more work to follow the spec. With others I can agree that it can be difficult to follow. > @Tom Schindl: I'm not talking about only the "CSS language", there is no > > such thing > That is not correct. There is a CSS language (syntax) which is independent > of the various specific pseudo-classes or declarations supported by a > specific target (node type). You can find grammars on the internet. There is no CSS as language. You can talk about it, but CSS does not define only a language but also a bunch of properties: font, background and foreground colors, text properties, margins, etc, etc. Look at any CSS spec and you will find these. > One of the problems is that JavaFX adds a "-fx-" prefix to every keyword, > > the use of this prefix was meant to distinguish experimental browser new > > specific features during their testing, experimentation period. This was > > during an experimental phase, and was meant to be dropped as soon as all > > browser implementations of that new feature work the same. > As a practical matter, it is hard for the browsers to ever drop the > extension syntax, they just add in the new standard (dropping the existing > syntax breaks untold millions of websites).The same is true for FX, we > can't drop the -fx- prefix. And in fact we *added* the -fx- prefix at the > last minute before we shipped 2.0 (iirc). We didn't used to have the -fx- > prefix for everything. The problem was the the CSS standard was a moving > target, and we have to maintain compatibility, so we just put -fx- in front > of everything to make sure that we wouldn't be burned (as we already had > been once or twice) when the at-the-time unfinished CSS 3 backgrounds and > borders specification changed out from under us. That's not correct. Vendor prefixes are meant to be temporary as they fragment the web (each browser having there own prefix and implementation of a property), there have already been prefixes that were dropped. Taken from the W3C CSS specification 3 ( http://www.w3.org/TR/css3-syntax/#vendor-specific): "Although proprietary extensions should be avoided in general, there are situations (experiments, implementations of W3C drafts that have not yet reached Candidate Recommendation, intra-nets, debugging, etc.) where it is convenient to add some nonstandard, i.e., proprietary identifiers to a CSS style sheet. It is often hard to predict how long these proprietary extensions will be in use and hard to avoid that their names clash with new, standard properties or with other proprietary properties. Therefore the CSS Working Group proposes the following simple naming convention. A proprietary name should have a prefix consisting of..." In fact, the reason we put in -fx- was *exactly* to allow us to have > CSS-compliant non-fx- rules later on. Are you positively sure that your CSS implementation is compliant? I have serious doubts. > In JavaFX by contrast, this was added for the purposes of being able to > > write in the same stylesheet file both web w3c css and JavaFX css without > > the 2 clashing into each other. > That isn't really the reason why. It was so that we could be standards > compliant. We shipped before the CSS 3 spec was completed, so we needed to > use the vender extension prefix to make sure that we could later be spec > compliant (to the degree that makes sense). This was what I've been told more than once the reason was by Oracle staff. Again are you sure that this makes JavaFX CSS spec compliant? > But all this can be changed, we can have both -fx- prefixed properties > and > > non -fx- prefixed properties and with this not breaking backwards > > compatibility. > That's correct, and has always been the plan. But in practice (and as John > pointed out) this isn't really that big of a deal -- I'd rather have CSS > animations before we dealt with this, to be honest.-- I would be more interested in JavaFX CSS being W3C compliant than having CSS animations (you can already do those with java code), for the reasons I mentioned earlier. Thanks again, cheers, Pedro Duque Vieira From steve.x.northover at oracle.com Thu Aug 8 06:48:10 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 08 Aug 2013 09:48:10 -0400 Subject: Glass thread checks In-Reply-To: <76992F1E-EF52-4E56-904D-83A1262BD7DC@oracle.com> References: <52039D9C.7080206@oracle.com> <76992F1E-EF52-4E56-904D-83A1262BD7DC@oracle.com> Message-ID: <5203A19A.9070805@oracle.com> To give a little more context. JavaFX is apartment threaded with well documented rules for threaded. These rules were not enforced in code. Glass, the low level window component for FX is not enforcing apartment threading. Since Glass has no public API, the only way that an application can be affected is if it is coded such that it access Glass through FX from a non-UI thread. FX itself contained code some code that did this this code has been fixed. Thread checking is goodness and leads to consistent applications with repeatable behavior. Thread checking in Glass is a good first step forward in this area. Steve On 08/08/2013 9:33 AM, Petr Pchelko wrote: > Hello, OpenJFX Team. > > As you know, the previous attempt to switch on the thread checks have failed. > The problems were fixed, so I'm going to enable them again tomorrow morning if nobody objects. > > With best regards. Petr. From steve.x.northover at oracle.com Thu Aug 8 07:11:26 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 08 Aug 2013 10:11:26 -0400 Subject: Glass thread checks In-Reply-To: <5203A19A.9070805@oracle.com> References: <52039D9C.7080206@oracle.com> <76992F1E-EF52-4E56-904D-83A1262BD7DC@oracle.com> <5203A19A.9070805@oracle.com> Message-ID: <5203A70E.2080001@oracle.com> Heavens .. typos! To give a little more context. JavaFX is apartment threaded with well documented rules for threading. These rules were not enforced in code. Glass, the low level window component for FX is now enforcing apartment threading for this component. Since Glass has no public API, the only way that an application can be affected is if it is coded such that it accesses Glass through FX from a non-UI thread. FX itself contained code some code that did this this code has been fixed. Thread checking is goodness and leads to consistent applications with repeatable behavior. Thread checking in Glass is a good first step forward towards finding and addressing thread bugs. Steve On 08/08/2013 9:48 AM, steve.x.northover at oracle.com wrote: > To give a little more context. JavaFX is apartment threaded with well > documented rules for threaded. These rules were not enforced in > code. Glass, the low level window component for FX is not enforcing > apartment threading. Since Glass has no public API, the only way that > an application can be affected is if it is coded such that it access > Glass through FX from a non-UI thread. FX itself contained code some > code that did this this code has been fixed. > > Thread checking is goodness and leads to consistent applications with > repeatable behavior. Thread checking in Glass is a good first step > forward in this area. > > Steve > > On 08/08/2013 9:33 AM, Petr Pchelko wrote: >> Hello, OpenJFX Team. >> >> As you know, the previous attempt to switch on the thread checks have >> failed. >> The problems were fixed, so I'm going to enable them again tomorrow >> morning if nobody objects. >> >> With best regards. Petr. > From jeff at reportmill.com Thu Aug 8 07:56:30 2013 From: jeff at reportmill.com (Jeff Martin) Date: Thu, 8 Aug 2013 09:56:30 -0500 Subject: Swing and JavaFX thread merge In-Reply-To: <4E90E3AA-7D35-4813-8E82-0B912699CB3D@reportmill.com> References: <52021C0F.2090608@oracle.com> <520385F2.4050309@oracle.com> <4E90E3AA-7D35-4813-8E82-0B912699CB3D@reportmill.com> Message-ID: Addendum: it turns out that the JOptionPane is not blocking any of the UI (Swing included). So maybe this isn't strictly a JavaFX problem. jeff On Aug 8, 2013, at 8:17 AM, Jeff Martin wrote: > It looks like this is specific to MacOSX 7u25+, if you run Java Inventor from the JAWS link on MacOSX (I'm using JVM 1.7.0_25 or 40-ea): > > prompt> javaws http://reportmill.com/javi/javi1/JavaInventor1.jnlp > > Here are the steps: > > 1. Create New Project and Open > 2. Click on large, animated "New Java Starter File" to bring up JOptionPane > > Then if you move the mouse around, you should see the other buttons on the screen still animate or illuminate in the FX thread. Whereas on 7u20 or Windows or non-JAWS launch, the JavaFX effects are not triggered while the modal panel is up. If you dismiss the option pane with the escape key and quickly re-click the New Starter File button repeatedly, eventually the SwingUtilities.computeIntersection NPE will manifest (sooner if you are doing a sales demo). > > Any thoughts on what would make the FX thread ignore the modal state in this configuration? > > jeff > > > On Aug 8, 2013, at 6:50 AM, Artem Ananiev wrote: > >> >> On 8/8/2013 1:45 AM, Jeff Martin wrote: >>> I thought I was getting this automatically - when I run on my >>> desktop, I can bring up a JOptionPane from a Swing thread and >>> JFXPanels (correctly) block. But when I run from Java Web Start, they >>> don't, and I end up with sporadic SwingUtilities.computeIntersection >>> NullPointerException. >> >> Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). >> >>> Is there a secret setting that has a different default with JAWS? >> >> NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? >> >> Thanks, >> >> Artem >> >>> jeff >>> >>> >>> On Aug 7, 2013, at 5:06 AM, Artem Ananiev wrote: >>> >>>> Hi, Pedro Duque Vieira, >>>> >>>> this is in progress. JDK part is tracked in 8015477: >>>> >>>> http://bugs.sun.com/view_bug.do?bug_id=8015477 >>>> >>>> JavaFX part is described in RT-30694: >>>> >>>> https://javafx-jira.kenai.com/browse/RT-30694 >>>> >>>> Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. >>>> >>>> Thanks, >>>> >>>> Artem >>>> >>>> On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: >>>>> Hi, >>>>> >>>>> Some time ago there was a patch submitted which for all purposes merged the >>>>> swing and javafx thread, making it easier for developers working on a >>>>> swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX >>>>> >>>>> Is this available now (I was under the impression it is)? How do I use it? >>>>> >>>>> Thanks in advance, From danno.ferrin at shemnon.com Thu Aug 8 08:56:15 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Thu, 8 Aug 2013 09:56:15 -0600 Subject: current state of gradle script for Android? In-Reply-To: <52037CB8.2020606@oracle.com> References: <3E81E0CD-433A-48A7-A7FF-65EF60CAF7B9@ultramixer.com> <51F92255.5040904@oracle.com> <588620B7-D8A2-4D93-AD7B-17E27CC6E92E@ultramixer.com> <51FA69F9.1040402@oracle.com> <52034FCB.1000207@oracle.com> <60C32EA4-DB90-46A9-9EF0-DBB8C793BF25@ultramixer.com> <52037CB8.2020606@oracle.com> Message-ID: Summer vacation stuff with my family is sucking up all my free time. School starts in two weeks so I should be off the hook soon. On Aug 8, 2013 5:14 AM, "tomas.brandalik" wrote: > Hi, > I have hardly any info about the project jfx78 backport and its status. > I've just had a look at it and saw that last sync happened in beginning of > July. It's good if somebody is willing to put his effort into that. > In order to run on dalvik we need to compile jfx with jdk1.6 (I suppose > 1.7 would do as well). Then there will be some packages missing for example > java.beans or sun.misc but it could be fixed somehow. > > -Tomas > > On 08/08/2013 10:05 AM, Tobias Bley wrote: > >> Hi Tomas, >> >> yes, I was able to build JavaFX for Android, but I would like to start >> JavaFX on Dalvik?You said its necessary to update the jfx78 backport to the >> latest openjfx code changes?? >> >> btw: I just saw your very interesting JavaOne track ;) >> >> Am 08.08.2013 um 09:59 schrieb tomas.brandalik < >> tomas.brandalik at oracle.com>: >> >> Hi Tobi, >>> shouldn't be necessary to patch android.gradle file or set >>> ANDROID_CROSS_TOOLS_VER anymore. The latest changes resolve path to a >>> toolchain taking into account variants of NDK. Thank you for testing it. >>> >>> -Tomas >>> >>> On 08/01/2013 11:41 PM, Tobias Bley wrote: >>> >>>> Thanks Tomas, >>>> >>>> after changing android.gradle script line "defineProperty("ANDROID_**CROSS_TOOLS_VER", >>>> "arm-linux-androideabi-4.4.3?)**? to "defineProperty("ANDROID_**CROSS_TOOLS_VER", >>>> "arm-linux-androideabi-4.6?)? and "def toolsPlatform = IS_WINDOWS ? >>>> "windows" : IS_MAC ? "macosx" : "linux-x86?? to ?def toolsPlatform = >>>> IS_WINDOWS ? "windows" : IS_MAC ? "darwin-x86_64" : "linux-x86?? I could >>>> successfully build OpenJFX for Android von Mac OS X 10.9! >>>> >>>> So now I?m trying to use Android Studio and the Emulator to start a >>>> JavaFX test application on Android. I tried to start my activity which >>>> extends from FXActivity class in ?com.oracle.dalvik? package. But how do I >>>> have to specify the JavaFX application class or main method? How do I have >>>> to bind the FXActivity with the JavaFX app (Stage / Application)? Is there >>>> any demo code available? >>>> >>>> Best regards, >>>> Tobi >>>> >>>> >>>> Am 01.08.2013 um 16:00 schrieb tomas.brandalik < >>>> tomas.brandalik at oracle.com>: >>>> >>>> The latest tools should be ok sdk ver. 22 and ndk r9. I have sdk 21.1 >>>>> and ndk r7c and r8e. >>>>> http://developer.android.com/**sdk/index.html >>>>> http://developer.android.com/**tools/sdk/ndk/index.html >>>>> -Tomas >>>>> >>>>> On 08/01/2013 03:41 PM, Tobias Bley wrote: >>>>> >>>>>> Which android SDK do I need? Could you please give me the URL to the >>>>>> correct android SDK and NDK? >>>>>> >>>>>> Thanks! >>>>>> Tobi >>>>>> >>>>>> >>>>>> Am 31.07.2013 um 16:42 schrieb tomas.brandalik < >>>>>> tomas.brandalik at oracle.com>: >>>>>> >>>>>> Hi Tobi, >>>>>>> it works on linux only right now. >>>>>>> Set properties for cross build and android sdk/ndk. >>>>>>> -PCOMPILE_TARGETS=android -PANDROID_SDK=/opt/android-**sdk-linux >>>>>>> -PANDROID_NDK=/opt/android-**ndk-r7c -PCOMPILE_GSTREAMER=false >>>>>>> -PSKIP_JAVADOC=true >>>>>>> Closed source parts web and font-t2k will be missing. >>>>>>> >>>>>>> -Tomas >>>>>>> >>>>>>> On 07/29/2013 11:22 PM, Tobias Bley wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> can anyone say something about the current state of the gradle >>>>>>>> android support? Is it possible to build OpenJFX for Android now via gradle? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Tobi >>>>>>>> >>>>>>>> > From hang.vo at oracle.com Thu Aug 8 10:32:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 17:32:49 +0000 Subject: hg: openjfx/8/graphics/rt: Adding vi .swp files to .hgignore Message-ID: <20130808173408.090B1486F2@hg.openjdk.java.net> Changeset: d045f3d461de Author: ddhill Date: 2013-08-08 13:23 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d045f3d461de Adding vi .swp files to .hgignore ! .hgignore From hang.vo at oracle.com Thu Aug 8 10:47:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 17:47:52 +0000 Subject: hg: openjfx/8/graphics/rt: RT-31962: Window Display all black and can't restore Message-ID: <20130808174838.A16D0486F3@hg.openjdk.java.net> Changeset: c3890f1ae2a1 Author: kcr Date: 2013-08-08 10:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c3890f1ae2a1 RT-31962: Window Display all black and can't restore ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PresentingPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java From hang.vo at oracle.com Thu Aug 8 11:03:19 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 18:03:19 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30449 FX 8 3D: Need to handle mirror transformation (flip culling) Message-ID: <20130808180410.783EF486F8@hg.openjdk.java.net> Changeset: ae7b09388ec2 Author: Yao Wang Date: 2013-08-08 11:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ae7b09388ec2 RT-30449 FX 8 3D: Need to handle mirror transformation (flip culling) ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/prism/es2/ES2Context.java From hang.vo at oracle.com Thu Aug 8 11:48:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 18:48:16 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30204 ES2RTT Viewport fix Message-ID: <20130808184907.D5C0748705@hg.openjdk.java.net> Changeset: 1222358a4d4d Author: "Joseph Andresen" Date: 2013-08-08 11:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1222358a4d4d RT-30204 ES2RTT Viewport fix ! modules/graphics/src/main/java/com/sun/prism/MultiTexture.java ! modules/graphics/src/main/java/com/sun/prism/Texture.java ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DRTTexture.java ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DTexture.java ! modules/graphics/src/main/java/com/sun/prism/es2/ES2RTTexture.java ! modules/graphics/src/main/java/com/sun/prism/es2/ES2Texture.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseTexture.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWArgbPreTexture.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWMaskTexture.java ! modules/graphics/src/main/java/com/sun/scenario/effect/Filterable.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/ImagePool.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/PrDrawable.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/PrImage.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSDrawable.java ! modules/graphics/src/main/java/com/sun/scenario/effect/impl/prism/sw/PSWDrawable.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubFilterable.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/TestGraphics.java From jeff at reportmill.com Thu Aug 8 12:19:04 2013 From: jeff at reportmill.com (Jeff Martin) Date: Thu, 8 Aug 2013 14:19:04 -0500 Subject: Swing and JavaFX thread merge In-Reply-To: References: <52021C0F.2090608@oracle.com> <520385F2.4050309@oracle.com> <4E90E3AA-7D35-4813-8E82-0B912699CB3D@reportmill.com> Message-ID: <9D916A5F-0011-4BB2-807F-2FA86E74BD55@reportmill.com> So I found a workaround, though I don't understand the why of the problem or workaround. What I found was that on MacOSX 7u25+, my app mainSwing() (executed via invokeLater() from main()) was being called on AWT-EventQueue-2 from the JAWS startup thread (javawsApplicationMain) instead of AWT-EventQueue-0. So I added code to force JavaFX init, switch over to the FX thread, and switch back to Swing, which is then AWT-EventQueue-0: if(Thread.currentThread().getName().equals("AWT-EventQueue-2")) { new JFXPanel(); Platform.runLater(new Runnable() { public void run() { SwingUtilities.invokeLater(new Runnable() { public void run() { mainSwing(args); }}); }}); return; } And now my JOptionPane correctly blocks events outside of the dialog! jeff On Aug 8, 2013, at 9:56 AM, Jeff Martin wrote: > Addendum: it turns out that the JOptionPane is not blocking any of the UI (Swing included). So maybe this isn't strictly a JavaFX problem. > > jeff > > > On Aug 8, 2013, at 8:17 AM, Jeff Martin wrote: > >> It looks like this is specific to MacOSX 7u25+, if you run Java Inventor from the JAWS link on MacOSX (I'm using JVM 1.7.0_25 or 40-ea): >> >> prompt> javaws http://reportmill.com/javi/javi1/JavaInventor1.jnlp >> >> Here are the steps: >> >> 1. Create New Project and Open >> 2. Click on large, animated "New Java Starter File" to bring up JOptionPane >> >> Then if you move the mouse around, you should see the other buttons on the screen still animate or illuminate in the FX thread. Whereas on 7u20 or Windows or non-JAWS launch, the JavaFX effects are not triggered while the modal panel is up. If you dismiss the option pane with the escape key and quickly re-click the New Starter File button repeatedly, eventually the SwingUtilities.computeIntersection NPE will manifest (sooner if you are doing a sales demo). >> >> Any thoughts on what would make the FX thread ignore the modal state in this configuration? >> >> jeff >> >> >> On Aug 8, 2013, at 6:50 AM, Artem Ananiev wrote: >> >>> >>> On 8/8/2013 1:45 AM, Jeff Martin wrote: >>>> I thought I was getting this automatically - when I run on my >>>> desktop, I can bring up a JOptionPane from a Swing thread and >>>> JFXPanels (correctly) block. But when I run from Java Web Start, they >>>> don't, and I end up with sporadic SwingUtilities.computeIntersection >>>> NullPointerException. >>> >>> Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). >>> >>>> Is there a secret setting that has a different default with JAWS? >>> >>> NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? >>> >>> Thanks, >>> >>> Artem >>> >>>> jeff >>>> >>>> >>>> On Aug 7, 2013, at 5:06 AM, Artem Ananiev wrote: >>>> >>>>> Hi, Pedro Duque Vieira, >>>>> >>>>> this is in progress. JDK part is tracked in 8015477: >>>>> >>>>> http://bugs.sun.com/view_bug.do?bug_id=8015477 >>>>> >>>>> JavaFX part is described in RT-30694: >>>>> >>>>> https://javafx-jira.kenai.com/browse/RT-30694 >>>>> >>>>> Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. >>>>> >>>>> Thanks, >>>>> >>>>> Artem >>>>> >>>>> On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: >>>>>> Hi, >>>>>> >>>>>> Some time ago there was a patch submitted which for all purposes merged the >>>>>> swing and javafx thread, making it easier for developers working on a >>>>>> swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX >>>>>> >>>>>> Is this available now (I was under the impression it is)? How do I use it? >>>>>> >>>>>> Thanks in advance, > From hang.vo at oracle.com Thu Aug 8 12:48:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 19:48:01 +0000 Subject: hg: openjfx/8/graphics/rt: RT-32224: restore Window.add/remove methods needed by Lens native Message-ID: <20130808194909.4DC2848714@hg.openjdk.java.net> Changeset: e916bc90eb67 Author: ddhill Date: 2013-08-08 15:32 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e916bc90eb67 RT-32224: restore Window.add/remove methods needed by Lens native ! modules/graphics/src/main/java/com/sun/glass/ui/Window.java From hang.vo at oracle.com Thu Aug 8 12:04:48 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 19:04:48 +0000 Subject: hg: openjfx/8/master/rt: 97 new changesets Message-ID: <20130808195742.B51C848717@hg.openjdk.java.net> Changeset: 1881571d12e6 Author: mv157916 Date: 2013-08-02 00:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1881571d12e6 RT-32076: Update the JDK build number to b101 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 02439ac5011b Author: jgiles Date: 2013-07-30 12:32 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/02439ac5011b RT-31577: Clearing the selection in TableView doesn't call ChangeListener on SelectionModel selectedItemProperty ! 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/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: 908485f56f7f Author: jgiles Date: 2013-07-30 15:22 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/908485f56f7f RT-30253: [TreeView] graphics is not rendered immediately when prebuilt cell factory is used. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: be80dfafbd68 Author: jgiles Date: 2013-07-30 15:38 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/be80dfafbd68 RT-30754: ComboBox doesn't align properly with baseline ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java Changeset: f0fb93f22f9b Author: jgiles Date: 2013-07-31 09:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f0fb93f22f9b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 60e14d6f298e Author: jgiles Date: 2013-07-31 10:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/60e14d6f298e RT-31570: Make some VirtualFlow method protected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 0b89acf5c119 Author: jgiles Date: 2013-07-31 11:26 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0b89acf5c119 RT-31901: Regression: scrollbar issue with TitledPane ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 32a15e40d649 Author: jgiles Date: 2013-07-31 12:23 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/32a15e40d649 RT-31997: ChoiceBox and ComboBox popup menu appear shifted vertically (by ~5px) ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! modules/graphics/src/main/java/com/sun/javafx/Utils.java Changeset: 4f3014d423e9 Author: jgiles Date: 2013-07-31 14:10 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4f3014d423e9 Partial fix for RT-31918: ComboBox doesn't render scroll bars The exception listed in the jira issue no longer occurs. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 6ac8a1f0708d Author: jgiles Date: 2013-07-31 14:36 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6ac8a1f0708d RT-30400: ProgressBar cell factory renders progress bars in empty cells ! modules/controls/src/main/java/javafx/scene/control/cell/ProgressBarTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ProgressBarTreeTableCell.java ! modules/controls/src/test/java/javafx/scene/control/cell/ProgressBarTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ProgressBarTreeTableCellTest.java Changeset: 1468c900ae93 Author: jgiles Date: 2013-07-31 14:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1468c900ae93 RT-30394: TreeTableView focus model returns wrong focused index ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.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/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java Changeset: 30bec5fde344 Author: jgiles Date: 2013-07-31 15:17 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/30bec5fde344 RT-25975: [DOC] : Class SkinBase needs to be documented ! modules/controls/src/main/java/javafx/scene/control/SkinBase.java Changeset: a8987ec491ac Author: jgiles Date: 2013-08-01 10:02 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a8987ec491ac RT-30156: Sorting a table column leaves the selection model inconsistent with the display in the UI ! modules/controls/src/main/java/javafx/scene/control/ListView.java ! 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/TreeItem.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java Changeset: 4d59d24f0d8b Author: mickf Date: 2013-08-01 14:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4d59d24f0d8b RT-30871 : indeterminate progress bar causes memory leak ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 3aadad7d5904 Author: mickf Date: 2013-08-01 14:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3aadad7d5904 RT-27791 :ProgressBar keeps animating when in ScrollPane and scrolled out of view ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 42157cdefd1a Author: mickf Date: 2013-08-01 16:35 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/42157cdefd1a RT-31661 : Docs : Missing description in ScrollBar API - in constructor ! modules/controls/src/main/java/javafx/scene/control/ScrollBar.java Changeset: d9f804166732 Author: mickf Date: 2013-08-01 17:16 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d9f804166732 Revert DefaultTreeCell name change to enable building ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: d4657711e052 Author: jgiles Date: 2013-08-02 08:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d4657711e052 Backed out changeset: d9f804166732 ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: 970027341fc2 Author: jgiles Date: 2013-08-02 08:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/970027341fc2 Adding in missing DefaultTreeCell impl + modules/controls/src/main/java/javafx/scene/control/cell/DefaultTreeCell.java Changeset: 72059831a447 Author: rbair Date: 2013-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/72059831a447 Minor Intellij project update ! .idea/vcs.xml Changeset: 7b779c15ce73 Author: rbair Date: 2013-08-01 18:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7b779c15ce73 RT-24400: Incorrect work ctrl+backspace and ctrl+delete in TextArea. Summary: The problem is that the nextWord / previousWord methods on TextInputControl did not correctly handle cases where numbers are in the stream of characters. There may be additional issues related to symbols and how breaking should occur. Also some of this might be OS specific (on Mac it breaks in some places, on Windows someplace else). However this should fix the SQE tests. ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/test/java/javafx/scene/control/TextInputControlTest.java Changeset: a4d7b7b2daa2 Author: rbair Date: 2013-08-02 09:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a4d7b7b2daa2 Made some fields final, fixed a javadoc issue. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: 97ff822bb664 Author: rbair Date: 2013-08-02 09:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/97ff822bb664 Removed EMPTY_BINDINGS and use instead Collections.emptyList(). One less field, but more important, the EMPTY_BINDINGS wasn't immutable so there was a possibility of a bug there, whereas now there is not. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: a01a090e0477 Author: rbair Date: 2013-08-02 11:32 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a01a090e0477 RT-32102: TreeView on Mac does not use cmd+ctrl+space for toggling selection ! 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: 226250c9e7f9 Author: rbair Date: 2013-08-02 11:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/226250c9e7f9 Minor fixes to BehaviorBase. Made convenience traverse methods final, all pointing to the single non-final method that does all the work. Made sure the keyBindings field is unmodifiable. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: 44af70149f3b Author: rbair Date: 2013-08-02 14:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/44af70149f3b RT-32103: Behaviors should remove listeners when Skin is disposed. I believe this is mostly complete other than for TableViewBehavior and TreeTableViewBehavior. Tests forthcoming. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboBehavior.java - modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusListBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusPopupBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java + modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/AccordionBehaviorTest.java + modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java Changeset: e8ccb3fa27cc Author: rbair Date: 2013-08-02 20:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e8ccb3fa27cc RT-32110: Cleanup BehaviorBase by passing key bindings in the constructor ! apps/experiments/ConferenceScheduleApp/src/main/java/com/javafx/experiments/scheduleapp/control/VirtualKeyboardSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/CellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ColorPickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ComboBoxListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DatePickerBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/MenuButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/MenuButtonBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ProgressBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ProgressIndicatorBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/SplitMenuButtonBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableRowBehavior.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/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TitledPaneBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ToolBarBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/LabelSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SeparatorSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/BehaviorSkinBaseTest.java ! modules/web/src/main/java/com/sun/javafx/scene/web/behavior/HTMLEditorBehavior.java ! modules/web/src/main/java/com/sun/javafx/webkit/theme/RenderThemeImpl.java Changeset: 5c98da320f07 Author: rbair Date: 2013-08-02 21:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5c98da320f07 Remove unused method from BehaviorBase ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java Changeset: 2f80082e42ef Author: rbair Date: 2013-08-05 13:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2f80082e42ef Added some more tests for BehaviorBase, added comments to BehaviorBase. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/DateCellBehavior.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java Changeset: 0dc911479304 Author: rbair Date: 2013-08-05 13:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0dc911479304 Reduced redundant method invocations in TabPaneBehavior. ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! modules/graphics/src/main/java/com/sun/javafx/scene/traversal/TraversalEngine.java Changeset: b939cc31d31c Author: rbair Date: 2013-08-05 14:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b939cc31d31c Added tests to test BehaviorBase focus / mouse events are handled correctly ! modules/controls/src/test/java/com/sun/javafx/scene/control/behavior/BehaviorBaseTest.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/MouseEventFirer.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java ! modules/controls/src/test/java/javafx/scene/control/ButtonTest.java ! modules/controls/src/test/java/javafx/scene/control/ColorPickerTest.java Changeset: 5752e8bc7cb7 Author: jgiles Date: 2013-08-05 15:33 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5752e8bc7cb7 RT-19487: TableView: Support returning to unsorted state. For more information, I blogged about this feature here: http://fxexperience.com/2013/08/returning-a-tableview-back-to-an-unsorted-state-in-javafx-8-0/ ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java Changeset: 83a5c0ffd155 Author: jgiles Date: 2013-08-06 10:25 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/83a5c0ffd155 RT-30484: updateItem is not called at startup on virtualised controls, leading to invalid graphical states. ! 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/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.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: 905b63f0c057 Author: jgiles Date: 2013-08-06 10:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/905b63f0c057 RT-31907: Cleanup control code (part seven: generics cleanup for TableView / TreeTableView skin code) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableViewSkin.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/TreeTableViewSkin.java Changeset: 2a33523022aa Author: jgiles Date: 2013-08-06 11:30 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2a33523022aa RT-31907: Cleanup control code (part eight: Small TreeTableRow cleanup) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TreeTableRow.java Changeset: cecdbd12e168 Author: jgiles Date: 2013-08-06 11:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cecdbd12e168 RT-31907: Cleanup control code (part nine: Clean up generic warnings in TableRow) Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TableRow.java Changeset: 3268003fe9c0 Author: jgiles Date: 2013-08-06 13:11 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3268003fe9c0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! modules/controls/src/test/java/com/sun/javafx/scene/control/infrastructure/VirtualFlowTestUtils.java Changeset: d0ecfb9f77d6 Author: David Grieve Date: 2013-08-06 08:57 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d0ecfb9f77d6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java Changeset: d8637798fb3e Author: dmasada Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d8637798fb3e RT-31630 Ensemble8 CurveFittedAreaChart and some others get NPE in NGRegion ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/charts/area/curvefitted/CurveFittedAreaChart.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/searchbox/SearchBox.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/alphamediaplayer/AlphaMediaPlayer.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/overlaymediaplayer/OverlayMediaPlayer.css ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/media/streamingmediaplayer/StreamingMediaPlayer.css Changeset: 430db69d45c7 Author: Chien Yang Date: 2013-07-30 14:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/430db69d45c7 Fix to RT-31914: occlusion culling fails to work correctly on pure 2d shapes scene with 3d transform Reviewed by Kevin and Martin ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: 673aece90319 Author: Chien Yang Date: 2013-07-30 14:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/673aece90319 Fix to RT-30829: DepthTest flag on Graphics is set by Node but never cleared, misbehaving with multiple dirty regions Reviewed by Kevin ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java Changeset: a9eb573ffc6e Author: tb115823 Date: 2013-07-31 09:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a9eb573ffc6e Android: Add vmlauncher netbeans project. + netbeans/android/vmlauncher/Android.mk + netbeans/android/vmlauncher/nbproject/configurations.xml + netbeans/android/vmlauncher/nbproject/project.xml Changeset: 4f9d8e9fb4aa Author: tb115823 Date: 2013-07-31 09:25 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4f9d8e9fb4aa Android: Rename netbeans projects. - netbeans/android/glass-lib-lens/Android.mk - netbeans/android/glass-lib-lens/nbproject/configurations.xml - netbeans/android/glass-lib-lens/nbproject/project.xml + netbeans/android/native-glass/Android.mk + netbeans/android/native-glass/nbproject/configurations.xml + netbeans/android/native-glass/nbproject/project.xml = netbeans/android/native-vmlauncher/Android.mk < netbeans/android/vmlauncher/Android.mk = netbeans/android/native-vmlauncher/nbproject/configurations.xml < netbeans/android/vmlauncher/nbproject/configurations.xml ! netbeans/android/native-vmlauncher/nbproject/project.xml < netbeans/android/vmlauncher/nbproject/project.xml Changeset: fbd46f5535b5 Author: tb115823 Date: 2013-07-31 09:59 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fbd46f5535b5 Android: Add netbeans project native-prism-es2. + netbeans/android/native-prism-es2/Android.mk + netbeans/android/native-prism-es2/nbproject/configurations.xml + netbeans/android/native-prism-es2/nbproject/project.xml Changeset: 74cc6f8d1fc9 Author: Artem Ananiev Date: 2013-07-31 14:03 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/74cc6f8d1fc9 RT-31964: Quantum cleanup: don't force headless AWT on Mac Reviewed-by: Kevin Rushforth ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java Changeset: 61bcda9f2a59 Author: tb115823 Date: 2013-07-31 13:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/61bcda9f2a59 Android: Fix hyphens in native libraries names. Remove absolete NativeActivity class. ! buildSrc/android.gradle - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java Changeset: fda3c077e769 Author: tb115823 Date: 2013-07-31 13:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fda3c077e769 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java Changeset: 4d6d71a5fdb5 Author: David Pulkrabek Date: 2013-07-31 13:28 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4d6d71a5fdb5 iOS build: introduced a new property for closed build ! buildSrc/ios.gradle Changeset: dd02ad45b83c Author: flar Date: 2013-07-31 06:49 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dd02ad45b83c Fix RT-30223, RT-30826, RT-31044 - Canvas clears clip on Windows/D3D ! modules/graphics/src/main/java/com/sun/prism/d3d/D3DContext.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderContext.java Changeset: 0bd782657481 Author: snorthov Date: 2013-07-31 13:39 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0bd782657481 ECLIPSE ONLY: work around strange crash in webnode (html editor) that occurs when deploy.jar is before web on the class path. This began happening when I upgraded to b100. Did not investigate further to see whether it is an Eclipse issue or a JDK one. ! .classpath ! modules/web/.classpath Changeset: f7baf984824c Author: kcr Date: 2013-07-31 11:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f7baf984824c RT-32017: Gradle: closed build should fail if jfxrt.jar is present in the JDK ! build.gradle Changeset: 2ad0bb31c1bc Author: peterz Date: 2013-08-01 12:17 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2ad0bb31c1bc RT-32010 Gradle build fails with BINARY_STUB ! build.gradle ! buildSrc/linux.gradle Changeset: 49a2c50e80dc Author: Martin Sladecek Date: 2013-08-01 10:54 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/49a2c50e80dc RT-32001 SubScene is broken in recent code merge for 8.0-b99 ! 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/SubScene.java ! modules/graphics/src/stub/java/javafx/scene/SubSceneTest.java Changeset: 18ba5b7ba24c Author: snorthov Date: 2013-08-01 07:09 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/18ba5b7ba24c RT-31920: Allow Application name to be set and queried and implement app data directory ! modules/graphics/src/main/java/com/sun/glass/ui/Application.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/native-glass/mac/GlassApplication.m Changeset: c8b408109a3a Author: tb115823 Date: 2013-08-01 13:18 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c8b408109a3a Android: webnode moved to opensource. Updated java and native projects. ! buildSrc/android.gradle + modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java.jfx78 + modules/web/src/android/java/com/sun/javafx/scene/web/Debugger.java + modules/web/src/android/java/com/sun/javafx/scene/web/skin/HTMLEditorSkin.java + modules/web/src/android/java/com/sun/javafx/sg/prism/NGWebView.java + modules/web/src/android/java/com/sun/javafx/webkit/Accessor.java + modules/web/src/android/java/com/sun/javafx/webkit/prism/PrismInvoker.java + modules/web/src/android/java/com/sun/webkit/BackForwardList.java + modules/web/src/android/java/com/sun/webkit/Disposer.java + modules/web/src/android/java/com/sun/webkit/DisposerRecord.java + modules/web/src/android/java/com/sun/webkit/InspectorClient.java + modules/web/src/android/java/com/sun/webkit/Invoker.java + modules/web/src/android/java/com/sun/webkit/LoadListenerClient.java + modules/web/src/android/java/com/sun/webkit/NativeWebView.java + modules/web/src/android/java/com/sun/webkit/Timer.java + modules/web/src/android/java/com/sun/webkit/WebPage.java + modules/web/src/android/java/com/sun/webkit/event/WCChangeEvent.java + modules/web/src/android/java/com/sun/webkit/event/WCChangeListener.java + modules/web/src/android/java/com/sun/webkit/graphics/WCImage.java + modules/web/src/android/java/com/sun/webkit/network/URLs.java + modules/web/src/android/java/com/sun/webkit/network/Util.java + modules/web/src/android/java/javafx/scene/web/HTMLEditor.java + modules/web/src/android/java/javafx/scene/web/PopupFeatures.java + modules/web/src/android/java/javafx/scene/web/PromptData.java + modules/web/src/android/java/javafx/scene/web/WebEngine.java + modules/web/src/android/java/javafx/scene/web/WebEvent.java + modules/web/src/android/java/javafx/scene/web/WebHistory.java + modules/web/src/android/java/javafx/scene/web/WebView.java + modules/web/src/android/java/netscape/javascript/JSException.java + modules/web/src/android/java/netscape/javascript/JSObject.java + modules/web/src/android/native/android_log.h + modules/web/src/android/native/android_webview.c + modules/web/src/android/native/android_webview.h + modules/web/src/android/native/native_webview.c + modules/web/src/android/native/symbol.h + netbeans/android/native-webnode/Android.mk + netbeans/android/native-webnode/nbproject/configurations.xml + netbeans/android/native-webnode/nbproject/project.xml + netbeans/android/webnode/build.xml + netbeans/android/webnode/local.properties + netbeans/android/webnode/nbproject/project.xml Changeset: 675b95a2ac37 Author: tb115823 Date: 2013-08-01 13:23 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/675b95a2ac37 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: 812ccc5dcaf0 Author: snorthov Date: 2013-08-01 07:26 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/812ccc5dcaf0 ECLIPSE ONLY: fix .classpath compile error ! .classpath ! modules/web/.classpath Changeset: 44f6ba54dcde Author: snorthov Date: 2013-08-01 08:11 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/44f6ba54dcde RT-31249: Mechanism to identify application [udpate SWT] ! modules/swt/src/main/java/javafx/embed/swt/FXCanvas.java Changeset: 7b0d4ac76c35 Author: Artem Ananiev Date: 2013-08-01 16:22 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7b0d4ac76c35 RT-32012: Quantum cleanup: remove PopupScene and PopupStage Reviewed-by: Kevin Rushforth, Steve Northover ! modules/graphics/src/main/java/com/sun/javafx/tk/DummyToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupScene.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupStage.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java ! modules/graphics/src/main/java/javafx/stage/PopupWindow.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubToolkit.java Changeset: b4a3b80a0783 Author: Martin Sladecek Date: 2013-08-01 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b4a3b80a0783 RT-31464 Custom node sample in Ensemble8 is broken ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/node/customnode/MyNode.java Changeset: fbaef718694c Author: Martin Sladecek Date: 2013-08-01 16:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fbaef718694c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx/rt Changeset: c14cc7cd7d5c Author: peterz Date: 2013-08-01 18:44 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c14cc7cd7d5c Restored accidental change made in changeset #4514 ! buildSrc/linux.gradle Changeset: dff7ba8f08ec Author: Yao Wang Date: 2013-08-01 10:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dff7ba8f08ec RT-26111 Use glyph bounding boxes to get visual bounds ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java ! modules/graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java ! modules/graphics/src/main/java/javafx/scene/text/Text.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubTextLayout.java Changeset: 350038269859 Author: Felipe Heidrich Date: 2013-08-01 11:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/350038269859 minor fix for StubTextLayout caused by RT-26111 ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubTextLayout.java Changeset: 6279340ebb9d Author: Felipe Heidrich Date: 2013-08-01 14:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6279340ebb9d [eclipse only] Adding RegionTests to the classpath ! .classpath Changeset: 9c612891d297 Author: flar Date: 2013-08-01 14:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9c612891d297 Fix RT-31998, forward port of RT-31701: HiDPI: Effects position are wrong ! modules/graphics/src/main/jsl-decora/InvertMask.jsl Changeset: 469677a7c799 Author: flar Date: 2013-08-01 16:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/469677a7c799 Fix RT-24343: missing doc comments in PixelFormat classes ! modules/graphics/src/main/java/javafx/scene/image/PixelFormat.java ! modules/graphics/src/main/java/javafx/scene/image/WritablePixelFormat.java Changeset: 83f1dd37a34d Author: kcr Date: 2013-08-01 17:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/83f1dd37a34d RT-31249: Mechanism to identify application ! modules/graphics/src/main/java/com/sun/javafx/application/LauncherImpl.java ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java Changeset: d0e9bba74866 Author: Chien Yang Date: 2013-08-01 18:50 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d0e9bba74866 Add Netbeans project for 3D apps/toys projects Add 3D moving camera tests. + apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCamera.java + apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCameraSubScene.java + netbeans/appsToys/FX8-3DFeatures/build.xml + netbeans/appsToys/FX8-3DFeatures/manifest.mf + netbeans/appsToys/FX8-3DFeatures/nbproject/build-impl.xml + netbeans/appsToys/FX8-3DFeatures/nbproject/genfiles.properties + netbeans/appsToys/FX8-3DFeatures/nbproject/project.properties + netbeans/appsToys/FX8-3DFeatures/nbproject/project.xml + netbeans/appsToys/ShapeT3D/build.xml + netbeans/appsToys/ShapeT3D/manifest.mf + netbeans/appsToys/ShapeT3D/nbproject/build-impl.xml + netbeans/appsToys/ShapeT3D/nbproject/genfiles.properties + netbeans/appsToys/ShapeT3D/nbproject/project.properties + netbeans/appsToys/ShapeT3D/nbproject/project.xml Changeset: a22540914163 Author: Chien Yang Date: 2013-08-01 18:54 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a22540914163 Change title name ! apps/toys/FX8-3DFeatures/src/fx83dfeatures/SimpleMovingCameraSubScene.java Changeset: c6ca49ab6269 Author: Alexander Zvegintsev Date: 2013-08-02 15:41 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c6ca49ab6269 RT-26551 Gtk: Behavior of events sending changed RT-29576 Gtk: Scrolling stops in the combobox popup when the pointer leaves the slider box ! modules/graphics/src/main/native-glass/gtk/glass_gtkcompat.cpp ! modules/graphics/src/main/native-glass/gtk/glass_gtkcompat.h ! modules/graphics/src/main/native-glass/gtk/glass_window.cpp ! modules/graphics/src/main/native-glass/gtk/glass_window.h Changeset: 16f605590496 Author: peterz Date: 2013-08-02 17:56 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/16f605590496 RT-28295 Update libxml2 library to the latest version On Windows, jfxwebkit.dll is now statically linked to the latest libxml2/libxslt ! build.gradle ! modules/web/src/main/native/Source/WebCore/TargetJava.pri Changeset: bfa38efb69fa Author: dmasada Date: 2013-08-02 09:44 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bfa38efb69fa RT-31428 TableCellFactory sample doesn't cancel editing completely - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/CheckBoxTableCell.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/EditingCell.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/TableCellFactoryApp.java Changeset: 79cd77093f2d Author: Yao Wang Date: 2013-08-02 14:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/79cd77093f2d RT-30365 FX 8 3D: Remove predefine 3d shapes' local mesh ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGBox.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGCylinder.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGSphere.java Changeset: 673c493e2fd3 Author: dmasada Date: 2013-08-02 14:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/673c493e2fd3 RT-31428 TableCellFactory sample doesn't cancel editing completely-update desc and regen sample info to get new desc ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/TableCellFactoryApp.java Changeset: dfbaa5afdd53 Author: flar Date: 2013-08-02 16:22 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dfbaa5afdd53 Fix RT-23581 - add 9-slice render methods to Prism Graphics ! modules/graphics/src/main/java/com/sun/prism/Graphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java ! modules/graphics/src/test/java/com/sun/javafx/sg/prism/TestGraphics.java Changeset: 2c8227ed3cf0 Author: flar Date: 2013-08-02 17:17 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2c8227ed3cf0 Fix RT-27752 - PixelWriter on WritableImage cannot write BYTE_INDEXED image data ! modules/graphics/src/main/java/com/sun/javafx/image/PixelUtils.java + modules/graphics/src/main/java/com/sun/javafx/image/impl/ByteIndexed.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java ! modules/graphics/src/main/java/javafx/scene/image/Image.java ! modules/graphics/src/main/java/javafx/scene/image/PixelFormat.java Changeset: 7c1ff801571d Author: flar Date: 2013-08-04 02:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7c1ff801571d Fix RT-32111 - slice removal optimizations in 9-slicing methods are overly optimistic ! modules/graphics/src/main/java/com/sun/prism/impl/BaseGraphics.java ! modules/graphics/src/main/java/com/sun/prism/impl/ps/BaseShaderGraphics.java ! modules/graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWGraphics.java Changeset: 6de8fb22ec57 Author: Rafi Tayar Date: 2013-08-04 15:48 +0300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6de8fb22ec57 RT-31892 Tap radius and time out should be configurable and set to a lower default ! modules/graphics/src/main/java/com/sun/glass/ui/lens/LensTouchInputSupport.java ! modules/graphics/src/main/native-glass/lens/input/udev/udevInput.c Changeset: 89345a49e71f Author: kcr Date: 2013-08-05 08:05 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/89345a49e71f Follow-on fix for RT-31249 to call Application.setName from FX app thread ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java Changeset: c3ffaeb2e609 Author: Chien Yang Date: 2013-08-05 10:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c3ffaeb2e609 Fix to RT-29771: Dirty regions don't work with moving camera Reviewed by Kevin ! modules/graphics/src/main/java/javafx/scene/Camera.java ! modules/graphics/src/main/java/javafx/scene/Scene.java Changeset: fcdb21d8a960 Author: Felipe Heidrich Date: 2013-08-05 14:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fcdb21d8a960 RT-30922: Implement 9-slice region background caching ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 53a4fad540f1 Author: Felipe Heidrich Date: 2013-08-05 14:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/53a4fad540f1 RT-32126: composite glyphs broken after RT-30367 ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontStrike.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWFontStrike.java ! modules/graphics/src/main/java/com/sun/prism/impl/GlyphCache.java Changeset: 3456bb1910d4 Author: Lisa.Selle at oracle.com Date: 2013-08-05 20:14 -0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3456bb1910d4 Interim fix for rt-32116 - roll back changes from commit: changeset: 4447:ff1219a1e652 parent: 4445:074b23ebf5f1 user: Martin Sladecek date: Mon Jul 29 13:33:12 2013 +0200 summary: RT-31919 ColorPicker, ArrayIndexOutOfBoundsException when saving custom color. which currently cause an NPE with a long press on virtual keyboard. See jira for details, this interim fix can be reverted when the bugs that 32116 depends on are fixed. ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/stub/java/javafx/scene/ParentTest.java Changeset: 521cced8d920 Author: tb115823 Date: 2013-08-06 08:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/521cced8d920 RT-32032 Android: VM hangs when application finishes. Detach correctly all threads. Send notification to FXActivity that VM has shutdown. ! modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java ! modules/graphics/src/android/java/com/oracle/dalvik/NativePipeReader.java ! modules/graphics/src/android/java/com/oracle/dalvik/VMLauncher.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/input/android/androidInput.c ! modules/graphics/src/main/native-glass/lens/input/android/androidInput.h ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c Changeset: bd6f656cd8a9 Author: Pavel Safrata Date: 2013-08-06 10:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bd6f656cd8a9 RT-32123: Clip properly synced after parent visibility change. Contributed-by: Tom Schindl Added unit test. ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/stub/java/javafx/scene/NodeTest.java Changeset: b0e96ed06cce Author: Pavel Safrata Date: 2013-08-06 11:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b0e96ed06cce RT-32125: Removed unnecessary call to getParent. Contributed-by: Tom Schindl ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: 91a8ecbea96e Author: Vasiliy Baranov Date: 2013-08-06 15:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/91a8ecbea96e RT-32039: Yandex Maps are broken after sync with WebKit trunk ! modules/web/src/main/native/Source/WebCore/DerivedSourcesJava.pri ! modules/web/src/main/native/Source/WebCore/page/java/ChromeClientJava.cpp ! modules/web/src/main/native/Source/WebCore/page/java/ChromeClientJava.h ! modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.cpp ! modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.h Changeset: 891fda941088 Author: Chien Yang Date: 2013-08-06 07:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/891fda941088 Fix to RT-30270: FX 8 3D: dirtyopts doesn't work for 3D rendering Reviewed by Kevin + apps/toys/FX8-3DFeatures/src/fx83dfeatures/LightMotion.java ! modules/graphics/src/main/java/javafx/scene/LightBase.java Changeset: 1661f722d536 Author: Vasiliy Baranov Date: 2013-08-06 19:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1661f722d536 Fix Mac build broken by the recent fix for RT-32039 ! modules/web/src/main/native/Source/WebCore/mapfile-macosx ! modules/web/src/main/native/Source/WebCore/mapfile-vers Changeset: 59419bdda806 Author: Felipe Heidrich Date: 2013-08-06 08:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/59419bdda806 RT-27541: Add RTL support to TextFlow ! modules/graphics/src/main/java/javafx/scene/text/TextFlow.java Changeset: 0a2b4115d537 Author: Felipe Heidrich Date: 2013-08-06 08:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0a2b4115d537 Removing out-of-date comment in checkOrientation + dosmetic changes (trailing whitespace) ! modules/graphics/src/main/java/javafx/scene/text/Text.java Changeset: 324f1d41fc48 Author: kcr Date: 2013-08-06 10:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/324f1d41fc48 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/CheckBoxTableCell.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/EditingCell.java - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupScene.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupStage.java - netbeans/android/glass-lib-lens/Android.mk - netbeans/android/glass-lib-lens/nbproject/configurations.xml - netbeans/android/glass-lib-lens/nbproject/project.xml Changeset: 147daed4b355 Author: mhowe Date: 2013-08-05 19:47 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/147daed4b355 RT-31839: Mac native bundle segfaults on application launch [ngthomas] ! buildSrc/mac.gradle Changeset: a010db088f27 Author: ngthomas Date: 2013-08-06 10:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a010db088f27 Merge - modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TwoLevelFocusComboListBehavior.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/AnimationPathHelper.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/Position2D.java - modules/graphics/src/main/java/com/sun/javafx/effect/EffectUtils.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseCacheFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseEffectFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseNodeEffectInput.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/AbstractPainter.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismCameraImpl.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismDefaultCamera.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismParallelCameraImpl.java - modules/graphics/src/main/java/com/sun/prism/camera/PrismPerspectiveCameraImpl.java Changeset: 78a1636e68b1 Author: ngthomas Date: 2013-08-06 14:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/78a1636e68b1 Merge - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/CheckBoxTableCell.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/EditingCell.java - modules/graphics/src/android/java/com/oracle/dalvik/MainActivity.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupScene.java - modules/graphics/src/main/java/com/sun/javafx/tk/quantum/PopupStage.java - netbeans/android/glass-lib-lens/Android.mk - netbeans/android/glass-lib-lens/nbproject/configurations.xml - netbeans/android/glass-lib-lens/nbproject/project.xml Changeset: 19197d39ad7f Author: hudson Date: 2013-08-08 11:07 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/19197d39ad7f Added tag 8.0-b102 for changeset 78a1636e68b1 ! .hgtags From jonathan.giles at oracle.com Thu Aug 8 13:30:33 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 09 Aug 2013 08:30:33 +1200 Subject: Rowsorting of TableView with SortedList/FilteredList In-Reply-To: References: Message-ID: <5203FFE9.50300@oracle.com> Funny you should ask about this - I just blogged about SortedList and TableView the other day, over at FXExperience: http://fxexperience.com/2013/08/returning-a-tableview-back-to-an-unsorted-state-in-javafx-8-0 Of course, I can see that you've already read that post (I see a comment from the code in my post in your code below). What might have been missed is that I noted earlier on in the blog post I had to make a few small changes to properly get SortedList support in TableView, so you'll want to try again in b102 (or b103). Regarding your use of FilteredList as well - I've not tried this at all, but I'll add it to my todo list to investigate today. I imagine there might be a bug somewhere. Whatever I find will probably make for a good post at FXExperience, so keep an eye out there too. Thanks, and if you do run into further issues, please don't hesitate to file bugs. In general, if TableView isn't sorting then something is going really wrong! -- Jonathan On 8/08/2013 11:17 p.m., Martin Kl?hn wrote: > Hi guys, > > I'm working on a business application that makes use of TableView and I'm > working with JDK 8 build b101. > > Displaying the data works like a charm. Row sorting for ordinary > ObservableLists is fine too. > > Then I've set TableView.items to FilteredList and row sorting was disabled. > replacing TableView.item with SortedList does not allow row sorting as > well. Binding the comparator of SortedList to the TableView.comparator has > no effect either. > > > // row sorting possible > //final TableView tableView = new > TableView<>(FXCollections.observableArrayList(2, 1, 3)); > > // row sorting not possible (SortedList) > // create a TableView with the sorted list set as the items it will show > // bind the sortedList comparator to the TableView comparator > //SortedList sortedList = new > SortedList<>(FXCollections.observableArrayList(2, 1, 3)); > //sortedList.comparatorProperty().bind(tableView.comparatorProperty()); > //final TableView tableView = new TableView<>(sortedList); > > // row sorting not possible (FilteredList) > //FilteredList filteredList = new > FilteredList<>(FXCollections.observableArrayList(2, 1, 3), (e) -> true); > //final TableView tableView = new TableView<>(filteredList ); > > // Don't forget to define columns! > final TableColumn integerColumn = new > TableColumn<>("Integer"); > final TableColumn hexColumn = new TableColumn<>("Integer > Hex"); > > integerColumn.setCellValueFactory(javaClass -> new > SimpleLongProperty(javaClass.getValue())); > hexColumn.setCellValueFactory(javaClass -> new > SimpleStringProperty(Integer.toHexString(javaClass.getValue()))); > > tableView.getColumns().addAll(integerColumn, hexColumn); > > > Any pointers on what I'm doing wrong or where I have to adapt my > expectations. > Is it correct that row sorting in a TableView is only possible for ordinary > ObservableLists? > > > With Regards > Martin From felix.bembrick at gmail.com Thu Aug 8 13:31:37 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 9 Aug 2013 06:31:37 +1000 Subject: JavaFX Media issues Message-ID: I am having a look at JavaFX media support and have a couple of questions: 1. It seems that the only way to load media files is by specifying a source such as a file path etc. This is not going to work well for me as all of my application's content (which includes data, digital assets, media etc.) is stored in a database on the server and is loaded through an IO stream. Why doesn't Media support loading of files through a stream? That would seem like a common use case to me! 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for JDK 8 which I found here: http://download.java.net/jdk8/jfxdocs/index.html Is this just a glitch? 3. Is buffering of media something planned for the future in JavaFX? 4. What about live streaming of media content? Thanks, Felix From hang.vo at oracle.com Thu Aug 8 13:47:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 08 Aug 2013 20:47:52 +0000 Subject: hg: openjfx/8/graphics/rt: SWT glass: trivial fix to enable menu bar on mac Message-ID: <20130808204840.BD27748729@hg.openjdk.java.net> Changeset: 3371ead571da Author: snorthov Date: 2013-08-08 16:34 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3371ead571da SWT glass: trivial fix to enable menu bar on mac ! modules/graphics/src/main/java/com/sun/glass/ui/swt/SWTApplication.java From John_Smith at symantec.com Thu Aug 8 13:54:17 2013 From: John_Smith at symantec.com (John Smith) Date: Thu, 8 Aug 2013 13:54:17 -0700 Subject: JavaFX Media issues In-Reply-To: References: Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221685BF6A06@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> JavaFX 2.2 does http live streaming: http://docs.oracle.com/javafx/2/media/overview.htm "HTTP Live Streaming Support With the addition of HTTP live streaming support, you can now download the playlist file and playback video or audio segments using JavaFX Media. Media players are now able to switch to alternate streams, as specified in the playlist file and based on network conditions. For a given stream, there is a playlist file and a set of segments into which the stream is broken. The stream can be either an MP3 raw stream or an MPEG-TS containing multiplexed AAC audio and H.264 video. The stream can be played on demand when the stream is a static file or played live when the stream is actually a live feed. In both cases, the stream can adjust its bit rate and for video, its resolution can be adjusted." More info on HTTP Live Streaming: http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/Introduction/Introduction.html Your other questions, the JavaFX media devs can answer. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Felix Bembrick Sent: Thursday, August 08, 2013 1:32 PM To: openjfx-dev at openjdk.java.net List Subject: JavaFX Media issues I am having a look at JavaFX media support and have a couple of questions: 1. It seems that the only way to load media files is by specifying a source such as a file path etc. This is not going to work well for me as all of my application's content (which includes data, digital assets, media etc.) is stored in a database on the server and is loaded through an IO stream. Why doesn't Media support loading of files through a stream? That would seem like a common use case to me! 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for JDK 8 which I found here: http://download.java.net/jdk8/jfxdocs/index.html Is this just a glitch? 3. Is buffering of media something planned for the future in JavaFX? 4. What about live streaming of media content? Thanks, Felix From richard.bair at oracle.com Thu Aug 8 13:56:48 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Aug 2013 13:56:48 -0700 Subject: JavaFX Media issues In-Reply-To: References: Message-ID: <6F3F9FEE-58C6-4C75-BDBD-B449E7FB21D5@oracle.com> > I am having a look at JavaFX media support and have a couple of questions: > > 1. It seems that the only way to load media files is by specifying a source > such as a file path etc. This is not going to work well for me as all of > my application's content (which includes data, digital assets, media etc.) > is stored in a database on the server and is loaded through an IO stream. > Why doesn't Media support loading of files through a stream? That would > seem like a common use case to me! I will have to let the media guys chime in, I don't know why we don't support a stream. At one time Image had the same limitation but we added stream support for it, so it might just be oversight. One thing to suggest is that you can install your own URL content handlers / protocols in Java. So if your URL said "myapp://nameofvideo.mov" or whatever, you can install a "myapp" protocol handler with Java which is responsible for creating the InputStream. This way you can still had us a url and we can get back your input stream, even from a custom source such as a Database. > 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for > JDK 8 which I found here: > > http://download.java.net/jdk8/jfxdocs/index.html > > Is this just a glitch? Probably got blown up during the gradle switch. Can you please file a bug (in the "build" component) > 3. Is buffering of media something planned for the future in JavaFX? > > 4. What about live streaming of media content? Kirill should have more information here. Thanks! Richard From joe.mcglynn at oracle.com Thu Aug 8 13:57:51 2013 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Thu, 8 Aug 2013 13:57:51 -0700 Subject: JavaFX Media issues In-Reply-To: References: Message-ID: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> I don't know why FX Media isn't in the FX 8 API docs, but that's clearly an error. Please file a bug on that. In the meantime, you should look at the FX 2 media docs, there isn't a lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live Streaming) are both supported, as is playback from a URL. On Aug 8, 2013, at 1:31 PM, Felix Bembrick wrote: > I am having a look at JavaFX media support and have a couple of questions: > > 1. It seems that the only way to load media files is by specifying a source > such as a file path etc. This is not going to work well for me as all of > my application's content (which includes data, digital assets, media etc.) > is stored in a database on the server and is loaded through an IO stream. > Why doesn't Media support loading of files through a stream? That would > seem like a common use case to me! > > 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for > JDK 8 which I found here: > > http://download.java.net/jdk8/jfxdocs/index.html > > Is this just a glitch? > > 3. Is buffering of media something planned for the future in JavaFX? > > 4. What about live streaming of media content? > > Thanks, > > Felix From felix.bembrick at gmail.com Thu Aug 8 14:02:26 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 9 Aug 2013 07:02:26 +1000 Subject: Developing controls based on Canvas? In-Reply-To: <52003F11.8000502@oracle.com> References: <52003F11.8000502@oracle.com> Message-ID: Hi Jonathan, Thanks for your reply. I am a little restricted in exactly what I can reveal about my plans for this control but I can say that it is one in which its very appearance could change quite significantly in a dynamic way at runtime. The control also needs to support panning and zooming in a very performant way. There will likely be a lot of graphics being draw in a manner which (to me at least) fits the immediate mode of rendering better than a scenegraph because their positions and attributes are most readily defined programmatically rather than declaratively. Though not directly analogous, consider your typical spreadsheet application like Excel where the user is able to pan to the right effectively without limits and that grid lines are constantly being rendered as the panning takes place. Given that screens can be very large these days it is conceivable that a complex spreadsheet will be displaying hundreds of lines to define the cells in a grid at any one time and that it is way more concise to programmatically define how this grid is rendered rather than having a scenegraph containing a node for each line etc. Also, the panning and zooming responses are much simpler to implement programmatically than continually fiddling around with the scenegraph. Then there's the whole issue of virtualisation and keeping the actual number of "active" nodes to a minimum if it were to be done using a scenegraph. I am just not convinced that the costs of memory usage and processing cycles to maintain a retained mode representation of a visual structure like this can be justified or made performant when all you really need is a simple algorithm that draws lines on the screen according to the properties of your cell model. Then consider that the *actual* control will be significantly more complex and graphically rich than this simplistic spreadsheet analogy. To me this is the sort of control that really lends itself to an immediate mode rendering component such as Canvas but there just seem to be so many impediments in the way of actually building a professional control with Canvas at its base. If we continue with the spreadsheet analogy then obviously cells would contain other controls etc. and we have discussed the limitations on "embedding" other controls within a Canvas that seems to suggest it's not practical. I think in the end it gets down to the nature of the control itself and whether its appearance is best defined by data or by an algorithm just like the way certain types of knowledge are best defined by nouns whereas others are best defined procedurally. At this stage it is looking very much as though JavaFX really only supports controls most appropriately defined in a static, structured way like a scenegraph. This in turns limits its applicability to a whole range of software applications. Felix On 6 August 2013 10:10, Jonathan Giles wrote: > I think it would pay to take a step back and understand why you think a > 'traditional' scenegraph-based (or retained mode) control is not sufficient > for your needs? > Unfortunately you've not detailed your use case, so it is hard to give any > specific advice. Are you able to give any details about what it is you're > trying to build and why you think the normal approach to building controls > is not sufficient? > > We've built some fairly complex controls using this approach, and if > implemented wisely, there is very little that a scenegraph-based approach > can't do. Specifically, do you think your control will render all of the > 'thousands of nodes' at once, or will many of these nodes be off screen or > otherwise not visible at any one time? For things like the TableView we > only render the nodes that are visible. This means that regardless of > whether there are 100 or 1,000,000 rows of data, we only have visual nodes > for the 20 visible rows, for example. Keeping your scenegraph as minimal as > possible is always a very wise idea, if performance is a concern. > > As you note, the other problem is that you will run into issues if you > want to mix canvas rendering with the scenegraph-based controls like > Button. The best you're likely to achieve (having not tried it personally) > is to position the control on top of the canvas, rather than attempting to > render the control inside the canvas (and having to then deal with event > handling, etc). This will likely prove to be finicky, and more cumbersome > than simply using an entirely canvas-based or entirely scenegraph-based > approach. > > -- Jonathan > > > On 5/08/2013 10:11 p.m., Felix Bembrick wrote: > >> I am investigating the feasibility of developing a JavaFX 8 control based >> on Canvas. I have chosen Canvas as the base class as this control is of a >> very dynamic nature and would not be easy to implement with a retained >> mode >> style ancestor (at least as far as I can tell). >> >> So is this feasible? While I can readily see how to render the visual >> aspects of the control, I am not sure how to best "embed" other controls >> within it should that become necessary (and almost certainly will). >> >> For example, how would I go about embedding a Button within my control? >> It >> looks to me like I would need to create an actual Button node somewhere >> else in the scenegraph and then perhaps render it within my control using >> gc.drawImage() passing in a snapshot of the Button node. That's OK but >> then I have to somehow handle events and I am not sure how best to do >> that. >> >> Another issue I see is that there seems to be no way to apply effects to >> individual graphic elements within the Canvas as the applyEffect() method >> applies to the entire Canvas. >> >> Finally, a significant obstacle is this issue: >> >> https://javafx-jira.kenai.com/**browse/RT-23822 >> >> This issue relates to the lack of support for LCD font smoothing within >> Canvas. This may not sound that serious but the difference between LCD >> font-smoothed text in other controls and the grey-scale text in Canvas is >> so distinct on my current machine that a control based on Canvas would >> really stick out like a sore thumb and appear significantly less appealing >> than a "standard" control. >> >> So, am I wasting my time? >> Are there any other issues I am likely to face? >> Are there other ways to develop dynamic controls which may involve >> thousands of nodes (such as lines, curves etc.)? >> >> Thanks, >> >> Felix >> > > From Fabrizio.Giudici at tidalwave.it Thu Aug 8 14:04:56 2013 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 08 Aug 2013 23:04:56 +0200 Subject: JavaFX Media issues In-Reply-To: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> Message-ID: On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn wrote: > I don't know why FX Media isn't in the FX 8 API docs, but that's clearly > an error. Please file a bug on that. > > In the meantime, you should look at the FX 2 media docs, there isn't a > lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live > Streaming) are both supported, as is playback from a URL. What is the strategy for codecs? I mean, now we have ImageIO (there is also JAI but it seems basically dead). ImageIO provides many image codecs and there's a SPI that can be used to support more formats. Will it be replaced by FX2 media or co-exist with it? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From John_Smith at symantec.com Thu Aug 8 14:07:29 2013 From: John_Smith at symantec.com (John Smith) Date: Thu, 8 Aug 2013 14:07:29 -0700 Subject: JavaFX Media issues In-Reply-To: <6F3F9FEE-58C6-4C75-BDBD-B449E7FB21D5@oracle.com> References: <6F3F9FEE-58C6-4C75-BDBD-B449E7FB21D5@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D221685BF6A2E@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > One thing to suggest is that you can install your own URL content handlers / protocols in Java. That won't help in this case unless you replaced the http, file or jar protocol handlers, which would be weird. "Only HTTP, FILE, and JAR URLs are supported." http://docs.oracle.com/javafx/2/api/javafx/scene/media/Media.html#Media%28java.lang.String%29 -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair Sent: Thursday, August 08, 2013 1:57 PM To: Felix Bembrick Cc: openjfx-dev at openjdk.java.net List Subject: Re: JavaFX Media issues > I am having a look at JavaFX media support and have a couple of questions: > > 1. It seems that the only way to load media files is by specifying a > source such as a file path etc. This is not going to work well for me > as all of my application's content (which includes data, digital > assets, media etc.) is stored in a database on the server and is loaded through an IO stream. > Why doesn't Media support loading of files through a stream? That > would seem like a common use case to me! I will have to let the media guys chime in, I don't know why we don't support a stream. At one time Image had the same limitation but we added stream support for it, so it might just be oversight. One thing to suggest is that you can install your own URL content handlers / protocols in Java. So if your URL said "myapp://nameofvideo.mov" or whatever, you can install a "myapp" protocol handler with Java which is responsible for creating the InputStream. This way you can still had us a url and we can get back your input stream, even from a custom source such as a Database. > 2. I am unable to locate any reference to JavaFX Media in the JavaDocs > for JDK 8 which I found here: > > http://download.java.net/jdk8/jfxdocs/index.html > > Is this just a glitch? Probably got blown up during the gradle switch. Can you please file a bug (in the "build" component) > 3. Is buffering of media something planned for the future in JavaFX? > > 4. What about live streaming of media content? Kirill should have more information here. Thanks! Richard From kevin.rushforth at oracle.com Thu Aug 8 14:14:24 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 08 Aug 2013 14:14:24 -0700 Subject: JavaFX Media issues In-Reply-To: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> Message-ID: <52040A30.5040306@oracle.com> There is already bug filed to restore the FX Media APIs to the FX 8 API docs: https://javafx-jira.kenai.com/browse/RT-32004 -- Kevin Joe McGlynn wrote: > I don't know why FX Media isn't in the FX 8 API docs, but that's clearly an error. Please file a bug on that. > > In the meantime, you should look at the FX 2 media docs, there isn't a lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live Streaming) are both supported, as is playback from a URL. > > > On Aug 8, 2013, at 1:31 PM, Felix Bembrick wrote: > > >> I am having a look at JavaFX media support and have a couple of questions: >> >> 1. It seems that the only way to load media files is by specifying a source >> such as a file path etc. This is not going to work well for me as all of >> my application's content (which includes data, digital assets, media etc.) >> is stored in a database on the server and is loaded through an IO stream. >> Why doesn't Media support loading of files through a stream? That would >> seem like a common use case to me! >> >> 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for >> JDK 8 which I found here: >> >> http://download.java.net/jdk8/jfxdocs/index.html >> >> Is this just a glitch? >> >> 3. Is buffering of media something planned for the future in JavaFX? >> >> 4. What about live streaming of media content? >> >> Thanks, >> >> Felix >> > > From jonathan.giles at oracle.com Thu Aug 8 14:16:15 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 09 Aug 2013 09:16:15 +1200 Subject: Developing controls based on Canvas? In-Reply-To: References: <52003F11.8000502@oracle.com> Message-ID: <52040A9F.3020901@oracle.com> Felix, As you are restricted in what you can say, that also restricts how I can help. However, your example of a spreadsheet not being a control that can be implemented in a scenegraph-based manner suggests that you might want to re-evaluate your assumptions. A spreadsheet would be able to be implemented in a scenegraph approach quite nicely - the TableView control comes quite close to that already (especially in JavaFX 8.0 where it can virtualise in both vertical and horizontal directions). In fact, I know of at least two spreadsheet implementations that already exist in JavaFX based on a scenegraph approach. As I've said elsewhere, the issues you are facing are because of merging two approaches (retained and immediate modes) into one control. What you are hoping to do is have your cake and eat it too, which unfortunately I don't think will end up too well for you :-) My advice is to recheck your assumptions - the scenegraph approach, in my opinion, should suit your requirements far more than an immediate mode approach (given that your requirement is to reuse existing scenegraph-based controls). I'm not sure why you think controls must be defined in a static, structured way. You could put all nodes of a control into a single Pane (or Region, etc) layout and layout all the nodes using absolute positioning. You can be as dynamic as you want to be. Unfortunately, without more information I am really unable to give any further advice, but I wish you good luck in whichever approach you decide to take. -- Jonathan On 9/08/2013 9:02 a.m., Felix Bembrick wrote: > Hi Jonathan, > > Thanks for your reply. > > I am a little restricted in exactly what I can reveal about my plans > for this control but I can say that it is one in which its very > appearance could change quite significantly in a dynamic way at > runtime. The control also needs to support panning and zooming in a > very performant way. There will likely be a lot of graphics being > draw in a manner which (to me at least) fits the immediate mode of > rendering better than a scenegraph because their positions and > attributes are most readily defined programmatically rather than > declaratively. > > Though not directly analogous, consider your typical spreadsheet > application like Excel where the user is able to pan to the right > effectively without limits and that grid lines are constantly being > rendered as the panning takes place. Given that screens can be very > large these days it is conceivable that a complex spreadsheet will be > displaying hundreds of lines to define the cells in a grid at any one > time and that it is way more concise to programmatically define how > this grid is rendered rather than having a scenegraph containing a > node for each line etc. Also, the panning and zooming responses are > much simpler to implement programmatically than continually fiddling > around with the scenegraph. Then there's the whole issue of > virtualisation and keeping the actual number of "active" nodes to a > minimum if it were to be done using a scenegraph. > > I am just not convinced that the costs of memory usage and processing > cycles to maintain a retained mode representation of a visual > structure like this can be justified or made performant when all you > really need is a simple algorithm that draws lines on the screen > according to the properties of your cell model. Then consider that > the *actual* control will be significantly more complex and > graphically rich than this simplistic spreadsheet analogy. > > To me this is the sort of control that really lends itself to an > immediate mode rendering component such as Canvas but there just seem > to be so many impediments in the way of actually building a > professional control with Canvas at its base. If we continue with the > spreadsheet analogy then obviously cells would contain other controls > etc. and we have discussed the limitations on "embedding" other > controls within a Canvas that seems to suggest it's not practical. > > I think in the end it gets down to the nature of the control itself > and whether its appearance is best defined by data or by an algorithm > just like the way certain types of knowledge are best defined by nouns > whereas others are best defined procedurally. > > At this stage it is looking very much as though JavaFX really only > supports controls most appropriately defined in a static, structured > way like a scenegraph. This in turns limits its applicability to a > whole range of software applications. > > Felix > > > On 6 August 2013 10:10, Jonathan Giles > wrote: > > I think it would pay to take a step back and understand why you > think a 'traditional' scenegraph-based (or retained mode) control > is not sufficient for your needs? > Unfortunately you've not detailed your use case, so it is hard to > give any specific advice. Are you able to give any details about > what it is you're trying to build and why you think the normal > approach to building controls is not sufficient? > > We've built some fairly complex controls using this approach, and > if implemented wisely, there is very little that a > scenegraph-based approach can't do. Specifically, do you think > your control will render all of the 'thousands of nodes' at once, > or will many of these nodes be off screen or otherwise not visible > at any one time? For things like the TableView we only render the > nodes that are visible. This means that regardless of whether > there are 100 or 1,000,000 rows of data, we only have visual nodes > for the 20 visible rows, for example. Keeping your scenegraph as > minimal as possible is always a very wise idea, if performance is > a concern. > > As you note, the other problem is that you will run into issues if > you want to mix canvas rendering with the scenegraph-based > controls like Button. The best you're likely to achieve (having > not tried it personally) is to position the control on top of the > canvas, rather than attempting to render the control inside the > canvas (and having to then deal with event handling, etc). This > will likely prove to be finicky, and more cumbersome than simply > using an entirely canvas-based or entirely scenegraph-based approach. > > -- Jonathan > > > On 5/08/2013 10:11 p.m., Felix Bembrick wrote: > > I am investigating the feasibility of developing a JavaFX 8 > control based > on Canvas. I have chosen Canvas as the base class as this > control is of a > very dynamic nature and would not be easy to implement with a > retained mode > style ancestor (at least as far as I can tell). > > So is this feasible? While I can readily see how to render > the visual > aspects of the control, I am not sure how to best "embed" > other controls > within it should that become necessary (and almost certainly > will). > > For example, how would I go about embedding a Button within my > control? It > looks to me like I would need to create an actual Button node > somewhere > else in the scenegraph and then perhaps render it within my > control using > gc.drawImage() passing in a snapshot of the Button node. > That's OK but > then I have to somehow handle events and I am not sure how > best to do that. > > Another issue I see is that there seems to be no way to apply > effects to > individual graphic elements within the Canvas as the > applyEffect() method > applies to the entire Canvas. > > Finally, a significant obstacle is this issue: > > https://javafx-jira.kenai.com/browse/RT-23822 > > This issue relates to the lack of support for LCD font > smoothing within > Canvas. This may not sound that serious but the difference > between LCD > font-smoothed text in other controls and the grey-scale text > in Canvas is > so distinct on my current machine that a control based on > Canvas would > really stick out like a sore thumb and appear significantly > less appealing > than a "standard" control. > > So, am I wasting my time? > Are there any other issues I am likely to face? > Are there other ways to develop dynamic controls which may involve > thousands of nodes (such as lines, curves etc.)? > > Thanks, > > Felix > > > From richard.bair at oracle.com Thu Aug 8 14:25:52 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Aug 2013 14:25:52 -0700 Subject: Developing controls based on Canvas? In-Reply-To: References: <52003F11.8000502@oracle.com> Message-ID: > Though not directly analogous, consider your typical spreadsheet > application like Excel where the user is able to pan to the right > effectively without limits and that grid lines are constantly being > rendered as the panning takes place. Given that screens can be very large > these days it is conceivable that a complex spreadsheet will be displaying > hundreds of lines to define the cells in a grid at any one time and that it > is way more concise to programmatically define how this grid is rendered > rather than having a scenegraph containing a node for each line etc. Also, > the panning and zooming responses are much simpler to implement > programmatically than continually fiddling around with the scenegraph. > Then there's the whole issue of virtualisation and keeping the actual > number of "active" nodes to a minimum if it were to be done using a > scenegraph. Actually I would have thought that panning / zooming would be very simple with a scene graph based approach. The difficult part is the virtualization. Although if you were building a spreadsheet like control it seems like you could build it on top of the ListView, which would give you vertical virtualization for free. You're then left with horizontal virtualization. I suppose you could use horizontal list views for that as well if you didn't want to implement your own virtualization (which might be much more efficient with domain knowledge). If you know that you're grid will always be drawn underneath the other controls, then it seems reasonable to use a Canvas (or MeshView) to implement the grid, and then position controls on top of the grid as appropriate. I don't really see it as being any more difficult than immediate mode, really. YOu have a pool of Labels or whatever, grab one from the pool, position it where you want it, do the next one, etc. Heck, you could have a GraphicsContext interface with drawString(x, y, String) that handles all this behind an abstraction. All you're doing is positioning and defining content, right? Richard From tom.schindl at bestsolution.at Thu Aug 8 14:26:00 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 08 Aug 2013 23:26:00 +0200 Subject: PrefWidth/Height calculations only works if stage is shown Message-ID: <52040CE8.9080508@bestsolution.at> Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. > BorderPane g = new BorderPane(); > TableView v = new TableView(); > g.setCenter(v); > Scene s = new Scene(g); > primaryStage.setScene(s); > System.err.println(g.prefWidth(-1)); // 0 > primaryStage.show(); > System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom From richard.bair at oracle.com Thu Aug 8 14:29:29 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Aug 2013 14:29:29 -0700 Subject: PrefWidth/Height calculations only works if stage is shown In-Reply-To: <52040CE8.9080508@bestsolution.at> References: <52040CE8.9080508@bestsolution.at> Message-ID: <136F6D95-10BC-4EBB-B228-1672573ADCC7@oracle.com> Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. Richard On Aug 8, 2013, at 2:26 PM, Tom Schindl wrote: > Hi, > > I've been trying to open a window in the minimal dimension needed by > components but it looks like size calculations prefHeight/prefWidth only > works if the stage is shown. > > I need the dimensions before showing the stage because I want to > position it on the lower right of the screen before showing the stage > because if doing it afterwards leads to flickering. > > >> BorderPane g = new BorderPane(); >> TableView v = new TableView(); >> g.setCenter(v); >> Scene s = new Scene(g); >> primaryStage.setScene(s); >> System.err.println(g.prefWidth(-1)); // 0 >> primaryStage.show(); >> System.err.println(g.prefWidth(-1)); // 248 > > Is this working as designed? > > Tom From felix.bembrick at gmail.com Thu Aug 8 14:31:34 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 9 Aug 2013 07:31:34 +1000 Subject: Developing controls based on Canvas? In-Reply-To: <52040A9F.3020901@oracle.com> References: <52003F11.8000502@oracle.com> <52040A9F.3020901@oracle.com> Message-ID: T hanks Jonathan. I'll have to check out the virtualisation that you refer to that's going on in JavaFX8 with TableView., it sounds very interesting. I am not saying that controls such as what I am proposing are *impossible* to implement using a scenegraph; it just seems natural to implement them in a more procedural/programmatic way but this could very possibly just be because I do not have a full grasp of the capabilities of the scenegraph and what can be achieved by manipulating it. To me it seems that the costs of repeatedly creating nodes (or hopefully reusing them), potentially restructuring the hierarchy of nodes in the scenegraph and adjusting each node's properties to enable a truly dynamic control would logically be much greater than just cycling through a render loop and rendering each graphic element in its correct location but, again, you seem very confident that these costs are not significant enough to prevent such a control performing well. In the end if I can get away with a scenegraph representation of this control and that massaging said scenegraph is performant enough then I am in a happy place. I have already observed that some nice stuff can happen just by playing around the scenegraph so it is quite possible that I am worrying about performance and memory issues that will never actually eventuate in practice. Felix On 9 August 2013 07:16, Jonathan Giles wrote: > Felix, > > As you are restricted in what you can say, that also restricts how I can > help. However, your example of a spreadsheet not being a control that can > be implemented in a scenegraph-based manner suggests that you might want to > re-evaluate your assumptions. A spreadsheet would be able to be implemented > in a scenegraph approach quite nicely - the TableView control comes quite > close to that already (especially in JavaFX 8.0 where it can virtualise in > both vertical and horizontal directions). In fact, I know of at least two > spreadsheet implementations that already exist in JavaFX based on a > scenegraph approach. > > As I've said elsewhere, the issues you are facing are because of merging > two approaches (retained and immediate modes) into one control. What you > are hoping to do is have your cake and eat it too, which unfortunately I > don't think will end up too well for you :-) My advice is to recheck your > assumptions - the scenegraph approach, in my opinion, should suit your > requirements far more than an immediate mode approach (given that your > requirement is to reuse existing scenegraph-based controls). > > I'm not sure why you think controls must be defined in a static, > structured way. You could put all nodes of a control into a single Pane (or > Region, etc) layout and layout all the nodes using absolute positioning. > You can be as dynamic as you want to be. > > Unfortunately, without more information I am really unable to give any > further advice, but I wish you good luck in whichever approach you decide > to take. > > -- Jonathan > > On 9/08/2013 9:02 a.m., Felix Bembrick wrote: > > Hi Jonathan, > > Thanks for your reply. > > I am a little restricted in exactly what I can reveal about my plans for > this control but I can say that it is one in which its very appearance > could change quite significantly in a dynamic way at runtime. The control > also needs to support panning and zooming in a very performant way. There > will likely be a lot of graphics being draw in a manner which (to me at > least) fits the immediate mode of rendering better than a scenegraph > because their positions and attributes are most readily defined > programmatically rather than declaratively. > > Though not directly analogous, consider your typical spreadsheet > application like Excel where the user is able to pan to the right > effectively without limits and that grid lines are constantly being > rendered as the panning takes place. Given that screens can be very large > these days it is conceivable that a complex spreadsheet will be displaying > hundreds of lines to define the cells in a grid at any one time and that it > is way more concise to programmatically define how this grid is rendered > rather than having a scenegraph containing a node for each line etc. Also, > the panning and zooming responses are much simpler to implement > programmatically than continually fiddling around with the scenegraph. > Then there's the whole issue of virtualisation and keeping the actual > number of "active" nodes to a minimum if it were to be done using a > scenegraph. > > I am just not convinced that the costs of memory usage and processing > cycles to maintain a retained mode representation of a visual structure > like this can be justified or made performant when all you really need is a > simple algorithm that draws lines on the screen according to the properties > of your cell model. Then consider that the *actual* control will be > significantly more complex and graphically rich than this simplistic > spreadsheet analogy. > > To me this is the sort of control that really lends itself to an > immediate mode rendering component such as Canvas but there just seem to be > so many impediments in the way of actually building a professional control > with Canvas at its base. If we continue with the spreadsheet analogy then > obviously cells would contain other controls etc. and we have discussed the > limitations on "embedding" other controls within a Canvas that seems to > suggest it's not practical. > > I think in the end it gets down to the nature of the control itself and > whether its appearance is best defined by data or by an algorithm just like > the way certain types of knowledge are best defined by nouns whereas others > are best defined procedurally. > > At this stage it is looking very much as though JavaFX really only > supports controls most appropriately defined in a static, structured way > like a scenegraph. This in turns limits its applicability to a whole range > of software applications. > > Felix > > > On 6 August 2013 10:10, Jonathan Giles wrote: > >> I think it would pay to take a step back and understand why you think a >> 'traditional' scenegraph-based (or retained mode) control is not sufficient >> for your needs? >> Unfortunately you've not detailed your use case, so it is hard to give >> any specific advice. Are you able to give any details about what it is >> you're trying to build and why you think the normal approach to building >> controls is not sufficient? >> >> We've built some fairly complex controls using this approach, and if >> implemented wisely, there is very little that a scenegraph-based approach >> can't do. Specifically, do you think your control will render all of the >> 'thousands of nodes' at once, or will many of these nodes be off screen or >> otherwise not visible at any one time? For things like the TableView we >> only render the nodes that are visible. This means that regardless of >> whether there are 100 or 1,000,000 rows of data, we only have visual nodes >> for the 20 visible rows, for example. Keeping your scenegraph as minimal as >> possible is always a very wise idea, if performance is a concern. >> >> As you note, the other problem is that you will run into issues if you >> want to mix canvas rendering with the scenegraph-based controls like >> Button. The best you're likely to achieve (having not tried it personally) >> is to position the control on top of the canvas, rather than attempting to >> render the control inside the canvas (and having to then deal with event >> handling, etc). This will likely prove to be finicky, and more cumbersome >> than simply using an entirely canvas-based or entirely scenegraph-based >> approach. >> >> -- Jonathan >> >> >> On 5/08/2013 10:11 p.m., Felix Bembrick wrote: >> >>> I am investigating the feasibility of developing a JavaFX 8 control based >>> on Canvas. I have chosen Canvas as the base class as this control is of >>> a >>> very dynamic nature and would not be easy to implement with a retained >>> mode >>> style ancestor (at least as far as I can tell). >>> >>> So is this feasible? While I can readily see how to render the visual >>> aspects of the control, I am not sure how to best "embed" other controls >>> within it should that become necessary (and almost certainly will). >>> >>> For example, how would I go about embedding a Button within my control? >>> It >>> looks to me like I would need to create an actual Button node somewhere >>> else in the scenegraph and then perhaps render it within my control using >>> gc.drawImage() passing in a snapshot of the Button node. That's OK but >>> then I have to somehow handle events and I am not sure how best to do >>> that. >>> >>> Another issue I see is that there seems to be no way to apply effects to >>> individual graphic elements within the Canvas as the applyEffect() method >>> applies to the entire Canvas. >>> >>> Finally, a significant obstacle is this issue: >>> >>> https://javafx-jira.kenai.com/browse/RT-23822 >>> >>> This issue relates to the lack of support for LCD font smoothing within >>> Canvas. This may not sound that serious but the difference between LCD >>> font-smoothed text in other controls and the grey-scale text in Canvas is >>> so distinct on my current machine that a control based on Canvas would >>> really stick out like a sore thumb and appear significantly less >>> appealing >>> than a "standard" control. >>> >>> So, am I wasting my time? >>> Are there any other issues I am likely to face? >>> Are there other ways to develop dynamic controls which may involve >>> thousands of nodes (such as lines, curves etc.)? >>> >>> Thanks, >>> >>> Felix >>> >> >> > > From tom.schindl at bestsolution.at Thu Aug 8 14:35:27 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 08 Aug 2013 23:35:27 +0200 Subject: PrefWidth/Height calculations only works if stage is shown In-Reply-To: <136F6D95-10BC-4EBB-B228-1672573ADCC7@oracle.com> References: <52040CE8.9080508@bestsolution.at> <136F6D95-10BC-4EBB-B228-1672573ADCC7@oracle.com> Message-ID: <52040F1F.2050603@bestsolution.at> No same result! > BorderPane g = new BorderPane(); > TableView v = new TableView(); > g.setCenter(v); > Scene s = new Scene(g); > primaryStage.setScene(s); > g.impl_reapplyCSS(); > System.err.println(g.prefWidth(-1)); // 0 > primaryStage.show(); Could it be that this does not work because if a stage is not yet shown the peers have not been created? Tom On 08.08.13 23:29, Richard Bair wrote: > Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. > > Richard > > On Aug 8, 2013, at 2:26 PM, Tom Schindl wrote: > >> Hi, >> >> I've been trying to open a window in the minimal dimension needed by >> components but it looks like size calculations prefHeight/prefWidth only >> works if the stage is shown. >> >> I need the dimensions before showing the stage because I want to >> position it on the lower right of the screen before showing the stage >> because if doing it afterwards leads to flickering. >> >> >>> BorderPane g = new BorderPane(); >>> TableView v = new TableView(); >>> g.setCenter(v); >>> Scene s = new Scene(g); >>> primaryStage.setScene(s); >>> System.err.println(g.prefWidth(-1)); // 0 >>> primaryStage.show(); >>> System.err.println(g.prefWidth(-1)); // 248 >> >> Is this working as designed? >> >> Tom > From steve.x.northover at oracle.com Thu Aug 8 14:38:56 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 08 Aug 2013 17:38:56 -0400 Subject: How to raise JavaFX iOS bugs? In-Reply-To: References: Message-ID: <52040FF0.3020509@oracle.com> Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use "iOS:" as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: > So now the Maven stuff is working ( > http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), > I'm gradually starting to muck around with the iOS stuff. > > There are problems - how do I raise them? Should I log JIRAs? Should I > bring them up here, etc? Will you guys start running jfx on iOS now that > it's possible and are bug fixes within your allowance to work on given iOS > is not a supported platform? > > For example, in the hello world example, I've included a TextField. When I > start typing in it on my iPad the field starts changing size to accommodate > the auto-correction popup, which looks very weird. Should I log that as a > bug against Controls? From felix.bembrick at gmail.com Thu Aug 8 14:38:46 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 9 Aug 2013 07:38:46 +1000 Subject: Automatic virtualisation (was Developing controls based on Canvas?) Message-ID: With all this talk of node virtualisation, I am wondering how feasible it would to build some kind of "automatic virtualiser" such that you pass it your real-world model and then it automagically works out the actual nodes and pools required and manages them seamlessly to maximise rendering performance and responsiveness? That is, it determines how many nodes will be visible at any one time and just manages all that stuff for you completely under the hood. Maybe Jonanthan you have come some way to building such a beast with your work on bidirectional virtualisation in FX 8 TableView or other controls? Felix On 9 August 2013 07:31, Felix Bembrick wrote: > T > hanks Jonathan. > > I'll have to check out the virtualisation that you refer to that's going > on in JavaFX8 with TableView., it sounds very interesting. > > I am not saying that controls such as what I am proposing are *impossible* > to implement using a scenegraph; it just seems natural to implement them in > a more procedural/programmatic way but this could very possibly just be > because I do not have a full grasp of the capabilities of the scenegraph > and what can be achieved by manipulating it. To me it seems that the costs > of repeatedly creating nodes (or hopefully reusing them), potentially > restructuring the hierarchy of nodes in the scenegraph and adjusting each > node's properties to enable a truly dynamic control would logically be much > greater than just cycling through a render loop and rendering each graphic > element in its correct location but, again, you seem very confident that > these costs are not significant enough to prevent such a control performing > well. > > In the end if I can get away with a scenegraph representation of this > control and that massaging said scenegraph is performant enough then I am > in a happy place. I have already observed that some nice stuff can happen > just by playing around the scenegraph so it is quite possible that I am > worrying about performance and memory issues that will never actually > eventuate in practice. > > Felix > > > On 9 August 2013 07:16, Jonathan Giles wrote: > >> Felix, >> >> As you are restricted in what you can say, that also restricts how I can >> help. However, your example of a spreadsheet not being a control that can >> be implemented in a scenegraph-based manner suggests that you might want to >> re-evaluate your assumptions. A spreadsheet would be able to be implemented >> in a scenegraph approach quite nicely - the TableView control comes quite >> close to that already (especially in JavaFX 8.0 where it can virtualise in >> both vertical and horizontal directions). In fact, I know of at least two >> spreadsheet implementations that already exist in JavaFX based on a >> scenegraph approach. >> >> As I've said elsewhere, the issues you are facing are because of merging >> two approaches (retained and immediate modes) into one control. What you >> are hoping to do is have your cake and eat it too, which unfortunately I >> don't think will end up too well for you :-) My advice is to recheck your >> assumptions - the scenegraph approach, in my opinion, should suit your >> requirements far more than an immediate mode approach (given that your >> requirement is to reuse existing scenegraph-based controls). >> >> I'm not sure why you think controls must be defined in a static, >> structured way. You could put all nodes of a control into a single Pane (or >> Region, etc) layout and layout all the nodes using absolute positioning. >> You can be as dynamic as you want to be. >> >> Unfortunately, without more information I am really unable to give any >> further advice, but I wish you good luck in whichever approach you decide >> to take. >> >> -- Jonathan >> >> On 9/08/2013 9:02 a.m., Felix Bembrick wrote: >> >> Hi Jonathan, >> >> Thanks for your reply. >> >> I am a little restricted in exactly what I can reveal about my plans >> for this control but I can say that it is one in which its very appearance >> could change quite significantly in a dynamic way at runtime. The control >> also needs to support panning and zooming in a very performant way. There >> will likely be a lot of graphics being draw in a manner which (to me at >> least) fits the immediate mode of rendering better than a scenegraph >> because their positions and attributes are most readily defined >> programmatically rather than declaratively. >> >> Though not directly analogous, consider your typical spreadsheet >> application like Excel where the user is able to pan to the right >> effectively without limits and that grid lines are constantly being >> rendered as the panning takes place. Given that screens can be very large >> these days it is conceivable that a complex spreadsheet will be displaying >> hundreds of lines to define the cells in a grid at any one time and that it >> is way more concise to programmatically define how this grid is rendered >> rather than having a scenegraph containing a node for each line etc. Also, >> the panning and zooming responses are much simpler to implement >> programmatically than continually fiddling around with the scenegraph. >> Then there's the whole issue of virtualisation and keeping the actual >> number of "active" nodes to a minimum if it were to be done using a >> scenegraph. >> >> I am just not convinced that the costs of memory usage and processing >> cycles to maintain a retained mode representation of a visual structure >> like this can be justified or made performant when all you really need is a >> simple algorithm that draws lines on the screen according to the properties >> of your cell model. Then consider that the *actual* control will be >> significantly more complex and graphically rich than this simplistic >> spreadsheet analogy. >> >> To me this is the sort of control that really lends itself to an >> immediate mode rendering component such as Canvas but there just seem to be >> so many impediments in the way of actually building a professional control >> with Canvas at its base. If we continue with the spreadsheet analogy then >> obviously cells would contain other controls etc. and we have discussed the >> limitations on "embedding" other controls within a Canvas that seems to >> suggest it's not practical. >> >> I think in the end it gets down to the nature of the control itself and >> whether its appearance is best defined by data or by an algorithm just like >> the way certain types of knowledge are best defined by nouns whereas others >> are best defined procedurally. >> >> At this stage it is looking very much as though JavaFX really only >> supports controls most appropriately defined in a static, structured way >> like a scenegraph. This in turns limits its applicability to a whole range >> of software applications. >> >> Felix >> >> >> On 6 August 2013 10:10, Jonathan Giles wrote: >> >>> I think it would pay to take a step back and understand why you think a >>> 'traditional' scenegraph-based (or retained mode) control is not sufficient >>> for your needs? >>> Unfortunately you've not detailed your use case, so it is hard to give >>> any specific advice. Are you able to give any details about what it is >>> you're trying to build and why you think the normal approach to building >>> controls is not sufficient? >>> >>> We've built some fairly complex controls using this approach, and if >>> implemented wisely, there is very little that a scenegraph-based approach >>> can't do. Specifically, do you think your control will render all of the >>> 'thousands of nodes' at once, or will many of these nodes be off screen or >>> otherwise not visible at any one time? For things like the TableView we >>> only render the nodes that are visible. This means that regardless of >>> whether there are 100 or 1,000,000 rows of data, we only have visual nodes >>> for the 20 visible rows, for example. Keeping your scenegraph as minimal as >>> possible is always a very wise idea, if performance is a concern. >>> >>> As you note, the other problem is that you will run into issues if you >>> want to mix canvas rendering with the scenegraph-based controls like >>> Button. The best you're likely to achieve (having not tried it personally) >>> is to position the control on top of the canvas, rather than attempting to >>> render the control inside the canvas (and having to then deal with event >>> handling, etc). This will likely prove to be finicky, and more cumbersome >>> than simply using an entirely canvas-based or entirely scenegraph-based >>> approach. >>> >>> -- Jonathan >>> >>> >>> On 5/08/2013 10:11 p.m., Felix Bembrick wrote: >>> >>>> I am investigating the feasibility of developing a JavaFX 8 control >>>> based >>>> on Canvas. I have chosen Canvas as the base class as this control is >>>> of a >>>> very dynamic nature and would not be easy to implement with a retained >>>> mode >>>> style ancestor (at least as far as I can tell). >>>> >>>> So is this feasible? While I can readily see how to render the visual >>>> aspects of the control, I am not sure how to best "embed" other controls >>>> within it should that become necessary (and almost certainly will). >>>> >>>> For example, how would I go about embedding a Button within my control? >>>> It >>>> looks to me like I would need to create an actual Button node somewhere >>>> else in the scenegraph and then perhaps render it within my control >>>> using >>>> gc.drawImage() passing in a snapshot of the Button node. That's OK but >>>> then I have to somehow handle events and I am not sure how best to do >>>> that. >>>> >>>> Another issue I see is that there seems to be no way to apply effects to >>>> individual graphic elements within the Canvas as the applyEffect() >>>> method >>>> applies to the entire Canvas. >>>> >>>> Finally, a significant obstacle is this issue: >>>> >>>> https://javafx-jira.kenai.com/browse/RT-23822 >>>> >>>> This issue relates to the lack of support for LCD font smoothing within >>>> Canvas. This may not sound that serious but the difference between LCD >>>> font-smoothed text in other controls and the grey-scale text in Canvas >>>> is >>>> so distinct on my current machine that a control based on Canvas would >>>> really stick out like a sore thumb and appear significantly less >>>> appealing >>>> than a "standard" control. >>>> >>>> So, am I wasting my time? >>>> Are there any other issues I am likely to face? >>>> Are there other ways to develop dynamic controls which may involve >>>> thousands of nodes (such as lines, curves etc.)? >>>> >>>> Thanks, >>>> >>>> Felix >>>> >>> >>> >> >> > From richard.bair at oracle.com Thu Aug 8 14:40:42 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Aug 2013 14:40:42 -0700 Subject: PrefWidth/Height calculations only works if stage is shown In-Reply-To: <52040F1F.2050603@bestsolution.at> References: <52040CE8.9080508@bestsolution.at> <136F6D95-10BC-4EBB-B228-1672573ADCC7@oracle.com> <52040F1F.2050603@bestsolution.at> Message-ID: <5E73DAEC-8C9C-49EE-BEAD-369C5ACBCE7C@oracle.com> The peers don't impact the preferred sizes at all. Use this one instead of impl_reapplyCSS (wrong one) impl_processCSS(true) On Aug 8, 2013, at 2:35 PM, Tom Schindl wrote: > No same result! > >> BorderPane g = new BorderPane(); >> TableView v = new TableView(); >> g.setCenter(v); >> Scene s = new Scene(g); >> primaryStage.setScene(s); >> g.impl_reapplyCSS(); >> System.err.println(g.prefWidth(-1)); // 0 >> primaryStage.show(); > > Could it be that this does not work because if a stage is not yet shown > the peers have not been created? > > Tom > > On 08.08.13 23:29, Richard Bair wrote: >> Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. >> >> Richard >> >> On Aug 8, 2013, at 2:26 PM, Tom Schindl wrote: >> >>> Hi, >>> >>> I've been trying to open a window in the minimal dimension needed by >>> components but it looks like size calculations prefHeight/prefWidth only >>> works if the stage is shown. >>> >>> I need the dimensions before showing the stage because I want to >>> position it on the lower right of the screen before showing the stage >>> because if doing it afterwards leads to flickering. >>> >>> >>>> BorderPane g = new BorderPane(); >>>> TableView v = new TableView(); >>>> g.setCenter(v); >>>> Scene s = new Scene(g); >>>> primaryStage.setScene(s); >>>> System.err.println(g.prefWidth(-1)); // 0 >>>> primaryStage.show(); >>>> System.err.println(g.prefWidth(-1)); // 248 >>> >>> Is this working as designed? >>> >>> Tom >> > From tom.schindl at bestsolution.at Thu Aug 8 14:47:53 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 08 Aug 2013 23:47:53 +0200 Subject: PrefWidth/Height calculations only works if stage is shown In-Reply-To: <5E73DAEC-8C9C-49EE-BEAD-369C5ACBCE7C@oracle.com> References: <52040CE8.9080508@bestsolution.at> <136F6D95-10BC-4EBB-B228-1672573ADCC7@oracle.com> <52040F1F.2050603@bestsolution.at> <5E73DAEC-8C9C-49EE-BEAD-369C5ACBCE7C@oracle.com> Message-ID: <52041209.4030804@bestsolution.at> Prefect! Tom On 08.08.13 23:40, Richard Bair wrote: > The peers don't impact the preferred sizes at all. Use this one instead of impl_reapplyCSS (wrong one) > > impl_processCSS(true) > > > On Aug 8, 2013, at 2:35 PM, Tom Schindl wrote: > >> No same result! >> >>> BorderPane g = new BorderPane(); >>> TableView v = new TableView(); >>> g.setCenter(v); >>> Scene s = new Scene(g); >>> primaryStage.setScene(s); >>> g.impl_reapplyCSS(); >>> System.err.println(g.prefWidth(-1)); // 0 >>> primaryStage.show(); >> >> Could it be that this does not work because if a stage is not yet shown >> the peers have not been created? >> >> Tom >> >> On 08.08.13 23:29, Richard Bair wrote: >>> Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. >>> >>> Richard >>> >>> On Aug 8, 2013, at 2:26 PM, Tom Schindl wrote: >>> >>>> Hi, >>>> >>>> I've been trying to open a window in the minimal dimension needed by >>>> components but it looks like size calculations prefHeight/prefWidth only >>>> works if the stage is shown. >>>> >>>> I need the dimensions before showing the stage because I want to >>>> position it on the lower right of the screen before showing the stage >>>> because if doing it afterwards leads to flickering. >>>> >>>> >>>>> BorderPane g = new BorderPane(); >>>>> TableView v = new TableView(); >>>>> g.setCenter(v); >>>>> Scene s = new Scene(g); >>>>> primaryStage.setScene(s); >>>>> System.err.println(g.prefWidth(-1)); // 0 >>>>> primaryStage.show(); >>>>> System.err.println(g.prefWidth(-1)); // 248 >>>> >>>> Is this working as designed? >>>> >>>> Tom >>> >> > From zonski at gmail.com Thu Aug 8 15:08:16 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 9 Aug 2013 08:08:16 +1000 Subject: How to raise JavaFX iOS bugs? In-Reply-To: <52040FF0.3020509@oracle.com> References: <52040FF0.3020509@oracle.com> Message-ID: <45F53F2D-AF85-406A-AE3D-81029F460EDB@gmail.com> No, I didn't get a chance. Probably easier for you to just raise it now? It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northover at oracle.com wrote: > Hi Daniel, > > Did you log a bug for the TextField problem? If you have not done so, please do. If you use "iOS:" as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. > > Steve > > On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: >> So now the Maven stuff is working ( >> http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), >> I'm gradually starting to muck around with the iOS stuff. >> >> There are problems - how do I raise them? Should I log JIRAs? Should I >> bring them up here, etc? Will you guys start running jfx on iOS now that >> it's possible and are bug fixes within your allowance to work on given iOS >> is not a supported platform? >> >> For example, in the hello world example, I've included a TextField. When I >> start typing in it on my iPad the field starts changing size to accommodate >> the auto-correction popup, which looks very weird. Should I log that as a >> bug against Controls? > From pedro.duquevieira at gmail.com Thu Aug 8 16:59:26 2013 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 9 Aug 2013 00:59:26 +0100 Subject: Chart CategoryView - setLowerBound(...) and setUpperBound(...) Message-ID: Hi, I already posted this question on the JavaFX forum but got no answer. I have a chart with a CategoryAxis for the x values and a NumberAxis for the y values. I want to enable zooming in this chart. For the NumberAxis I'm planing to use the setLowerBound(...) and setUpperBound(...) methods to zoom in the particular region the user has chosen. But for the CategoryAxis I don't see any method similar to these ones. How can I do this? (I'm using JavaFX8) Thanks in advance, -- Pedro Duque Vieira From swpalmer at gmail.com Thu Aug 8 17:10:44 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 8 Aug 2013 20:10:44 -0400 Subject: JavaFX Media issues In-Reply-To: References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> Message-ID: The Media APIs are mostly useless in their current state. Other than demoing that you can play a video, they don't go far enough to be of practical value. I tried to get someone to pay attention to them back in the JavaFX 1.0 days https://javafx-jira.kenai.com/browse/RT-2684 at least someone listened to the request to get H.264 support in there, but that is just a workaround. We need to be able to get our data into the media pipeline. This would allow those of us that have attempted to do a video window to have a fighting chance. Canvas can't keep up and will likely crash the app with out of memory errors. Support for drawing into a native surface (OpenGL or D3D context) has been talked about, but doesn't appear to be on the horizon yet. If we just had a hook to get the dang pixel data into the media pipeline so we could supply the "next frame" with whatever we want - either from any native codec via JNI, or dynamically generated from Java code, whatever... that would be just so dang useful... (to me at least) Regards, Scott On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici < Fabrizio.Giudici at tidalwave.it> wrote: > On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn > wrote: > > I don't know why FX Media isn't in the FX 8 API docs, but that's clearly >> an error. Please file a bug on that. >> >> In the meantime, you should look at the FX 2 media docs, there isn't a >> lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live >> Streaming) are both supported, as is playback from a URL. >> > > What is the strategy for codecs? I mean, now we have ImageIO (there is > also JAI but it seems basically dead). ImageIO provides many image codecs > and there's a SPI that can be used to support more formats. Will it be > replaced by FX2 media or co-exist with it? > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/**blog - > fabrizio.giudici at tidalwave.it > From felix.bembrick at gmail.com Thu Aug 8 17:15:39 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 9 Aug 2013 10:15:39 +1000 Subject: JavaFX Media issues In-Reply-To: References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> Message-ID: Scott, That JIRA issue doesn't make any mention of getting hooks into pixel data etc., it only refers to user defined codecs. Maybe you could open another issue to manage the wishlist of missing features such as the ones you referred to? I too would very much like to see greatly improved media support in JavaFX. Felix On 9 August 2013 10:10, Scott Palmer wrote: > The Media APIs are mostly useless in their current state. Other than > demoing that you can play a video, they don't go far enough to be of > practical value. I tried to get someone to pay attention to them back in > the JavaFX 1.0 days > https://javafx-jira.kenai.com/browse/RT-2684 > > at least someone listened to the request to get H.264 support in there, > but that is just a workaround. We need to be able to get our data into the > media pipeline. This would allow those of us that have attempted to do a > video window to have a fighting chance. Canvas can't keep up and will > likely crash the app with out of memory errors. Support for drawing into a > native surface (OpenGL or D3D context) has been talked about, but doesn't > appear to be on the horizon yet. If we just had a hook to get the dang > pixel data into the media pipeline so we could supply the "next frame" with > whatever we want - either from any native codec via JNI, or dynamically > generated from Java code, whatever... that would be just so dang useful... > (to me at least) > > Regards, > > Scott > > > > On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici < > Fabrizio.Giudici at tidalwave.it> wrote: > >> On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn >> wrote: >> >> I don't know why FX Media isn't in the FX 8 API docs, but that's clearly >>> an error. Please file a bug on that. >>> >>> In the meantime, you should look at the FX 2 media docs, there isn't a >>> lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live >>> Streaming) are both supported, as is playback from a URL. >>> >> >> What is the strategy for codecs? I mean, now we have ImageIO (there is >> also JAI but it seems basically dead). ImageIO provides many image codecs >> and there's a SPI that can be used to support more formats. Will it be >> replaced by FX2 media or co-exist with it? >> >> >> -- >> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >> "We make Java work. Everywhere." >> http://tidalwave.it/fabrizio/**blog - >> fabrizio.giudici at tidalwave.it >> > > From zonski at gmail.com Thu Aug 8 17:19:06 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 9 Aug 2013 10:19:06 +1000 Subject: JavaFX Media issues In-Reply-To: References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> Message-ID: I don't want to detract from the issues around media stuff (they are significant), but if you are desperate (as I was), here's some code for doing video capture and streaming based on LTI-CIVIL and writing to JFX image to render the video: - https://code.google.com/p/jfxcamera/ It's a work around and not elegant at all, and media needs to have a lot done to be useful. I only include it here in case there is something useful you can take from it to hobble through. On Fri, Aug 9, 2013 at 10:10 AM, Scott Palmer wrote: > The Media APIs are mostly useless in their current state. Other than > demoing that you can play a video, they don't go far enough to be of > practical value. I tried to get someone to pay attention to them back in > the JavaFX 1.0 days > https://javafx-jira.kenai.com/browse/RT-2684 > > at least someone listened to the request to get H.264 support in there, but > that is just a workaround. We need to be able to get our data into the > media pipeline. This would allow those of us that have attempted to do a > video window to have a fighting chance. Canvas can't keep up and will > likely crash the app with out of memory errors. Support for drawing into a > native surface (OpenGL or D3D context) has been talked about, but doesn't > appear to be on the horizon yet. If we just had a hook to get the dang > pixel data into the media pipeline so we could supply the "next frame" with > whatever we want - either from any native codec via JNI, or dynamically > generated from Java code, whatever... that would be just so dang useful... > (to me at least) > > Regards, > > Scott > > > > On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici < > Fabrizio.Giudici at tidalwave.it> wrote: > > > On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn > > wrote: > > > > I don't know why FX Media isn't in the FX 8 API docs, but that's clearly > >> an error. Please file a bug on that. > >> > >> In the meantime, you should look at the FX 2 media docs, there isn't a > >> lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live > >> Streaming) are both supported, as is playback from a URL. > >> > > > > What is the strategy for codecs? I mean, now we have ImageIO (there is > > also JAI but it seems basically dead). ImageIO provides many image codecs > > and there's a SPI that can be used to support more formats. Will it be > > replaced by FX2 media or co-exist with it? > > > > > > -- > > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > > "We make Java work. Everywhere." > > http://tidalwave.it/fabrizio/**blog > - > > fabrizio.giudici at tidalwave.it > > > From swpalmer at gmail.com Thu Aug 8 17:20:29 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 8 Aug 2013 20:20:29 -0400 Subject: JavaFX Media issues In-Reply-To: References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> Message-ID: I was referring to supplying the pixel data to the media nodes. Getting the pixel data of the media from the media nodes should also be possible. It actually is possible now to a degree via the "snapshot" method on Node. Though I encountered a lot of lock-up problems when I tried it. Scott On Thu, Aug 8, 2013 at 8:15 PM, Felix Bembrick wrote: > Scott, > > That JIRA issue doesn't make any mention of getting hooks into pixel data > etc., it only refers to user defined codecs. > > Maybe you could open another issue to manage the wishlist of missing > features such as the ones you referred to? I too would very much like to > see greatly improved media support in JavaFX. > > Felix > > > On 9 August 2013 10:10, Scott Palmer wrote: > >> The Media APIs are mostly useless in their current state. Other than >> demoing that you can play a video, they don't go far enough to be of >> practical value. I tried to get someone to pay attention to them back in >> the JavaFX 1.0 days >> https://javafx-jira.kenai.com/browse/RT-2684 >> >> at least someone listened to the request to get H.264 support in there, >> but that is just a workaround. We need to be able to get our data into the >> media pipeline. This would allow those of us that have attempted to do a >> video window to have a fighting chance. Canvas can't keep up and will >> likely crash the app with out of memory errors. Support for drawing into a >> native surface (OpenGL or D3D context) has been talked about, but doesn't >> appear to be on the horizon yet. If we just had a hook to get the dang >> pixel data into the media pipeline so we could supply the "next frame" with >> whatever we want - either from any native codec via JNI, or dynamically >> generated from Java code, whatever... that would be just so dang useful... >> (to me at least) >> >> Regards, >> >> Scott >> >> >> >> On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici < >> Fabrizio.Giudici at tidalwave.it> wrote: >> >>> On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn >>> wrote: >>> >>> I don't know why FX Media isn't in the FX 8 API docs, but that's >>>> clearly an error. Please file a bug on that. >>>> >>>> In the meantime, you should look at the FX 2 media docs, there isn't a >>>> lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live >>>> Streaming) are both supported, as is playback from a URL. >>>> >>> >>> What is the strategy for codecs? I mean, now we have ImageIO (there is >>> also JAI but it seems basically dead). ImageIO provides many image codecs >>> and there's a SPI that can be used to support more formats. Will it be >>> replaced by FX2 media or co-exist with it? >>> >>> >>> -- >>> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >>> "We make Java work. Everywhere." >>> http://tidalwave.it/fabrizio/**blog - >>> fabrizio.giudici at tidalwave.it >>> >> >> > From hjohn at xs4all.nl Thu Aug 8 18:06:10 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 09 Aug 2013 03:06:10 +0200 Subject: JavaFX Media issues In-Reply-To: References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> Message-ID: <52044082.30407@xs4all.nl> On 9/08/2013 02:10, Scott Palmer wrote: > The Media APIs are mostly useless in their current state. Other than > demoing that you can play a video, they don't go far enough to be of > practical value. I tried to get someone to pay attention to them back in > the JavaFX 1.0 days > https://javafx-jira.kenai.com/browse/RT-2684 Unfortunately, I have to agree here. I'd love to use the Media APIs of JavaFX, but they are way to limited. At a minimum I'd need support for MKV containers and some common audio formats used with these. Decoding AVI containers would be rather important as well. Without those, JavaFX video is basically limited to "bring your own" videos only and completely unsuitable for playing back videos that end users might have... Instead, I've been using VLC + VLCJ from day one while working with JavaFX as a work-around. > at least someone listened to the request to get H.264 support in there, but > that is just a workaround. We need to be able to get our data into the > media pipeline. This would allow those of us that have attempted to do a > video window to have a fighting chance. Canvas can't keep up and will > likely crash the app with out of memory errors. Support for drawing into a > native surface (OpenGL or D3D context) has been talked about, but doesn't > appear to be on the horizon yet. If we just had a hook to get the dang > pixel data into the media pipeline so we could supply the "next frame" with > whatever we want - either from any native codec via JNI, or dynamically > generated from Java code, whatever... that would be just so dang useful... > (to me at least) This would atleast allow me to decode the MKV container myself and supply data... not looking forward to having to write all that code, but I would if it meant I'd be able to go "native" JavaFX with video. Canvas however is working for me even with HD video (copying 25 frames/sec of HD video from VLCJ to Canvas). Playback is smooth even with 1920x1080 video for hours long video, and I can't tell the difference with a native player or copying frame by frame using pixelWriter anymore. There is some CPU penalty but on a my system it is well below 5%. This is basically how that looks with VLCJ: new RenderCallback() { @Override public void display(DirectMediaPlayer mp, Memory[] memory, final BufferFormat bufferFormat) { final ByteBuffer byteBuffer = memory[0].getByteBuffer(0, memory[0].size()); Platform.runLater(new Runnable() { @Override public void run() { pixelWriter.setPixels(0, 0, bufferFormat.getWidth(), bufferFormat.getHeight(), byteBgraInstance, byteBuffer, bufferFormat.getPitches()[0]); } }); } } However, the bug where Canvas keeps buffering data when off-screen sometimes bites me, resulting in out of memory errors -- even slight display delays can fairly easily cause this when video is running at 25 fps (takes about a second to go through 256 MB of memory). --John > > Regards, > > Scott > > > > On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici< > Fabrizio.Giudici at tidalwave.it> wrote: > >> On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn >> wrote: >> >> I don't know why FX Media isn't in the FX 8 API docs, but that's clearly >>> an error. Please file a bug on that. >>> >>> In the meantime, you should look at the FX 2 media docs, there isn't a >>> lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live >>> Streaming) are both supported, as is playback from a URL. >>> >> What is the strategy for codecs? I mean, now we have ImageIO (there is >> also JAI but it seems basically dead). ImageIO provides many image codecs >> and there's a SPI that can be used to support more formats. Will it be >> replaced by FX2 media or co-exist with it? >> >> >> -- >> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >> "We make Java work. Everywhere." >> http://tidalwave.it/fabrizio/**blog - >> fabrizio.giudici at tidalwave.it >> From swpalmer at gmail.com Thu Aug 8 18:48:55 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 8 Aug 2013 21:48:55 -0400 Subject: JavaFX Media issues In-Reply-To: <52044082.30407@xs4all.nl> References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> <52044082.30407@xs4all.nl> Message-ID: At minimum the Media Player must support H.264, MP3, AAC (so there is a guarantee of a cross-platform format) and then defer to the default platform media decoder for everything else. I.e. *anything* that the standard OS provided media system can decode - I.e. QuickTime on Mac, GStreamer on Linux, DirectShow on Windows. But all that is needed is the hook and the community can make the bindings to QuickTime, VLC, etc. The current implementation appears to be too unstable to rely on at the moment anyway though: https://javafx-jira.kenai.com/browse/RT-31412 I have heard rumors of people being able to play HD video via Canvas. I have tried everything and can't come close. (Yes, I have been careful about the pixel format.) I mean, it looks like it is working for a few seconds, but then as the memory fills with the Canvas backlog it can lead to the GC using a lot more CPU, thus reducing the ability for Canvas to process its command queue even further, well it just collapses in on itself and dies. Is your app able to do *anything* else while the video is playing? The slightest delay to the rendering and that Canvas buffering bug kills the app. Not that it would matter if it could keep up, because the off-screen thing is also a deal breaker. Of course 25fps is well below the 60fps required for full-speed video. I suspect it is the frame rate more than the frame size that matters here. Plain old, standard definition, interlaced, 60 fields per second will probably kill most apps with the current Canvas implementation. We need something better. I proposed having at least a JNI method so we could get native window handles from Stages but didn't get any traction either. Security was brought up as a concern, which I totally do NOT understand as the use of JNI means you are out of the Java sandbox already. If we had native window handles we might be able get our own window for rendering to at least interact nicely with the Stage. (We already did this successfully in Swing via JAWT and a heavyweight component that we paint to from native code) Regards, Scott On Thu, Aug 8, 2013 at 9:06 PM, John Hendrikx wrote: > On 9/08/2013 02:10, Scott Palmer wrote: > >> The Media APIs are mostly useless in their current state. Other than >> demoing that you can play a video, they don't go far enough to be of >> practical value. I tried to get someone to pay attention to them back in >> the JavaFX 1.0 days >> https://javafx-jira.kenai.com/**browse/RT-2684 >> > > Unfortunately, I have to agree here. I'd love to use the Media APIs of > JavaFX, but they are way to limited. At a minimum I'd need support for MKV > containers and some common audio formats used with these. Decoding AVI > containers would be rather important as well. Without those, JavaFX video > is basically limited to "bring your own" videos only and completely > unsuitable for playing back videos that end users might have... > > Instead, I've been using VLC + VLCJ from day one while working with JavaFX > as a work-around. > > > at least someone listened to the request to get H.264 support in there, >> but >> that is just a workaround. We need to be able to get our data into the >> media pipeline. This would allow those of us that have attempted to do a >> video window to have a fighting chance. Canvas can't keep up and will >> likely crash the app with out of memory errors. Support for drawing into >> a >> native surface (OpenGL or D3D context) has been talked about, but doesn't >> appear to be on the horizon yet. If we just had a hook to get the dang >> pixel data into the media pipeline so we could supply the "next frame" >> with >> whatever we want - either from any native codec via JNI, or dynamically >> generated from Java code, whatever... that would be just so dang useful... >> (to me at least) >> > This would atleast allow me to decode the MKV container myself and supply > data... not looking forward to having to write all that code, but I would > if it meant I'd be able to go "native" JavaFX with video. > > Canvas however is working for me even with HD video (copying 25 frames/sec > of HD video from VLCJ to Canvas). Playback is smooth even with 1920x1080 > video for hours long video, and I can't tell the difference with a native > player or copying frame by frame using pixelWriter anymore. There is some > CPU penalty but on a my system it is well below 5%. This is basically how > that looks with VLCJ: > > new RenderCallback() { > @Override > public void display(DirectMediaPlayer mp, Memory[] memory, final > BufferFormat bufferFormat) { > final ByteBuffer byteBuffer = memory[0].getByteBuffer(0, > memory[0].size()); > > Platform.runLater(new Runnable() { > @Override > public void run() { > pixelWriter.setPixels(0, 0, bufferFormat.getWidth(), > bufferFormat.getHeight(), byteBgraInstance, byteBuffer, > bufferFormat.getPitches()[0]); > } > }); > } > } > > However, the bug where Canvas keeps buffering data when off-screen > sometimes bites me, resulting in out of memory errors -- even slight > display delays can fairly easily cause this when video is running at 25 fps > (takes about a second to go through 256 MB of memory). > > --John > > >> Regards, >> >> Scott >> >> >> >> On Thu, Aug 8, 2013 at 5:04 PM, Fabrizio Giudici< >> Fabrizio.Giudici at tidalwave.it> wrote: >> >> On Thu, 08 Aug 2013 22:57:51 +0200, Joe McGlynn>> > >>> wrote: >>> >>> I don't know why FX Media isn't in the FX 8 API docs, but that's >>> clearly >>> >>>> an error. Please file a bug on that. >>>> >>>> In the meantime, you should look at the FX 2 media docs, there isn't a >>>> lot of change from FX2 media in FX8. Buffering and streaming (HTTP Live >>>> Streaming) are both supported, as is playback from a URL. >>>> >>>> What is the strategy for codecs? I mean, now we have ImageIO (there is >>> also JAI but it seems basically dead). ImageIO provides many image codecs >>> and there's a SPI that can be used to support more formats. Will it be >>> replaced by FX2 media or co-exist with it? >>> >>> >>> -- >>> Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. >>> "We make Java work. Everywhere." >>> http://tidalwave.it/fabrizio/****blog >>> > >>> - >>> fabrizio.giudici at tidalwave.it >>> >>> > From hang.vo at oracle.com Thu Aug 8 22:48:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 09 Aug 2013 05:48:06 +0000 Subject: hg: openjfx/8/graphics/rt: RT-30650: SwingNode is not Resizable Message-ID: <20130809054912.5252348738@hg.openjdk.java.net> Changeset: 29a56291f75e Author: ant Date: 2013-08-09 09:38 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/29a56291f75e RT-30650: SwingNode is not Resizable Reviewed-by: anthony, art ! build.properties ! modules/swing/src/main/java/javafx/embed/swing/SwingNode.java + tests/graphics/SwingInterop/test/javafx/embed/swing/RT30650GUI.java + tests/graphics/SwingInterop/test/javafx/embed/swing/RT30650Test.java From tobi at ultramixer.com Thu Aug 8 22:51:34 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 9 Aug 2013 07:51:34 +0200 Subject: How to raise JavaFX iOS bugs? In-Reply-To: <45F53F2D-AF85-406A-AE3D-81029F460EDB@gmail.com> References: <52040FF0.3020509@oracle.com> <45F53F2D-AF85-406A-AE3D-81029F460EDB@gmail.com> Message-ID: <4E1F265D-071B-4B52-8D15-C8DC4813F4B8@ultramixer.com> Daniel, the question is: Which surprise will Oracle show on JavaOne 2013 in september? Maybe there is something official concerning JavaFX and iOS and Android?? Please take a look a the planned tracks: http://blog.software4java.com/?p=97 One track talks about ?JavaSE in AOT mode??so maybe we do not need such a backport in the future? Because Oracle does not say anything about the future, we don?t know it at the moment ;) Best regards, Tobi Am 09.08.2013 um 00:08 schrieb Daniel Zwolenski : > No, I didn't get a chance. Probably easier for you to just raise it now? > > It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. > > I could simplify the last step by allowing the version of jfx backport to be configurable. > > As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? > > > On 09/08/2013, at 7:38 AM, steve.x.northover at oracle.com wrote: > >> Hi Daniel, >> >> Did you log a bug for the TextField problem? If you have not done so, please do. If you use "iOS:" as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. >> >> Steve >> >> On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: >>> So now the Maven stuff is working ( >>> http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), >>> I'm gradually starting to muck around with the iOS stuff. >>> >>> There are problems - how do I raise them? Should I log JIRAs? Should I >>> bring them up here, etc? Will you guys start running jfx on iOS now that >>> it's possible and are bug fixes within your allowance to work on given iOS >>> is not a supported platform? >>> >>> For example, in the hello world example, I've included a TextField. When I >>> start typing in it on my iPad the field starts changing size to accommodate >>> the auto-correction popup, which looks very weird. Should I log that as a >>> bug against Controls? >> From zonski at gmail.com Thu Aug 8 23:26:25 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 9 Aug 2013 16:26:25 +1000 Subject: How to raise JavaFX iOS bugs? In-Reply-To: <4E1F265D-071B-4B52-8D15-C8DC4813F4B8@ultramixer.com> References: <52040FF0.3020509@oracle.com> <45F53F2D-AF85-406A-AE3D-81029F460EDB@gmail.com> <4E1F265D-071B-4B52-8D15-C8DC4813F4B8@ultramixer.com> Message-ID: <9EC72C94-B439-4FBF-81AD-0FE41E8FF423@gmail.com> Wtf? Oracle guys, what JVM is this session going to use? https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=5517 On 09/08/2013, at 3:51 PM, Tobias Bley wrote: > Daniel, the question is: Which surprise will Oracle show on JavaOne 2013 in september? Maybe there is something official concerning JavaFX and iOS and Android?? Please take a look a the planned tracks: http://blog.software4java.com/?p=97 > One track talks about ?JavaSE in AOT mode??so maybe we do not need such a backport in the future? Because Oracle does not say anything about the future, we don?t know it at the moment ;) > > Best regards, > Tobi > > > Am 09.08.2013 um 00:08 schrieb Daniel Zwolenski : > >> No, I didn't get a chance. Probably easier for you to just raise it now? >> >> It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. >> >> I could simplify the last step by allowing the version of jfx backport to be configurable. >> >> As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? >> >> >> On 09/08/2013, at 7:38 AM, steve.x.northover at oracle.com wrote: >> >>> Hi Daniel, >>> >>> Did you log a bug for the TextField problem? If you have not done so, please do. If you use "iOS:" as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. >>> >>> Steve >>> >>> On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: >>>> So now the Maven stuff is working ( >>>> http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), >>>> I'm gradually starting to muck around with the iOS stuff. >>>> >>>> There are problems - how do I raise them? Should I log JIRAs? Should I >>>> bring them up here, etc? Will you guys start running jfx on iOS now that >>>> it's possible and are bug fixes within your allowance to work on given iOS >>>> is not a supported platform? >>>> >>>> For example, in the hello world example, I've included a TextField. When I >>>> start typing in it on my iPad the field starts changing size to accommodate >>>> the auto-correction popup, which looks very weird. Should I log that as a >>>> bug against Controls? >>> > From felix.bembrick at gmail.com Fri Aug 9 00:17:14 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 9 Aug 2013 17:17:14 +1000 Subject: How to raise JavaFX iOS bugs? In-Reply-To: <9EC72C94-B439-4FBF-81AD-0FE41E8FF423@gmail.com> References: <52040FF0.3020509@oracle.com> <45F53F2D-AF85-406A-AE3D-81029F460EDB@gmail.com> <4E1F265D-071B-4B52-8D15-C8DC4813F4B8@ultramixer.com> <9EC72C94-B439-4FBF-81AD-0FE41E8FF423@gmail.com> Message-ID: I have a very good feeling about JavaOne this year. It's now or never for Java/JavaFX on mobiles and tablets and judging by the session titles, I think Oracle is going to make a lot of people very happy :-) On 9 August 2013 16:26, Daniel Zwolenski wrote: > Wtf? Oracle guys, what JVM is this session going to use? > > > https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=5517 > > > On 09/08/2013, at 3:51 PM, Tobias Bley wrote: > > > Daniel, the question is: Which surprise will Oracle show on JavaOne 2013 > in september? Maybe there is something official concerning JavaFX and iOS > and Android?? Please take a look a the planned tracks: > http://blog.software4java.com/?p=97 > > One track talks about ?JavaSE in AOT mode??so maybe we do not need such > a backport in the future? Because Oracle does not say anything about the > future, we don?t know it at the moment ;) > > > > Best regards, > > Tobi > > > > > > Am 09.08.2013 um 00:08 schrieb Daniel Zwolenski : > > > >> No, I didn't get a chance. Probably easier for you to just raise it now? > >> > >> It's going to be a pretty big round loop to get ios fixes in. It first > needs to go into jfx then needs to be merged into the backport, then that > needs to be deployed to maven, then the maven plugin needs to be updated to > refer to the new version, then the maven plugin needs to be deployed to > maven. > >> > >> I could simplify the last step by allowing the version of jfx backport > to be configurable. > >> > >> As I've raised in previous emails, help would be good. I don't suppose > any oracle people could be allocated to merging changed into the backport > on a regular basis (eg weekly) - even on an unofficial, > non-publicly-commited arrangement? > >> > >> > >> On 09/08/2013, at 7:38 AM, steve.x.northover at oracle.com wrote: > >> > >>> Hi Daniel, > >>> > >>> Did you log a bug for the TextField problem? If you have not done so, > please do. If you use "iOS:" as a prefix for the title of the bug and use > iOS as a label, that should help people find iOS related bugs. I have a > fix for the problem you are seeing. The text skin thinks that because iOS > has touch, it needs to show resize handles in the text field. > >>> > >>> Steve > >>> > >>> On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: > >>>> So now the Maven stuff is working ( > >>>> > http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), > >>>> I'm gradually starting to muck around with the iOS stuff. > >>>> > >>>> There are problems - how do I raise them? Should I log JIRAs? Should I > >>>> bring them up here, etc? Will you guys start running jfx on iOS now > that > >>>> it's possible and are bug fixes within your allowance to work on > given iOS > >>>> is not a supported platform? > >>>> > >>>> For example, in the hello world example, I've included a TextField. > When I > >>>> start typing in it on my iPad the field starts changing size to > accommodate > >>>> the auto-correction popup, which looks very weird. Should I log that > as a > >>>> bug against Controls? > >>> > > > From tobi at ultramixer.com Fri Aug 9 01:13:46 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 9 Aug 2013 10:13:46 +0200 Subject: How to raise JavaFX iOS bugs? In-Reply-To: References: <52040FF0.3020509@oracle.com> <45F53F2D-AF85-406A-AE3D-81029F460EDB@gmail.com> <4E1F265D-071B-4B52-8D15-C8DC4813F4B8@ultramixer.com> <9EC72C94-B439-4FBF-81AD-0FE41E8FF423@gmail.com> Message-ID: <129D4ECC-D1AE-4D27-9469-8174D3A76FAE@ultramixer.com> I absolutely agree! Am 09.08.2013 um 09:17 schrieb Felix Bembrick : > I have a very good feeling about JavaOne this year. It's now or never for Java/JavaFX on mobiles and tablets and judging by the session titles, I think Oracle is going to make a lot of people very happy :-) > > > On 9 August 2013 16:26, Daniel Zwolenski wrote: > Wtf? Oracle guys, what JVM is this session going to use? > > https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=5517 > > > On 09/08/2013, at 3:51 PM, Tobias Bley wrote: > > > Daniel, the question is: Which surprise will Oracle show on JavaOne 2013 in september? Maybe there is something official concerning JavaFX and iOS and Android?? Please take a look a the planned tracks: http://blog.software4java.com/?p=97 > > One track talks about ?JavaSE in AOT mode??so maybe we do not need such a backport in the future? Because Oracle does not say anything about the future, we don?t know it at the moment ;) > > > > Best regards, > > Tobi > > > > > > Am 09.08.2013 um 00:08 schrieb Daniel Zwolenski : > > > >> No, I didn't get a chance. Probably easier for you to just raise it now? > >> > >> It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. > >> > >> I could simplify the last step by allowing the version of jfx backport to be configurable. > >> > >> As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? > >> > >> > >> On 09/08/2013, at 7:38 AM, steve.x.northover at oracle.com wrote: > >> > >>> Hi Daniel, > >>> > >>> Did you log a bug for the TextField problem? If you have not done so, please do. If you use "iOS:" as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. > >>> > >>> Steve > >>> > >>> On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: > >>>> So now the Maven stuff is working ( > >>>> http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), > >>>> I'm gradually starting to muck around with the iOS stuff. > >>>> > >>>> There are problems - how do I raise them? Should I log JIRAs? Should I > >>>> bring them up here, etc? Will you guys start running jfx on iOS now that > >>>> it's possible and are bug fixes within your allowance to work on given iOS > >>>> is not a supported platform? > >>>> > >>>> For example, in the hello world example, I've included a TextField. When I > >>>> start typing in it on my iPad the field starts changing size to accommodate > >>>> the auto-correction popup, which looks very weird. Should I log that as a > >>>> bug against Controls? > >>> > > > From hjohn at xs4all.nl Fri Aug 9 03:23:15 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 09 Aug 2013 12:23:15 +0200 Subject: JavaFX Media issues In-Reply-To: References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> <52044082.30407@xs4all.nl> Message-ID: <5204C313.7090906@xs4all.nl> On 9/08/2013 03:48, Scott Palmer wrote: > I have heard rumors of people being able to play HD video via Canvas. > I have tried everything and can't come close. (Yes, I have been > careful about the pixel format.) I mean, it looks like it is working > for a few seconds, but then as the memory fills with the Canvas > backlog it can lead to the GC using a lot more CPU, thus reducing the > ability for Canvas to process its command queue even further, well it > just collapses in on itself and dies. > Is your app able to do *anything* else while the video is playing? > The slightest delay to the rendering and that Canvas buffering bug > kills the app. Not that it would matter if it could keep up, because > the off-screen thing is also a deal breaker. My app is basically just a video watching system -- while video is playing (in the bottom most layer of a StackPane), it shows overlays with time / position, possibly a menu (where you can download a matching subtitle for the video and adjust settings like playback speed and brightness). These overlays are smoothly faded in / faded out just with the opacity property of another Pane that is at a higher level in the main StackPane. None of this is really CPU intensive, nor is there a huge SceneGraph to deal with (I'm guessing its smaller than 100 nodes while video playback is running). See picture here for an idea of what's going on while playback is occuring: https://github.com/hjohn/MediaSystem/blob/master/screenshot-1.jpg The Stage used is a non-transparent one -- I mention this because a transparent change performs a lot worse than a non-transparent one. Before I used the Canvas solution, I'd actually just playback video in a java.awt.Frame with a transparent JavaFX Stage on top. I'd have 2 windows, with the transparent JavaFX Stage on top that would show overlays for the video, while the other window would show the video using java.awt.Canvas, accessed directly by VLC. I do run into this issue every now and then though: https://javafx-jira.kenai.com/browse/RT-23312 It really needs to be fixed or Canvas is simply not safely usable in its current form (and IMHO never has been since its release then). > Of course 25fps is well below the 60fps required for full-speed video. > I suspect it is the frame rate more than the frame size that matters > here. Plain old, standard definition, interlaced, 60 fields per > second will probably kill most apps with the current Canvas > implementation. I don't think I have aany 60fps video, if you can point me to something I can download that VLC can handle that is of the size you're using I could test with the setup I have here. With 1920x1080 HD Video, the CPU uses 8% according to Task Manager (low-end quad core xeon, about 1 year old). I'm running a standard Java VM (b99), no other tweaking, with default memory settings, 256 MB heap, Task Manager claims a working set of +/- 600 MB, but some native memory might be involved -- when playback stops, working set drops to 340 MB, so there's definitely a lot going on. It's solid though once playback starts (usually it only locks up at the start of playback, if it locks up) and can run for hours. No frame stuttering (I'd notice this immediately on a horizontal pan of one of the test videos I use). Even with a lot of other things going on on the same machine (although not by my Java process) playback stays solid -- I often have this machine running at 50-75% CPU for extended periods while enjoying a Video on the 3rd screen. I'd agree though that more than doubling the frame rate is gonna be a huge impact. I'm not certain if interlaced is going to cause any additional problems, I'm assuming that's handled by VLC and that I'd still be copying a full buffer for each frame (or do you mean 60 FPS interlaced = 120 FPS?). > > We need something better. I proposed having at least a JNI method so > we could get native window handles from Stages but didn't get any > traction either. Security was brought up as a concern, which I > totally do NOT understand as the use of JNI means you are out of the > Java sandbox already. If we had native window handles we might be > able get our own window for rendering to at least interact nicely with > the Stage. (We already did this successfully in Swing via JAWT and a > heavyweight component that we paint to from native code) Getting a WindowHandle for a Stage would be great -- however, I think I actually hacked this in at one point, and then tried playing back video on a JavaFX Stage -- the video however always ended up in the foreground, obliterating any JavaFX rendering. That would need to be solved as well if it is still an issue. I've actually tried almost every video player solution that I could find (all on Windows), including DirectShow (using DSJ), GStreamer-java, MPlayer (in seperate window), VLCJ, MediaPlayer Classic Home Cinema and Xuggler. All of them except VLCJ had severe issues, ranging from simply being immature and crashing (GStreamer-java, MPlayer) to having insufficient accessible controls (DSJ, MediaPlayer Classic) to only being able to play stereo output, no 5.1 etc (Xuggler) or being complicated to use (DSJ mainly (DirectShow sucks), Xuggler somewhat). Best regards, John From hang.vo at oracle.com Fri Aug 9 03:47:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 09 Aug 2013 10:47:59 +0000 Subject: hg: openjfx/8/graphics/rt: Android: RT-32218 Add TextField and TextArea skins for Android. Message-ID: <20130809104910.1E4AE48743@hg.openjdk.java.net> Changeset: 5963868d92d9 Author: tb115823 Date: 2013-08-09 11:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5963868d92d9 Android: RT-32218 Add TextField and TextArea skins for Android. ! build.gradle ! buildSrc/android.gradle + modules/controls/src/android/java/com/sun/javafx/scene/control/skin/TextAreaSkinAndroid.java + modules/controls/src/android/java/com/sun/javafx/scene/control/skin/TextFieldSkinAndroid.java + modules/controls/src/android/resources/com/sun/javafx/scene/control/skin/caspian/android.css + modules/controls/src/android/resources/com/sun/javafx/scene/control/skin/modena/android.css ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java + netbeans/android/controls/build.xml + netbeans/android/controls/manifest.mf + netbeans/android/controls/nbproject/build-impl.xml + netbeans/android/controls/nbproject/genfiles.properties + netbeans/android/controls/nbproject/project.properties + netbeans/android/controls/nbproject/project.xml From sven.ehrke at canoo.com Fri Aug 9 04:18:17 2013 From: sven.ehrke at canoo.com (Sven Ehrke) Date: Fri, 9 Aug 2013 13:18:17 +0200 (CEST) Subject: use custom behavior class for TableView In-Reply-To: <722371871.541993.1376047086491.JavaMail.root@canoo.com> Message-ID: <2118246722.541997.1376047097377.JavaMail.root@canoo.com> Hi, I would like to use a custom Behavior class for a TableView and so I started as usual with a 'MyTableViewSkin' class which I can activate via the css file. In order to reuse functionality of 'TableViewSkin' and 'TableViewBehavior' I started to let ' MyTableViewSkin' inherit from 'TableViewSkin and planned to let it's constructor simply call the super constructor like this: super(tableView, new MyTableViewBehavior(tableView)); Unfortunately 'TableViewSkin' only defines the constructor 'TableViewSkin(final TableView tableView) ' and thus hides the one from ' TableViewSkinBase ' : TableViewSkinBase(final C control, final B behavior) which makes it impossible to call it. Was this done on purpose and if yes how am I supposed to attach a custom behavior class ? Thanks! Regards, Sven From rvjansen at xs4all.nl Fri Aug 9 04:55:46 2013 From: rvjansen at xs4all.nl (=?iso-8859-1?Q?Ren=E9_Jansen?=) Date: Fri, 9 Aug 2013 13:55:46 +0200 Subject: hello and macosx build trouble Message-ID: <7493723D-5370-4D16-A4BE-0E51B3FD6BC6@xs4all.nl> Hello, let me first introduce myself as this is my first post on this list. I am working on integrating jsr223 support in the netrexx 3.03 compiler/interpreter (www.netrexx.org) and I am testing with (apart from netrexx code itself of course) Nashorn and I want to add some examples of how to script JavaFX in addition to using JavaFX in compiled code. For both I need a working JavaFx installation, and I chose the path of building it myself (which most of the time leads to better understanding. I started with building OpenJDK 8, and apart from the need to unset my classpath first (as I found out) and edit the gcc.make file of hotspot, this succeeded. Now I am trying to build OpenJFX. I have gone past the hurdle of the Gradle buiildfile requiring a JDK build number larger than 100 - I set this to 0 and it happily trucks on - but now if have hit a showstopper that I need your help with. These is the complete message stream I receive: ==================== The ConfigurationContainer.add() method has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the create() method instead. :buildSrc:generateGrammarSource UP-TO-DATE :buildSrc:compileJava UP-TO-DATE :buildSrc:compileGroovy UP-TO-DATE :buildSrc:processResources UP-TO-DATE :buildSrc:classes UP-TO-DATE :buildSrc:jar UP-TO-DATE :buildSrc:assemble UP-TO-DATE :buildSrc:compileTestJava UP-TO-DATE :buildSrc:compileTestGroovy UP-TO-DATE :buildSrc:processTestResources UP-TO-DATE :buildSrc:testClasses UP-TO-DATE :buildSrc:test :buildSrc:check :buildSrc:build Missing or incorrect path to 'jfxrt.jar': '/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar'. Perhaps bad JDK_HOME? /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home Unsupported gradle version 1.6 in use. Only 1.4 is supported OS_NAME: mac os x OS_ARCH: x86_64 JAVA_HOME: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home JDK_HOME: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home java.runtime.version: 1.8.0-internal-rvjansen_2013_08_01_16_03-b00 java version: 1.8.0 java build number: 00 minimum java build number: 0 COMPILE_TARGETS: mac COMPILE_FLAGS_FILES: buildSrc/mac.gradle BINARY_STUB: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar HUDSON_JOB_NAME: not_hudson HUDSON_BUILD_NUMBER: 0000 PROMOTED_BUILD_NUMBER: 00 PRODUCT_NAME: OpenJFX RAW_VERSION: 8.0.0 RELEASE_NAME: 8.0 RELEASE_MILESTONE: ea UPDATE_STUB_CACHE: false The CompileOptions.useAnt property has been deprecated and is scheduled to be removed in Gradle 2.0. There is no replacement for this property. :checkJfxrtJar :updateCacheIfNeeded UP-TO-DATE :verifyJava :base:processVersionInfo UP-TO-DATE :base:compileJava UP-TO-DATE :base:processResources UP-TO-DATE :base:classes UP-TO-DATE :base:jar UP-TO-DATE :graphics:compileJava FAILURE: Build failed with an exception. * What went wrong: Could not resolve all dependencies for configuration ':graphics:compile'. > Could not find :plugin:. Required by: rt:graphics:unspecified * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 18.243 secs =============================== OSX is 10.8.4, Xcode is up to date. Anyone able to get me past this? best regards, Ren? Jansen. From felix.bembrick at gmail.com Fri Aug 9 05:45:56 2013 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 9 Aug 2013 22:45:56 +1000 Subject: Mailing list woes Message-ID: I am not sure who this is directed at but there seem to be some glitches in the mailing list software that manages this list. I notice that sometimes when I post to this list I do not always get that message being sent to me via the list so I was wondering if I am actually receiving every message that is posted to the list. I compared notes with a friend of mine who also subscribes to this list and we analysed the posts that we had both received over the past week. To both of our surprise we discovered that I received some posts that he never received and vice versa. There does not appear to be any pattern as to which posts make it into our inboxes and which don't. I'd say we are both receiving about 19 out of every 20 messages or slightly less than that. We definitely established that neither of us has received *every* message sent to the list. We have also all but ruled out spam filter issues as this is my Gmail account and all spam goes into the Spam folder and they certainly haven't been ending up in there. Similarly he has a POP3 account and actually has opted to receive *all* spam sent to him which he then uses an Outlook message rule to place it in his Junk folder. Is anyone else experiencing this? If you are, you probably don't realise it. I only noticed because a couple of my posts didn't come back from the list. Felix From hang.vo at oracle.com Fri Aug 9 06:32:58 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 09 Aug 2013 13:32:58 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130809133356.9B4B94874A@hg.openjdk.java.net> Changeset: 53570eadb90b Author: David Grieve Date: 2013-08-09 09:20 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/53570eadb90b RT-31691: if css is being reapplied but we're using cached values, force a lookup on properties not in the cache ! modules/controls/src/main/java/javafx/scene/control/Control.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: ef2ca9c96bc5 Author: David Grieve Date: 2013-08-09 09:21 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ef2ca9c96bc5 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From jeff at reportmill.com Fri Aug 9 07:03:11 2013 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 9 Aug 2013 09:03:11 -0500 Subject: Mailing list woes In-Reply-To: References: Message-ID: > I only noticed because a couple of my posts didn't come back from the list. I've noticed this, too. Perhaps the list is losing things to a junk filter. jeff On Aug 9, 2013, at 7:45 AM, Felix Bembrick wrote: > I am not sure who this is directed at but there seem to be some glitches in > the mailing list software that manages this list. > > I notice that sometimes when I post to this list I do not always get that > message being sent to me via the list so I was wondering if I am actually > receiving every message that is posted to the list. I compared notes with > a friend of mine who also subscribes to this list and we analysed the posts > that we had both received over the past week. > > To both of our surprise we discovered that I received some posts that he > never received and vice versa. There does not appear to be any pattern as > to which posts make it into our inboxes and which don't. > > I'd say we are both receiving about 19 out of every 20 messages or slightly > less than that. We definitely established that neither of us has received > *every* message sent to the list. > > We have also all but ruled out spam filter issues as this is my Gmail > account and all spam goes into the Spam folder and they certainly haven't > been ending up in there. Similarly he has a POP3 account and actually has > opted to receive *all* spam sent to him which he then uses an Outlook > message rule to place it in his Junk folder. > > Is anyone else experiencing this? If you are, you probably don't realise > it. I only noticed because a couple of my posts didn't come back from the > list. > > Felix From steve.x.northover at oracle.com Fri Aug 9 07:46:32 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 09 Aug 2013 10:46:32 -0400 Subject: How to raise JavaFX iOS bugs? In-Reply-To: <45F53F2D-AF85-406A-AE3D-81029F460EDB@gmail.com> References: <52040FF0.3020509@oracle.com> <45F53F2D-AF85-406A-AE3D-81029F460EDB@gmail.com> Message-ID: <520500C8.2090004@oracle.com> On 08/08/2013 6:08 PM, Daniel Zwolenski wrote: > No, I didn't get a chance. Probably easier for you to just raise it now? See https://javafx-jira.kenai.com/browse/RT-32237 > > It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. > > I could simplify the last step by allowing the version of jfx backport to be configurable. > > As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? > > > On 09/08/2013, at 7:38 AM, steve.x.northover at oracle.com wrote: > >> Hi Daniel, >> >> Did you log a bug for the TextField problem? If you have not done so, please do. If you use "iOS:" as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. >> >> Steve >> >> On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: >>> So now the Maven stuff is working ( >>> http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), >>> I'm gradually starting to muck around with the iOS stuff. >>> >>> There are problems - how do I raise them? Should I log JIRAs? Should I >>> bring them up here, etc? Will you guys start running jfx on iOS now that >>> it's possible and are bug fixes within your allowance to work on given iOS >>> is not a supported platform? >>> >>> For example, in the hello world example, I've included a TextField. When I >>> start typing in it on my iPad the field starts changing size to accommodate >>> the auto-correction popup, which looks very weird. Should I log that as a >>> bug against Controls? From hang.vo at oracle.com Fri Aug 9 07:47:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 09 Aug 2013 14:47:57 +0000 Subject: hg: openjfx/8/graphics/rt: SWT glass: fix defaults to potentially enable live resize on other platforms Message-ID: <20130809144845.5E0834874F@hg.openjdk.java.net> Changeset: 4618b11c75f9 Author: snorthov Date: 2013-08-09 10:43 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4618b11c75f9 SWT glass: fix defaults to potentially enable live resize on other platforms ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java From richard.bair at oracle.com Fri Aug 9 08:23:40 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Aug 2013 08:23:40 -0700 Subject: Canvas blowing up (was Re: JavaFX Media issues) In-Reply-To: References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> <52044082.30407@xs4all.nl> Message-ID: <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> > I mean, it looks like it is working for a few seconds, > but then as the memory fills with the Canvas backlog it can lead to the GC > using a lot more CPU, thus reducing the ability for Canvas to process its > command queue even further, well it just collapses in on itself and dies. Forking the thread. The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. BUT, if you issue a command to the canvas which will cause it to "clear" all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a "clear" method which is "clearRect(0, 0, w, h)" to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. If you're making use of manually operated "dirty rects" so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of "liveness" and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. Richard From richard.bair at oracle.com Fri Aug 9 08:33:12 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Aug 2013 08:33:12 -0700 Subject: Canvas blowing up (was Re: JavaFX Media issues) In-Reply-To: <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> <52044082.30407@xs4all.nl> <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> Message-ID: https://javafx-jira.kenai.com/browse/RT-32242 On Aug 9, 2013, at 8:23 AM, Richard Bair wrote: >> I mean, it looks like it is working for a few seconds, >> but then as the memory fills with the Canvas backlog it can lead to the GC >> using a lot more CPU, thus reducing the ability for Canvas to process its >> command queue even further, well it just collapses in on itself and dies. > > Forking the thread. > > The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. > > BUT, if you issue a command to the canvas which will cause it to "clear" all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. > > This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a "clear" method which is "clearRect(0, 0, w, h)" to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. > > If you're making use of manually operated "dirty rects" so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of "liveness" and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. > > Richard From hang.vo at oracle.com Fri Aug 9 08:33:13 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 09 Aug 2013 15:33:13 +0000 Subject: hg: openjfx/8/graphics/rt: SW pipeline: fix for RT-32227 - setContentWidth + setContentHeight functions on SWTexture Message-ID: <20130809153358.0116B48753@hg.openjdk.java.net> Changeset: 4873e7422e65 Author: Martin Soch Date: 2013-08-09 17:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4873e7422e65 SW pipeline: fix for RT-32227 - setContentWidth + setContentHeight functions on SWTexture ! modules/graphics/src/main/java/com/sun/prism/sw/SWArgbPreTexture.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWMaskTexture.java ! modules/graphics/src/main/java/com/sun/prism/sw/SWTexture.java From richard.bair at oracle.com Fri Aug 9 08:35:05 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Aug 2013 08:35:05 -0700 Subject: JavaFX Media issues In-Reply-To: <6F3F9FEE-58C6-4C75-BDBD-B449E7FB21D5@oracle.com> References: <6F3F9FEE-58C6-4C75-BDBD-B449E7FB21D5@oracle.com> Message-ID: <9EAE3B99-4BBE-4D99-B5DC-B4BA715A90EF@oracle.com> Forwarded from Kiriil Kirichenko who is getting his mailing list credentials sorted out... >> *From: *Felix Bembrick > > >> *Subject: **JavaFX Media issues* >> *Date: *August 8, 2013 1:31:37 PM PDT >> *To: *"openjfx-dev at openjdk.java.net >> List" >> > >> >> I am having a look at JavaFX media support and have a couple of questions: >> >> 1. It seems that the only way to load media files is by specifying a >> source >> such as a file path etc. This is not going to work well for me as all of >> my application's content (which includes data, digital assets, media etc.) >> is stored in a database on the server and is loaded through an IO stream. >> Why doesn't Media support loading of files through a stream? That would >> seem like a common use case to me! This is correct. So called arbitrary input stream support is among the features for the future. >> 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for >> JDK 8 which I found here: >> >> http://download.java.net/jdk8/jfxdocs/index.html >> >> Is this just a glitch? A glitch related to javadoc execution. FXMedia is still there. >> 3. Is buffering of media something planned for the future in JavaFX? What do you mean by buffering ? We have progressive buffer for http links. See MediaPlayer.bufferProgressTimeProperty >> 4. What about live streaming of media content? We support Http Live Streaming: MpegTS which contains H264 + AAC. From richard.bair at oracle.com Fri Aug 9 08:41:52 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Aug 2013 08:41:52 -0700 Subject: Mailing list woes In-Reply-To: References: Message-ID: Maybe the discuss (http://mail.openjdk.java.net/mailman/listinfo/discuss) mailing list is the right place? Richard On Aug 9, 2013, at 5:45 AM, Felix Bembrick wrote: > I am not sure who this is directed at but there seem to be some glitches in > the mailing list software that manages this list. > > I notice that sometimes when I post to this list I do not always get that > message being sent to me via the list so I was wondering if I am actually > receiving every message that is posted to the list. I compared notes with > a friend of mine who also subscribes to this list and we analysed the posts > that we had both received over the past week. > > To both of our surprise we discovered that I received some posts that he > never received and vice versa. There does not appear to be any pattern as > to which posts make it into our inboxes and which don't. > > I'd say we are both receiving about 19 out of every 20 messages or slightly > less than that. We definitely established that neither of us has received > *every* message sent to the list. > > We have also all but ruled out spam filter issues as this is my Gmail > account and all spam goes into the Spam folder and they certainly haven't > been ending up in there. Similarly he has a POP3 account and actually has > opted to receive *all* spam sent to him which he then uses an Outlook > message rule to place it in his Junk folder. > > Is anyone else experiencing this? If you are, you probably don't realise > it. I only noticed because a couple of my posts didn't come back from the > list. > > Felix From steve.x.northover at oracle.com Fri Aug 9 08:43:59 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 09 Aug 2013 11:43:59 -0400 Subject: Canvas blowing up (was Re: JavaFX Media issues) In-Reply-To: <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> <52044082.30407@xs4all.nl> <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> Message-ID: <52050E3F.8020109@oracle.com> This is a great idea. We should just enter a tweak and do it. If the area that is being cleared is larger than the current size of the canvas, we can throw away all pending draw commands. Steve On 09/08/2013 11:23 AM, Richard Bair wrote: >> I mean, it looks like it is working for a few seconds, >> but then as the memory fills with the Canvas backlog it can lead to the GC >> using a lot more CPU, thus reducing the ability for Canvas to process its >> command queue even further, well it just collapses in on itself and dies. > Forking the thread. > > The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. > > BUT, if you issue a command to the canvas which will cause it to "clear" all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. > > This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a "clear" method which is "clearRect(0, 0, w, h)" to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. > > If you're making use of manually operated "dirty rects" so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of "liveness" and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. > > Richard From richard.bair at oracle.com Fri Aug 9 08:47:03 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Aug 2013 08:47:03 -0700 Subject: Mailing list woes In-Reply-To: References: Message-ID: The thing that I'm always burned by is when replies come back out of order. Sometimes I even get my own replies to myself before the original message! On Aug 9, 2013, at 5:45 AM, Felix Bembrick wrote: > I am not sure who this is directed at but there seem to be some glitches in > the mailing list software that manages this list. > > I notice that sometimes when I post to this list I do not always get that > message being sent to me via the list so I was wondering if I am actually > receiving every message that is posted to the list. I compared notes with > a friend of mine who also subscribes to this list and we analysed the posts > that we had both received over the past week. > > To both of our surprise we discovered that I received some posts that he > never received and vice versa. There does not appear to be any pattern as > to which posts make it into our inboxes and which don't. > > I'd say we are both receiving about 19 out of every 20 messages or slightly > less than that. We definitely established that neither of us has received > *every* message sent to the list. > > We have also all but ruled out spam filter issues as this is my Gmail > account and all spam goes into the Spam folder and they certainly haven't > been ending up in there. Similarly he has a POP3 account and actually has > opted to receive *all* spam sent to him which he then uses an Outlook > message rule to place it in his Junk folder. > > Is anyone else experiencing this? If you are, you probably don't realise > it. I only noticed because a couple of my posts didn't come back from the > list. > > Felix From mp at jugs.org Fri Aug 9 09:16:05 2013 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 09 Aug 2013 18:16:05 +0200 Subject: Canvas blowing up (was Re: JavaFX Media issues) In-Reply-To: <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> <52044082.30407@xs4all.nl> <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> Message-ID: <520515C5.1040007@jugs.org> What would be the performance penalty for using this quick-fix? The clear/fill commands do not just clear the command buffer. They also fill the canvas area with a certain color. So in normal operation the canvas is always filled twice for each frame, isn't it? Am 09.08.13 17:23, schrieb Richard Bair: >> I mean, it looks like it is working for a few seconds, >> but then as the memory fills with the Canvas backlog it can lead to the GC >> using a lot more CPU, thus reducing the ability for Canvas to process its >> command queue even further, well it just collapses in on itself and dies. > Forking the thread. > > The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. > > BUT, if you issue a command to the canvas which will cause it to "clear" all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. > > This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a "clear" method which is "clearRect(0, 0, w, h)" to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. > > If you're making use of manually operated "dirty rects" so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of "liveness" and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. > > Richard From swpalmer at gmail.com Fri Aug 9 09:17:37 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 9 Aug 2013 12:17:37 -0400 Subject: Canvas blowing up (was Re: JavaFX Media issues) In-Reply-To: <52050E3F.8020109@oracle.com> References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> <52044082.30407@xs4all.nl> <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> <52050E3F.8020109@oracle.com> Message-ID: That's okay for a quick hack. In the case of a video preview surface, I will be explicitly setting the value for every pixel from a ByteBuffer. You could save the extra step of doing a rectFill or clearRect if you knew that every pixel was about to be overwritten. It's a reasonable optimization.. but as a fix for this issue it's still only a half-fix hack. "If pulses are not happening, we still need to remember these scribbles so we can draw the right result." No. If pulses are not happening you need to block or force a pulse somehow. Otherwise I don't see how having the unbounded queue is ever going to be 100% reliable. Since we are talking about painting to the Canvas surface as opposed to directly modifying the scene graph, why does the painting have to happen "later" when a pulse occurs? It's not like you have any other thread writing to the Canvas. Why can't the Platform thread actually *do* the scribbles,and the pulse just refreshes the portion of the Canvas that is visible on the screen? Is it some D3D/OpenGL multi-threading complication? Regards, Scott On Fri, Aug 9, 2013 at 11:43 AM, wrote: > This is a great idea. We should just enter a tweak and do it. If the > area that is being cleared is larger than the current size of the canvas, > we can throw away all pending draw commands. > > Steve > > > On 09/08/2013 11:23 AM, Richard Bair wrote: > >> I mean, it looks like it is working for a few seconds, >>> but then as the memory fills with the Canvas backlog it can lead to the >>> GC >>> using a lot more CPU, thus reducing the ability for Canvas to process its >>> command queue even further, well it just collapses in on itself and >>> dies. >>> >> Forking the thread. >> >> The problem with Canvas is that if you have a canvas and you scribble on >> it, and then scribble on it some more, and then scribble on it some more, >> then in order for us to get the right result in the end, we need to replay >> all those scribbles in order. If pulses are not happening, we still need to >> remember these scribbles so we can draw the right result. >> >> BUT, if you issue a command to the canvas which will cause it to "clear" >> all its contents, then we could throw away any previously buffered data. >> Right now the only way to do that would be a fillRect with a solid fill >> where the fillRect encompasses the entire canvas area, or a clearRect where >> the clearRect encompasses the entire canvas area. >> >> This seems like a very simple fix. GraphicsContext.clearRect and >> GraphicsContext.fillRect should both (under the right conditions) throw >> away the previously buffered commands. Then all you have to do is be sure >> to make one of these calls (likely just a clearRect) before each frame, and >> we'll never buffer more than a single frame's worth of data. We could also >> add a "clear" method which is "clearRect(0, 0, w, h)" to make this more >> foolproof, and then document it as a best practice to clear the canvas >> before each rendering if you intend to redraw the entire thing on each >> frame. >> >> If you're making use of manually operated "dirty rects" so that you only >> clear the damaged area to repaint, then we couldn't employ this technique >> and we'd have to buffer 'till kingdom come. So we still need a mechanism >> exposed in the scene graph of "liveness" and associated events so that when >> the scene is no longer live (for example, when minimized) you could stop >> your animation timer, but for your specific media use case this isn't as >> important. >> >> Richard >> > > From richard.bair at oracle.com Fri Aug 9 09:30:42 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Aug 2013 09:30:42 -0700 Subject: Canvas blowing up (was Re: JavaFX Media issues) In-Reply-To: References: <2718A715-9B96-455F-9452-6877ABA3B666@oracle.com> <52044082.30407@xs4all.nl> <0A8CF2BB-2364-45AA-9752-A7E182058ADD@oracle.com> <52050E3F.8020109@oracle.com> Message-ID: <6205AFD7-9C5E-4E5E-A142-DACFB54FB386@oracle.com> > That's okay for a quick hack. In the case of a video preview surface, I will be explicitly setting the value for every pixel from a ByteBuffer. You could save the extra step of doing a rectFill or clearRect if you knew that every pixel was about to be overwritten. It's a reasonable optimization.. but as a fix for this issue it's still only a half-fix hack. I wouldn't call it a hack, just an obvious optimization that would happen to help in this case. > "If pulses are not happening, we still need to remember these scribbles so we can draw the right result." > > No. If pulses are not happening you need to block or force a pulse somehow. Otherwise I don't see how having the unbounded queue is ever going to be 100% reliable. I agree it would be better to render the thing. We still need a way to tell people that what they're doing isn't visible so they can stop their timer or whatnot to avoid wasted CPU cycles / battery drain. > Since we are talking about painting to the Canvas surface as opposed to directly modifying the scene graph, why does the painting have to happen "later" when a pulse occurs? It's not like you have any other thread writing to the Canvas. Why can't the Platform thread actually *do* the scribbles,and the pulse just refreshes the portion of the Canvas that is visible on the screen? Is it some D3D/OpenGL multi-threading complication? No doubt drawing to the actual screen in this case won't work (since the surface is likely "lost"), but if we're doing double buffering then we should still be able to draw to the texture. There might be nasty details to work through (windows / graphics guys?). At the high level we short-cut out of doing a pulse if the window is not actually visible so we don't waste CPU resources, but from a high level it would be easy enough to keep track of whether