From guru.hb at oracle.com Thu Oct 1 08:09:55 2015 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 1 Oct 2015 01:09:55 -0700 (PDT) Subject: [9, 8u] review request: 8136466 : [regression] [WebView] Load single page application from jar In-Reply-To: References: Message-ID: <0aa9f5a2-a01a-44ff-81d7-f23b4836197f@default> Hi Kevin / Chien / Alexander, JIRA : https://bugs.openjdk.java.net/browse/JDK-8136466 Webrev : http://cr.openjdk.java.net/~psadhukhan/guru/8136466/webrev.00/ Root cause : Relative url of sub resource which are requested from base url of protocol type "jar:" was missing. Fix : Parse the protocol type of "jar:" and append the baseurl to relative url (Detailed comments updated in JIRA). Please review the fix (comments updated in JIRA). Thanks, Guru From johan.vos at gluonhq.com Thu Oct 1 08:57:09 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 1 Oct 2015 10:57:09 +0200 Subject: freetype glyph Message-ID: I have issues displaying some text with special characters on mobile platforms. The text doesn't appear in a control (e.g. Label), and I saw this in the log output: "Only simple text supported." Searching the source code for this, this occurs in com.sun.javafx.font.freetype.HBGlyphLayout.layout(TextRun run, PGFont font, FontStrike strike, char[] text) { System.out.println("Only simple text supported."); } This method gets called when TextRun.isComplex() returns true for the given TextRun. As a test, I explicitly disallowed this method to return true, thereby preventing the call to HBGlyphLayout.layout(). The special characters are now displayed fine. However, this doesn't sound like a good solution to me. There must be a reason why those characters are rendered differently, and there is also probably a reason why this isn't implemented in the freetype package? Thanks, - Johan From james.graham at oracle.com Thu Oct 1 21:02:27 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 1 Oct 2015 14:02:27 -0700 Subject: RGB and LAB color spaces: Conversion and interpolation In-Reply-To: References: <5605A184.8030209@oracle.com> Message-ID: <560D9F63.5050103@oracle.com> LinearGradient only interpolates in RGB under the covers so it won't help you for interpolating in the other color spaces. The regular Java ColorSpace has built-in support for a couple of color spaces, but their implementations are not in the base classes, they farm out the actual conversions to a plug-in library. If you need other color spaces and can obtain their ICC profile data then you can instantiate any color space from that. If those solutions aren't sufficient then you may have to roll your own (at least for now). I don't think we have a feature request for color space support (beyond the HSB conversions we provide) so you should file one so we can track this issue... ...jim On 9/30/15 2:04 AM, Benjamin Gudehus wrote: > java.awt.color.ColorSpace (and ICC_ColorSpace) only provide an empty > implementation and constants for the conversion between color spaces, > but no specific implementation (at least for HSL, LAB, et cetera). > > Conversion: Interestingly the implementations in the wild rarely > reference the source of the algorithms. So I searched through our > university's library and found different algorithms for HSV, HSL and HSI > (Smith 1978, Metrick 1979, Foley and van Dam 1982, Fishkin 1990, Travis > 1991, Gonzalez and Woods 1992). > > Interpolation: JavaFX has LinearGradient. But it's rather complicated to > retrieve a color ramp from it; we need to fill a Rectangle with a > LinearGradient, make a snapshot and use PixelReader to extract the > integer color values, and the implemention uses some padding for the > colors at start and end. Then the implementation is in > com.sun.prism.impl.paint so I can't access it directly. > > Seems I have to implement this library by myself. > > > > On Fri, Sep 25, 2015 at 9:33 PM, Jim Graham > wrote: > > JavaFX has no color conversion libraries. The classes in > java.awt.color are the only alternative that ships standard with the > JDK... > > ...jim > > > On 9/25/15 7:42 AM, Benjamin Gudehus wrote: > > Hey! > > I want to convert colors between different color spaces and > interpolate > them within the specific color space (sRGB and its cylindrical > transformations HSL/HLS, HSV/HSB, and HSI. LAB and its cylindrical > transformations LCH, and HCL). > > javafx.scene.paint.Color only accepts (s)RGB and HSB and seems > to support > interpolate() within RGB only. Should I use > java.awt.color.ICC_ColorSpace > (which lacks support for HSI, LCH and HCL) or is there a more > complete > library for Java or JavaFX? > > Regards, > Benjamin > > From alexander.matveev at oracle.com Thu Oct 1 21:28:49 2015 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 1 Oct 2015 14:28:49 -0700 Subject: [9] Review request for 8135304: ERROR_MEDIA_INVALID when playing MP4 file Message-ID: <560DA591.2020504@oracle.com> Hi Kirill, https://bugs.openjdk.java.net/browse/JDK-8135304 http://cr.openjdk.java.net/~almatvee/8135304/webrev.00/ This issue affects all MP4 files with header at the end of file and when file is larger then 10 megs. - javasource was not supporting GST_QUERY_SEEKING and thus qtdemux assumed that file is not seekable and thus was not able to find header. - After fixing above file still was not played, because javasource was not able to send NEW SEGMENT after it send EOS. Fixed by flushing source pad on javasource. - Also, we need to clear pending events in progressbuffer when seek is performed, otherwise it breaks playback intermittently by sending wrong sequence of events. Thanks, Alexander From leif.samuelsson at oracle.com Thu Oct 1 23:48:40 2015 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Thu, 1 Oct 2015 16:48:40 -0700 Subject: [8u, 9] Review request: 8136838: [ComboBox, DatePicker] Value doesn't update when focus is lost Message-ID: <560DC658.1010201@oracle.com> Hi Jonathan, Please review this fix for 8u72 and 9. https://bugs.openjdk.java.net/browse/JDK-8136838 http://cr.openjdk.java.net/~leifs/8136838/webrev-8u.00/ http://cr.openjdk.java.net/~leifs/8136838/webrev-9.00/ Thanks, Leif From alexander.matveev at oracle.com Thu Oct 1 23:54:11 2015 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 1 Oct 2015 16:54:11 -0700 Subject: [8u, 9] Review request for 8091132: Support JavaFX MediaPlayer over HTTPS Message-ID: <560DC7A3.5080102@oracle.com> Hi Kirill, https://bugs.openjdk.java.net/browse/JDK-8091132 http://cr.openjdk.java.net/~almatvee/8091132/webrev.00/ Added support for HTTPS. Thanks, Alexander From jonathan.giles at oracle.com Fri Oct 2 01:38:23 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 2 Oct 2015 14:38:23 +1300 Subject: Focus Traversal API for JDK 9 Message-ID: <560DE00F.1070609@oracle.com> Hi folks. I'm continuing along with working on a few small API additions for JDK 9 to smooth off some of the rough edges due to Jigsaw modularity. Today there is a relatively big API to discuss - focus traversal. In summary, my plan is to essentially bring forward the focus traversal API out of com.sun.javafx.scene.traversal and move it to javafx.scene.traversal. I have done that on my machine, and along with a few cleanups to reduce the API surface area and to clarify some generic class names, it is ready for review. This isn't to say it is final, or even guaranteed to go in to JDK 9, but I wanted to get your thoughts on it so that we can move forward with the javadoc effort, etc. The JavaDoc that you see presently is unchanged from what was there previously, so a major task still to do is to fully document the new API. If it proves contentious, the likely plan would be to return to this again after JavaOne, and if things can't be resolved it might not make it into JDK 9. I've uploaded the latest javadocs for this API to my website, which you can see here: http://jonathangiles.net/javafx/jdk9/traversal/ Any thoughts you have would be welcome! Thanks, -- Jonathan From martin.sladecek at oracle.com Fri Oct 2 06:04:20 2015 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Fri, 02 Oct 2015 08:04:20 +0200 Subject: Focus Traversal API for JDK 9 In-Reply-To: <560DE00F.1070609@oracle.com> References: <560DE00F.1070609@oracle.com> Message-ID: <560E1E64.8070304@oracle.com> Hi Jonathan, just a few thoughts about the API. When I was adding some of the functionality to traversal, I could not touch the public API. All we had there was the impl_ method for adding TraversalEngine. This means there is some functionality that IMO should have been directly in the scenegraph. First of all, the TraversalEngine serves for 2 different purposes: 1) overriding traversal algorithm for the given subtree 2) adding listener to the subtree. I think only the #1 should be really part of the TraversalEngine. It would be better to register listeners directly on the scene/parent. This would simplify the code as currently there are engines that are really just a containers for listeners and they need to be special-cased. The setOverriddenFocusTraversability/ isParentTraversable is there just for Toggle button traversability ( RT-36659). I don't think this should be part of the public API. This basically switches off the traversability of unselected nodes that are part of a Toggle group, so that only the selected one can be traversed to. The ParentTraversalEngine is misused there just mark the node has overridden traversability. I'm not sure how to replace it though. Too bad that Toggle/ToggleGroup is in control and traversal engine does not know about it, so it cannot check for it. This might be possibly marked by a property (?) directly on the node? It would be kind-of a property intended to be used by controls and not by the user, as the user already has his ways to control the focus. Anybody has a better idea here? Also, TopMostTraversalEngine probably shouldn't be exposed, unless there's public Scene property for it. This would allow to change the default algorithm for the Scene (one that can be then accessed in TraversalContext). The constructor for this is missing (still package-private) however. If you want this functionality, you should probably publish also (Sub)SceneTraversalEngine. If not, TopMostTraversalEngine is useless and may stay in the private API space. Cheers, -Martin On 2.10.2015 03:38, Jonathan Giles wrote: > Hi folks. > > I'm continuing along with working on a few small API additions for JDK > 9 to smooth off some of the rough edges due to Jigsaw modularity. > Today there is a relatively big API to discuss - focus traversal. > > In summary, my plan is to essentially bring forward the focus > traversal API out of com.sun.javafx.scene.traversal and move it to > javafx.scene.traversal. I have done that on my machine, and along with > a few cleanups to reduce the API surface area and to clarify some > generic class names, it is ready for review. This isn't to say it is > final, or even guaranteed to go in to JDK 9, but I wanted to get your > thoughts on it so that we can move forward with the javadoc effort, > etc. The JavaDoc that you see presently is unchanged from what was > there previously, so a major task still to do is to fully document the > new API. > > If it proves contentious, the likely plan would be to return to this > again after JavaOne, and if things can't be resolved it might not make > it into JDK 9. > > I've uploaded the latest javadocs for this API to my website, which > you can see here: > http://jonathangiles.net/javafx/jdk9/traversal/ > > Any thoughts you have would be welcome! > Thanks, > -- Jonathan From jonathan.giles at oracle.com Fri Oct 2 06:09:20 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 02 Oct 2015 19:09:20 +1300 Subject: Focus Traversal API for JDK 9 In-Reply-To: <560E1E64.8070304@oracle.com> References: <560DE00F.1070609@oracle.com> <560E1E64.8070304@oracle.com> Message-ID: Thanks so much for chiming in here Martin! For those who don't know, focus traversal used to be one of Martin's many APIs that he used to own, so he knows it in great depth. Martin, I'll parse and work through your sage advice as soon as possible. If you have any further advice for your old API, I am all ears. Thanks a lot, -- Jonathan Sent from a touch device. Please excuse my brevity. On 2 October 2015 19:04:20 GMT+13:00, Martin Sladecek wrote: >Hi Jonathan, >just a few thoughts about the API. > >When I was adding some of the functionality to traversal, I could not >touch the public API. All we had there was the impl_ method for adding >TraversalEngine. This means there is some functionality that IMO should > >have been directly in the scenegraph. > >First of all, the TraversalEngine serves for 2 different purposes: 1) >overriding traversal algorithm for the given subtree 2) adding listener > >to the subtree. >I think only the #1 should be really part of the TraversalEngine. It >would be better to register listeners directly on the scene/parent. >This >would simplify the code as currently there are engines that are really >just a containers for listeners and they need to be special-cased. > >The setOverriddenFocusTraversability/ isParentTraversable is there just > >for Toggle button traversability ( RT-36659). I don't think this should > >be part of the public API. This basically switches off the >traversability of unselected nodes that are part of a Toggle group, so >that only the selected one can be traversed to. The >ParentTraversalEngine is misused there just mark the node has >overridden >traversability. I'm not sure how to replace it though. Too bad that >Toggle/ToggleGroup is in control and traversal engine does not know >about it, so it cannot check for it. This might be possibly marked by a > >property (?) directly on the node? It would be kind-of a property >intended to be used by controls and not by the user, as the user >already >has his ways to control the focus. >Anybody has a better idea here? > >Also, TopMostTraversalEngine probably shouldn't be exposed, unless >there's public Scene property for it. This would allow to change the >default algorithm for the Scene (one that can be then accessed in >TraversalContext). The constructor for this is missing (still >package-private) however. If you want this functionality, you should >probably publish also (Sub)SceneTraversalEngine. If not, >TopMostTraversalEngine is useless and may stay in the private API >space. > >Cheers, >-Martin > > >On 2.10.2015 03:38, Jonathan Giles wrote: >> Hi folks. >> >> I'm continuing along with working on a few small API additions for >JDK >> 9 to smooth off some of the rough edges due to Jigsaw modularity. >> Today there is a relatively big API to discuss - focus traversal. >> >> In summary, my plan is to essentially bring forward the focus >> traversal API out of com.sun.javafx.scene.traversal and move it to >> javafx.scene.traversal. I have done that on my machine, and along >with >> a few cleanups to reduce the API surface area and to clarify some >> generic class names, it is ready for review. This isn't to say it is >> final, or even guaranteed to go in to JDK 9, but I wanted to get your > >> thoughts on it so that we can move forward with the javadoc effort, >> etc. The JavaDoc that you see presently is unchanged from what was >> there previously, so a major task still to do is to fully document >the >> new API. >> >> If it proves contentious, the likely plan would be to return to this >> again after JavaOne, and if things can't be resolved it might not >make >> it into JDK 9. >> >> I've uploaded the latest javadocs for this API to my website, which >> you can see here: >> http://jonathangiles.net/javafx/jdk9/traversal/ >> >> Any thoughts you have would be welcome! >> Thanks, >> -- Jonathan From info at cuhka.com Fri Oct 2 13:43:13 2015 From: info at cuhka.com (info at cuhka.com) Date: Fri, 02 Oct 2015 13:43:13 +0000 Subject: OSGi bundle reloading and "Application launch must not be called more than once" Message-ID: <20151002134313.Horde.CqjGKKcfqADCUQ6o8U43ow1@dime187.dizinc.com> I'm using OSGi (Apache Felix) to develop my application. The bundle's activator is as follows: @Override public void start(BundleContext context) throws Exception { new Thread(() -> Application.launch(Desktop.class), "JavaFX Desktop launcher").start(); } @Override public void stop(BundleContext context) throws Exception { Platform.exit(); } The new Thread() is because Application.launch blocks the thread (can it be avoided?). However, the main problem is when I stop a bundle, do an update and try to start it again. Unless I quit the entire OSGi container I get the following stacktrace: g! Exception in thread "JavaFX Desktop launcher" java.lang.IllegalStateException: Application launch must not be called more than once at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:162) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:143) at javafx.application.Application.launch(Application.java:191) While I understand this in a regular situation, it is kind of annoying in a environment such as OSGi. I would have thought that calling Platform.exit() in the activator's stop() method would have done the trick, but obviously it doesn't. Is there a way to completely stop the JavaFX framework in the stop() method so that a subsequent call to start() will be capable of starting a new application? From vadim.pakhnushev at oracle.com Fri Oct 2 15:45:00 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 2 Oct 2015 18:45:00 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <560EA67C.5080004@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From David.Hill at Oracle.com Mon Oct 5 15:24:39 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 05 Oct 2015 11:24:39 -0400 Subject: review: InvokeLaterDispatcher should set thread name Message-ID: <56129637.5000801@Oracle.com> Kevin, A good suggestion came in: InvokeLaterDispatcher should set thread name This will help debugging. JBS: https://bugs.openjdk.java.net/browse/JDK-8138853 a one line fix: ddhill at ddhlinux:~/sb/9/graphics/rt$ hg qdiff diff -r 1909f0a4308f modules/graphics/src/main/java/com/sun/glass/ui/InvokeLaterDispatcher.java --- a/modules/graphics/src/main/java/com/sun/glass/ui/InvokeLaterDispatcher.java Fri Oct 02 16:17:17 2015 -0700 +++ b/modules/graphics/src/main/java/com/sun/glass/ui/InvokeLaterDispatcher.java Mon Oct 05 11:12:03 2015 -0400 @@ -68,6 +68,7 @@ private final InvokeLaterSubmitter invokeLaterSubmitter; public InvokeLaterDispatcher(InvokeLaterSubmitter invokeLaterSubmitter) { + super("InvokeLaterDispatcher"); setDaemon(true); this.invokeLaterSubmitter = invokeLaterSubmitter; -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From john2011uk at gmail.com Mon Oct 5 15:34:44 2015 From: john2011uk at gmail.com (John Maton) Date: Mon, 5 Oct 2015 17:34:44 +0200 Subject: WebView and Javascript event listeners Message-ID: In a WebView application is there any reliable method to determe when a Flash video has attempted to run and failed? I want to be able to detect that condition, inform the user and optionally run alternative resources when that occurs. I have tried analysing the data provided by all WebEngine listeners (change of state, location change, etc, etc), I have tried embedding code in javascript to listen for other events but no luck so far. Any comments/ideas would be greatly appreciated. John Maton From kevin.rushforth at oracle.com Mon Oct 5 19:59:33 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 05 Oct 2015 12:59:33 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <5612D6A5.30203@oracle.com> From leif.samuelsson at oracle.com Tue Oct 6 01:45:21 2015 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Mon, 5 Oct 2015 18:45:21 -0700 Subject: [9] Review request for 8088397: [Dialog] ButtonType text not updated when Locale changes Message-ID: <561327B1.5000409@oracle.com> Hi Jonathan, https://bugs.openjdk.java.net/browse/JDK-8088397 http://cr.openjdk.java.net/~leifs/8088397/webrev.00/ Thanks, Leif From johan.vos at gluonhq.com Tue Oct 6 08:02:43 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 6 Oct 2015 10:02:43 +0200 Subject: Scroll Gesture in ListView Message-ID: I have the following issue: Scrolling with inertia, initiated by a ScrollGesture, stops after a while in a ListView. The reason for this is the following: the javadoc for ScrollEvent has this: The event is delivered to the top-most node picked on the gesture coordinates in time of the gesture start - the whole gesture is delivered to the same node even if the coordinates change during the gesture. Looking into the code, this is indeed what happens: when a SCROLL_STARTED is received, the targetNode is picked, and this is then used as the first one in the dispatchchain for the remainder of the scroll event (even after SCROLL_FINISHED occurred). But the inertia scrolling causes new SCROLL events to be generated after the SCROLL_FINISHED, and it will cause the ListView to scroll its items. The initially selected cell might be reclaimed (or its contents are not shown in the ListTile anymore, as this is re-used for other content). In that case, the dispatch chain is broken, as the targetNode.getParent() will return null, and the scroll event is never passed to the ListView. There are a number of potentials solutions to this problem. Re-calculating the pickedTarget on every SCROLL event seems not a good solution to me (what are the pick coordinates after the touchpoint has been released? It will slow down performance as well). Rather, it would be better if somehow the pickedTarget for these events is the ListView itself, and not one of its cells. We can already do this by setting the ListCell and its content to mouseTransparent, but that will make them unavailable for mouseClick events as well. So it seems to me we need something like "gestureTransparent", by which we can indicate a Node not to be interested in handling gestures. The code for picking the target Node currently ignores the Node if it has the mouseTransparent set. I would propose to add a gestureTransparent property on Node, and to add the following check: if we need to find the pickedTarget for a gestureEvent, it should never return a node with gestureTransparent set to true. This would require a change in Scene.ScenePeerListener.scrollEvent() where the ScrollEvent is created, and where the pickTarget is computed by pick(x,y) which only ignores mouseTransparent nodes at the moment. Should I file an issue for this? - Johan From hastebrot at gmail.com Tue Oct 6 13:30:09 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 6 Oct 2015 15:30:09 +0200 Subject: Usage of Toolkit firePulse In-Reply-To: References: <56033A89.5050600@oracle.com> Message-ID: Hi Ryan, I've created an issue for that. https://github.com/TestFX/TestFX/issues/231 Will try you example out. --Benjamin On Tue, Sep 29, 2015 at 2:58 AM, Ryan Jaeb wrote: > Hi Benjamin, > > Yes, it's a NoNodesFoundException using TestFX 3.1.2. > > As far as I know, using firePulse() is the only way to guarantee all > previous model changes are rendered in the scene. I've created an example > to show what I mean: > > https://gist.github.com/ryanjaeb/74685a002e2b402e7fac > > It's a small example, so I'll post it inline too: > > ... > public class FirePulseApplication extends Application { > @Override > public void start(Stage primaryStage) throws Exception { > printEnv(); > > ListView listView = new ListView<>(); > > Scene scene = new Scene(listView, 200, 400); > primaryStage.setScene(scene); > primaryStage.show(); > > for (int i = 1; i < 6; i++) { > listView.getItems().add("list-item-" + i); > } > > System.out.println("Before firePulse():"); > printVisibleRowInfo(listView); > > Toolkit.getToolkit().firePulse(); > > System.out.println("After firePulse():"); > printVisibleRowInfo(listView); > > Platform.exit(); > } > > private void printVisibleRowInfo(ListView listView) { > // Item count according to the list model > System.out.println(" Item count: " + listView.getItems().size()); > > // Extract the VirtualFlow so it can be used to determine which > // list items are rendered in the scene. > ObservableList children = listView.getChildrenUnmodifiable(); > VirtualFlow flow = (VirtualFlow) children.get(0); > > IndexedCell firstCell = flow.getFirstVisibleCell(); > System.out.println(" First visible cell: " + firstCell); > > IndexedCell lastCell = flow.getLastVisibleCell(); > System.out.println(" Last visible cell: " + lastCell); > } > > private void printEnv() { > String osName = System.getProperty("os.name"); > String jvm = System.getProperty("java.version") + > " (" + System.getProperty("java.vm.version") + > " - " + System.getProperty("os.arch") + ")"; > > System.out.println("OS: " + osName); > System.out.println("JVM: " + jvm); > System.out.println(""); > } > } > ... > > The output I get when running the example: > > ... > OS: Windows 8.1 > JVM: 1.8.0_40 (25.40-b25 - amd64) > > Before firePulse(): > Item count: 5 > First visible cell: null > Last visible cell: null > After firePulse(): > Item count: 5 > First visible cell: ListViewSkin$2 at 7820053f[styleClass=cell > indexed-cell list-cell]'list-item-1' > Last visible cell: ListViewSkin$2 at 8be9262[styleClass=cell indexed-cell > list-cell]'list-item-5' > ... > > Until there's a pulse, the nodes that represent the list items don't > exist, so the NoNodesFoundException is expected. > > Ryan > > On Sun, Sep 27, 2015 at 12:40 AM, Benjamin Gudehus > wrote: > >> Hi Ryan! >> >> >Otherwise the drag(...) command will throw an exception because it >> can't find the node for "list-item-name" (it doesn't exist yet). >> >> Well, this is very interesting. This must be a NoNodesFoundException in >> TestFX 3. >> >> >I don't actually needto call firePulse(). I just need a way to know the >> scene is up to date with a re-validated model. Is there a better way of >> accomplishing that right now? >> >> TestFX should try to find the Node within the JavaFX Application Thread >> using Platform.runLater(...). Maybe this is a better way than to call >> firePulse(), >> >> --Benjamin >> >> On Thu, Sep 24, 2015 at 12:49 PM, Ryan Jaeb wrote: >> >>> I use firePulse() in GUI test code. I'm using TestFX (v3) for testing. >>> Is >>> there a way to ensure model updates are reflected in the scene without >>> using firePulse()? Consider something like this: >>> >>> ... >>> // TestFX starts us on the main thread. Maybe I'm using it wrong? >>> >>> CountDownLatch latch = new CountDownLatch(1); >>> >>> Platform.runLater(() -> { >>> // Add "list-item-name" to an empty list that's used as the model for >>> // a ListView. >>> Toolkit.getToolkit().firePulse(); >>> latch.countDown(); >>> }); >>> >>> try { >>> latch.await(1, TimeUnit.SECONDS); >>> } >>> catch (InterruptedException e) { >>> throw new RuntimeException(e); >>> } >>> >>> // TestFX runs this on the application thread. >>> drag("list-item-name").to("trash"); >>> >>> assertTrue(list.isEmpty); >>> ... >>> >>> In a case like the above, firePulse() is used to ensure a node (ListCell) >>> for "list-item-name" is added to the scene before continuing with the >>> test. Otherwise the drag(...) command will throw an exception because it >>> can't find the node for "list-item-name" (it doesn't exist yet). >>> >>> I don't actually needto call firePulse(). I just need a way to know the >>> scene is up to date with a re-validated model. Is there a better way of >>> accomplishing that right now? >>> >>> Ryan >>> >>> >>> On Wed, Sep 23, 2015 at 5:49 PM, Jonathan Giles < >>> jonathan.giles at oracle.com> >>> wrote: >>> >>> > Hi all, >>> > >>> > Today I am keen to get your help on understanding use of the >>> > Toolkit.getToolkit().firePulse() private API. If you could spare a few >>> > minutes to grep your source directory for any usage of 'firePulse', and >>> > email me your findings, that would be really interesting. >>> > >>> > As a gentle motivational tool I'll conclude by saying that, >>> surprisingly, >>> > this private API is barely used inside the openjfx production code. If >>> you >>> > look at the openjfx unit tests, it is used massively. The question is >>> - how >>> > much is this being used by other community members. If the answer is >>> 'not >>> > much' or less, then this private API may not be made public in JDK 9. >>> Your >>> > feedback therefore is critical! >>> > >>> > Thanks, >>> > -- Jonathan >>> > >>> >> >> > From rahman.usta.88 at gmail.com Tue Oct 6 19:27:27 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Tue, 6 Oct 2015 22:27:27 +0300 Subject: Process manager already initialized: can't fully enable headless mode Message-ID: Hello; Some of Mac users are facing with following problem. What can be the reason? Thanks. Hello I have Software OS X 10.8.5 (12F2560) Java 8 U 60 I just have installed the AsciidocFX v1.3.8 for Mac When I open/execute the program I can see the main window just one second and it crash, the app is still running, immediately for few seconds below in the dock an icon about Updater appears and disappears. If I open the app through a terminal, no error message appears. But using or checking the Console -> system.log, I can see the following: JavaApplicationStub[261]: [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode. JavaApplicationStub[261]: *** -[__NSArrayM insertObject:atIndex:]: object cannot be nil JavaApplicationStub[261]: ( 0 CoreFoundation 0x00007fff8da96b06 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff880983f0 objc_exception_throw + 43 2 CoreFoundation 0x00007fff8da4727a -[__NSArrayM insertObject:atIndex:] + 282 3 AppKit 0x00007fff892f9794 -[NSMenu insertItem:atIndex:] + 505 4 libawt_lwawt.dylib 0x000000012cc435e7 addMenuItem + 185 5 libawt_lwawt.dylib 0x000000012cc42f54 -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 6 libawt_lwawt.dylib 0x000000012cc43179 __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 + 159 7 JavaNativeFoundation 0x00000001007f15f5 +[JNFRunLoop _performCopiedBlock:] + 20 8 Foundation 0x00007fff8e25b59a __NSThreadPerformPerform + 225 9 CoreFoundation 0x00007fff8da15b31 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 10 CoreFoundation 0x00007fff8da1551d __CFRunLoopDoSources0 + 445 11 CoreFoundation 0x00007fff8da387f5 __CFRunLoopRun + 789 12 CoreFoundation 0x00007fff8da380e2 CFRunLoopRunSpecific + 290 13 HIToolbox 0x00007fff8b412eb4 RunCurrentEventLoopInMode + 209 14 HIToolbox 0x00007fff8b412b94 ReceiveNextEventCommon + 166 15 HIToolbox 0x00007fff8b412ae3 BlockUntilNextEventMatchingListInMode + 62 16 AppKit 0x00007fff89307533 _DPSNextEvent + 685 17 AppKit 0x00007fff89306df2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 18 AppKit 0x00007fff892fe1a3 -[NSApplication run] + 517 19 libglass.dylib 0x000000011e2c15ec -[GlassApplication runLoop:] + 1836 20 Foundation 0x00007fff8e25b59a __NSThreadPerformPerform + 225 21 CoreFoundation 0x00007fff8da15b31 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 22 CoreFoundation 0x00007fff8da15455 __CFRunLoopDoSources0 + 245 23 CoreFoundation 0x00007fff8da387f5 __CFRunLoopRun + 789 24 CoreFoundation 0x00007fff8da380e2 CFRunLoopRunSpecific + 290 25 libjli.dylib 0x00000001000f28fb CreateExecutionEnvironment + 871 26 libjli.dylib 0x00000001000ee644 JLI_Launch + 1952 27 JavaApplicationStub 0x0000000100006e98 -[Launcher launch] + 872 28 JavaApplicationStub 0x00000001000075b5 launcher_main + 645 29 JavaApplicationStub 0x0000000100007722 main + 34 30 JavaApplicationStub 0x0000000100001854 start + 52 ) ?. more CGXDisableUpdate: UI updates were forcibly disabled by application "AsciidocFX" for over 1.00 seconds. Server has re-enabled them. WindowServer[76]: disable_update_likely_unbalanced: UI updates still disabled by application "AsciidocFX" after 15.00 seconds (server forcibly re-enabled them after 1.00 seconds). Likely an unbalanced disableUpdate call. What is wrong? Thanks From sselvia at gmail.com Wed Oct 7 19:22:28 2015 From: sselvia at gmail.com (Scott Selvia) Date: Wed, 7 Oct 2015 15:22:28 -0400 Subject: Windows Store App Package Enhancment Message-ID: I would like to request an enhancement to have the packager support a Windows Store application bundle as it currently supports the Mac App store package process. I ask this question without checking the code availability, is the packager code open sourced for others to contribute? It would be really nice to automate the windows store code process, it is not that dissimilar (makeappx, having an appxmanifest.xml (aka entitlements), sign tool, etc..) Thanks, Scott From danno.ferrin at oracle.com Wed Oct 7 19:40:42 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Wed, 7 Oct 2015 13:40:42 -0600 Subject: Windows Store App Package Enhancment In-Reply-To: References: Message-ID: <13BD5A4D-3B54-4ADB-A40C-CD7FFC6CE1D4@oracle.com> > On Oct 7, 2015, at 1:22 PM, Scott Selvia wrote: > > I would like to request an enhancement to have the packager support a Windows Store application bundle as it currently supports the Mac App store package process. > > I ask this question without checking the code availability, is the packager code open sourced for others to contribute? The source code is all GPL+Classpath: The current released code is http://hg.openjdk.java.net/openjfx/8u-dev/rt/ and the main packager bits are here http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/761213753af4/modules/fxpackager . I'm working on some jigsaw updates and the will be here when ready: http://hg.openjdk.java.net/openjfx/sandbox-9-jake/ > It would be really nice to automate the windows store code process, it is not that dissimilar (makeappx, having an appxmanifest.xml (aka entitlements), sign tool, etc..) The main problem is a very basic on. I haven't checked the Windows 10 store, but in the windows 8 and Windows 8.1 timeframe all windows app store apps had to be WinRT applications, and Java is Win32. I think WinRT has been re-named to be Universal Applications. The problem is very deep, however. One of the key constraints of WinRT was that like iOS you were prohibited from generating code and running it from the same app. (technically you couldn't flip the NX bit on any pages to change them from data to code). This is Java and the HotSpot VM's modus operandi, to take java byte code, create native code, and flip the MX bit. It can run in all-interpreted mode but that is orders of magnitude slower. So there is a whole lot more to a windows store installer than looks like initially, and it has little to do with packaging. --Danno From felix.bembrick at gmail.com Wed Oct 7 21:11:23 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 8 Oct 2015 08:11:23 +1100 Subject: Java & JavaFX on mobiles Message-ID: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> The world of Java and JavaFX is growing more confusing than ever it seems. Some say Oracle is cutting back on funding for Java because it is effectively helping its competitors. Sounds similar to Google forking WebKit so they weren't writing code for Apple. But now we hear of the looming release of official JDKs for iOS and Android from Oracle. Will these JDKs be the best and simplest way of running JavaFX on those platforms? Without JIT support, will these JDKs support AOT compiling? Do the proposed JDKs for mobiles even include JavaFX? Felix From steve at weblite.ca Wed Oct 7 21:19:02 2015 From: steve at weblite.ca (Steve Hannah) Date: Wed, 7 Oct 2015 14:19:02 -0700 Subject: Java & JavaFX on mobiles In-Reply-To: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> References: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> Message-ID: I recall reading that these JDKs won't include any UI components. Since iOS doesn't support JIT, the iOS port of JDK will certainly be AOT compiling. On Wed, Oct 7, 2015 at 2:11 PM, Felix Bembrick wrote: > The world of Java and JavaFX is growing more confusing than ever it seems. > > Some say Oracle is cutting back on funding for Java because it is > effectively helping its competitors. Sounds similar to Google forking > WebKit so they weren't writing code for Apple. > > But now we hear of the looming release of official JDKs for iOS and > Android from Oracle. > > Will these JDKs be the best and simplest way of running JavaFX on those > platforms? Without JIT support, will these JDKs support AOT compiling? > > Do the proposed JDKs for mobiles even include JavaFX? > > Felix -- Steve Hannah Web Lite Solutions Corp. From felix.bembrick at gmail.com Wed Oct 7 21:21:42 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 8 Oct 2015 08:21:42 +1100 Subject: Java & JavaFX on mobiles In-Reply-To: References: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> Message-ID: What would be the reason/logic for not including JavaFX in these JDKs? > On 8 Oct 2015, at 08:19, Steve Hannah wrote: > > I recall reading that these JDKs won't include any UI components. Since iOS doesn't support JIT, the iOS port of JDK will certainly be AOT compiling. > >> On Wed, Oct 7, 2015 at 2:11 PM, Felix Bembrick wrote: >> The world of Java and JavaFX is growing more confusing than ever it seems. >> >> Some say Oracle is cutting back on funding for Java because it is effectively helping its competitors. Sounds similar to Google forking WebKit so they weren't writing code for Apple. >> >> But now we hear of the looming release of official JDKs for iOS and Android from Oracle. >> >> Will these JDKs be the best and simplest way of running JavaFX on those platforms? Without JIT support, will these JDKs support AOT compiling? >> >> Do the proposed JDKs for mobiles even include JavaFX? >> >> Felix > > > > -- > Steve Hannah > Web Lite Solutions Corp. From donald.smith at oracle.com Wed Oct 7 21:21:48 2015 From: donald.smith at oracle.com (Donald Smith) Date: Wed, 7 Oct 2015 17:21:48 -0400 Subject: Java & JavaFX on mobiles In-Reply-To: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> References: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> Message-ID: <56158CEC.5030207@oracle.com> There is no "official JDKs for iOS and Android", and anyone that tries to spin the recent OpenJDK project announcement as such is likely just trying to consume you as click-bait. The recent project announcement is simply to make internal code we have for some of our other commercial products available to those who may wish to use it (and therefore we hopefully benefit from any contributions back). That's it. It won't be released as part of the Oracle JDK. It's just some source, for OpenJDK. - Don On 07/10/2015 5:11 PM, Felix Bembrick wrote: > The world of Java and JavaFX is growing more confusing than ever it seems. > > Some say Oracle is cutting back on funding for Java because it is effectively helping its competitors. Sounds similar to Google forking WebKit so they weren't writing code for Apple. > > But now we hear of the looming release of official JDKs for iOS and Android from Oracle. > > Will these JDKs be the best and simplest way of running JavaFX on those platforms? Without JIT support, will these JDKs support AOT compiling? > > Do the proposed JDKs for mobiles even include JavaFX? > > Felix From donald.smith at oracle.com Wed Oct 7 21:24:13 2015 From: donald.smith at oracle.com (Donald Smith) Date: Wed, 7 Oct 2015 17:24:13 -0400 Subject: Java & JavaFX on mobiles In-Reply-To: References: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> Message-ID: <56158D7D.7080906@oracle.com> JavaFX is already 100% open source. It can be used with the code that will be contributed when the proposed OpenJDK project is approved. These are not orthogonal in any way. - Don On 07/10/2015 5:21 PM, Felix Bembrick wrote: > What would be the reason/logic for not including JavaFX in these JDKs? > >> On 8 Oct 2015, at 08:19, Steve Hannah wrote: >> >> I recall reading that these JDKs won't include any UI components. Since iOS doesn't support JIT, the iOS port of JDK will certainly be AOT compiling. >> >>> On Wed, Oct 7, 2015 at 2:11 PM, Felix Bembrick wrote: >>> The world of Java and JavaFX is growing more confusing than ever it seems. >>> >>> Some say Oracle is cutting back on funding for Java because it is effectively helping its competitors. Sounds similar to Google forking WebKit so they weren't writing code for Apple. >>> >>> But now we hear of the looming release of official JDKs for iOS and Android from Oracle. >>> >>> Will these JDKs be the best and simplest way of running JavaFX on those platforms? Without JIT support, will these JDKs support AOT compiling? >>> >>> Do the proposed JDKs for mobiles even include JavaFX? >>> >>> Felix >> >> >> -- >> Steve Hannah >> Web Lite Solutions Corp. From richard.bair at oracle.com Wed Oct 7 21:25:36 2015 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 7 Oct 2015 14:25:36 -0700 Subject: Java & JavaFX on mobiles In-Reply-To: <56158CEC.5030207@oracle.com> References: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> <56158CEC.5030207@oracle.com> Message-ID: <79D73358-8F47-4694-A5FF-ABDFD2D78A16@oracle.com> Donald, do you know if the iOS version has the JIT compiler? I know Apple reduced the restriction for some cases, but I can?t remember if it applied to us or not. Or is the VM on iOS interpreter only? Richard > On Oct 7, 2015, at 2:21 PM, Donald Smith wrote: > > There is no "official JDKs for iOS and Android", and anyone that tries to spin the recent OpenJDK project announcement as such is likely just trying to consume you as click-bait. The recent project announcement is simply to make internal code we have for some of our other commercial products available to those who may wish to use it (and therefore we hopefully benefit from any contributions back). That's it. It won't be released as part of the Oracle JDK. It's just some source, for OpenJDK. > > - Don > > On 07/10/2015 5:11 PM, Felix Bembrick wrote: >> The world of Java and JavaFX is growing more confusing than ever it seems. >> >> Some say Oracle is cutting back on funding for Java because it is effectively helping its competitors. Sounds similar to Google forking WebKit so they weren't writing code for Apple. >> >> But now we hear of the looming release of official JDKs for iOS and Android from Oracle. >> >> Will these JDKs be the best and simplest way of running JavaFX on those platforms? Without JIT support, will these JDKs support AOT compiling? >> >> Do the proposed JDKs for mobiles even include JavaFX? >> >> Felix > From donald.smith at oracle.com Wed Oct 7 21:43:59 2015 From: donald.smith at oracle.com (Donald Smith) Date: Wed, 7 Oct 2015 17:43:59 -0400 Subject: Java & JavaFX on mobiles In-Reply-To: <79D73358-8F47-4694-A5FF-ABDFD2D78A16@oracle.com> References: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> <56158CEC.5030207@oracle.com> <79D73358-8F47-4694-A5FF-ABDFD2D78A16@oracle.com> Message-ID: <5615921F.2070103@oracle.com> Not sure, I would suggest asking on the project proposal thread? - Don On 07/10/2015 5:25 PM, Richard Bair wrote: > Donald, do you know if the iOS version has the JIT compiler? I know Apple reduced the restriction for some cases, but I can?t remember if it applied to us or not. Or is the VM on iOS interpreter only? > > Richard > >> On Oct 7, 2015, at 2:21 PM, Donald Smith wrote: >> >> There is no "official JDKs for iOS and Android", and anyone that tries to spin the recent OpenJDK project announcement as such is likely just trying to consume you as click-bait. The recent project announcement is simply to make internal code we have for some of our other commercial products available to those who may wish to use it (and therefore we hopefully benefit from any contributions back). That's it. It won't be released as part of the Oracle JDK. It's just some source, for OpenJDK. >> >> - Don >> >> On 07/10/2015 5:11 PM, Felix Bembrick wrote: >>> The world of Java and JavaFX is growing more confusing than ever it seems. >>> >>> Some say Oracle is cutting back on funding for Java because it is effectively helping its competitors. Sounds similar to Google forking WebKit so they weren't writing code for Apple. >>> >>> But now we hear of the looming release of official JDKs for iOS and Android from Oracle. >>> >>> Will these JDKs be the best and simplest way of running JavaFX on those platforms? Without JIT support, will these JDKs support AOT compiling? >>> >>> Do the proposed JDKs for mobiles even include JavaFX? >>> >>> Felix From mike at plan99.net Thu Oct 8 12:48:15 2015 From: mike at plan99.net (Mike Hearn) Date: Thu, 8 Oct 2015 14:48:15 +0200 Subject: Java & JavaFX on mobiles In-Reply-To: <79D73358-8F47-4694-A5FF-ABDFD2D78A16@oracle.com> References: <5B7CA7A4-FB1A-4450-8A48-9DDC599B77A0@gmail.com> <56158CEC.5030207@oracle.com> <79D73358-8F47-4694-A5FF-ABDFD2D78A16@oracle.com> Message-ID: Re: AOT. At the JVMLS summit there was a talk on a HotSpot AOT compiler mode. It's being worked on, however, as a commercial feature. RoboVM provides an AOT compiler for iOS. From leif.samuelsson at oracle.com Thu Oct 8 16:24:00 2015 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Thu, 8 Oct 2015 09:24:00 -0700 Subject: [9] Review request for 8133833: JavaFX HTMLEditor Font Family should not default to a platform-specific font. Message-ID: <561698A0.1030009@oracle.com> Hi Jonathan, https://bugs.openjdk.java.net/browse/JDK-8133833 http://cr.openjdk.java.net/~leifs/8133833/webrev.00/ Thanks, Leif From leif.samuelsson at oracle.com Thu Oct 8 20:19:08 2015 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Thu, 8 Oct 2015 13:19:08 -0700 Subject: [9] Review request for 8088969: Ensemble8: HTML Editor's popup controls retain focus Message-ID: <5616CFBC.5060907@oracle.com> Hi Jonathan, https://bugs.openjdk.java.net/browse/JDK-8088969 http://cr.openjdk.java.net/~leifs/8088969/webrev.00/ Thanks, Leif From kevin.rushforth at oracle.com Thu Oct 8 23:19:44 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 08 Oct 2015 16:19:44 -0700 Subject: [9] review request: 8133103: JavaFX Clipboard should not require AllPermissions Message-ID: <5616FA10.6050002@oracle.com> Vadim, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8133103 http://cr.openjdk.java.net/~kcr/8133103/webrev.00/ Details are in the JIRA. -- Kevin From pj0585 at gmail.com Fri Oct 9 07:55:15 2015 From: pj0585 at gmail.com (Prasant J) Date: Fri, 9 Oct 2015 13:25:15 +0530 Subject: Linux X11 based setup: touch gesture related problem Message-ID: Hi, I'm using Intel atom based hardware (which runs custom linux and has intel HD graphics) to test JavaFX based application. I have built javaFX with monocle X11 support. I have correct graphics library setup and the verbose log confirms that es2 pipeline (X11 platform) is being used. My trouble is with touch gesture. Generally speaking gestures are working but not completely as expected. I'm not using X11 touch, but the touch events are being taken from linux drivers directly. I have an eGalax touch controller. One specific touch gesture trouble is (can be reproduced by the following steps): 1) Two finger pinch and zoom (works) 2) Lift only one finger from touch screen 3) Put the finger back on the touch screen 4) Pinch and zoom again (does not work) until both fingers are lifted Does it sound like a known issue in JavaFX (es2 X11 pipeline)? Some more information about my setup: - monocle.input.touchRadius is set to 1 (my application needs that resolution) - I'm not setting any monocle touch filters - The same application and touch controller work fine when used on Windows system. This is a very critical problem for us and we may not consider this platform if this problem is not solved. So all input is welcome. Any inputs will be of help. Thanks in advance. Regards, Pj From sselvia at gmail.com Fri Oct 9 10:32:37 2015 From: sselvia at gmail.com (Scott Selvia) Date: Fri, 9 Oct 2015 06:32:37 -0400 Subject: Mac App Store Refusal because of QTKit API's In-Reply-To: <2B828058-D3F4-4128-AF4E-6D6BAA137153@gmail.com> References: <186D0F4E-EEC6-43DA-AD58-8BD1C207D28C@gmail.com> <560C0DB8.2070607@oracle.com> <560C11C3.9060708@oracle.com> <9A2D841F-E8E6-486D-AE24-68FE95DB2860@gmail.com> <560C2FC9.9080807@oracle.com> <2B828058-D3F4-4128-AF4E-6D6BAA137153@gmail.com> Message-ID: <008C2D51-5988-4F31-81AB-BB96C698CCEA@gmail.com> Same results?Apple just does not like API?s used within the JRE October 8, 2015 at 9:10 PM From Apple 2.5 - Apps that use non-public APIs will be rejected 2.31 - Apps that are not sandboxed appropriately may be rejected 2.5 The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The following non-public APIs are included in your application: com.apple.security.temporary-exception.files.absolute-path.read-write: True If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions. Additionally, one or more of the above-mentioned APIs may reside in a library included with your application. If you do not have access to the library's source, you may be able to search the compiled binary using "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides. 2.31 Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary. ubrk_getRuleStatus ubrk_setUText ucnv_getCanonicalName ucnv_reset ucol_strcollIter For information on common app sandboxing issues, please see Technical Q&A QA1773 Common app sandboxing issues . See App Sandboxing for links to essential video and documentation to learn how to sandbox your application. As of June 1, 2012, apps must be sandboxed. New apps that are not sandboxed will be rejected. Updates to non-sandboxed apps may be submitted if they only addresses bug fixes and new OS X feature adoption provided that your app was on the Mac App Store prior to June 1st. Should you need code-level assistance implementing sandboxing, contact Apple Developer Technical Support . If you are unable to reproduce this issue, ensure you are testing the exact version of the app that you submitted for review, and that you're doing so in a minimally privileged environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App Store submissions . For information on how to symbolicate and read a crash log, please see Technical Note TN2123 - CrashReporter . Here is my entitlements, so it must be somewhere, I just don?t know where: com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write > On Oct 2, 2015, at 2:36 PM, Scott Selvia wrote: > > Chris, > > The app is in "waiting for review" state again. Last time it sat there for about 5 days then was rejected. Based on the app getting past the deprecated APIs issue I hope I will hear something soon. The bugs, I plan on updating them with a status note ??? This weekend. > > I thinking Apple has some integration issues between OS X apps and iOS apps. My current bundle has a note the it does not include beta testing entitlement. From our understanding of the apple docs, that is for iOS apps only. We do not have that option enabled in iTunes connect > > Scott > > Sent from my iPhone > >> On Oct 2, 2015, at 1:53 PM, Chris Bensen wrote: >> >> Hi Scott, >> >> Let me know what happens with this because we are tracking it with two bugs on our end ? one in the packager and one in WebKit. I?ve spoken with a couple friends at Apple and they don?t think it?s right either but none of them have control over the AppStore. At this point there?s really nothing we can do. With regards tot he CFBundleIndentifier collision, that?s another problem on their end as far as I can tell. >> >> Thanks, >> Chris >> >> >>> On Sep 30, 2015, at 3:41 PM, Scott Selvia wrote: >>> >>> See you at JavaOne, hopefully I?ll have good results to pass along. >>> >>> Again thanks to ALL, there are two Apple bug reports: 22751708 - CFBundleIdentifier Collision for JavaFX Application because of the embedded JRE Info.plist and 22923832 - Rejection of App based on Deprecated API?s used by JavaFX webkit and component and API?s not reference by App. >>> >>> I?ll update the thread once I here back from ITunes Connect on the App submit or when Apple gets back to me on the bug reports. >>> >>>> On Sep 30, 2015, at 5:43 PM, Chris Bensen wrote: >>>> >>>> I?ll be doing the JavaOne Packager talk and will include any information I can on the subject of the App Store that?s relevant. >>>> >>>> Chris >>>> >>>> >>>>> On Sep 30, 2015, at 12:09 PM, Scott Selvia wrote: >>>>> >>>>> I'll update the thread when I get a response from Apple on my latest submission. I believe someone is doing an App Store talk or packager talk at JavaOne. They can include the information in the thread >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Sep 30, 2015, at 3:05 PM, Scott Selvia wrote: >>>>>> >>>>>> Phil, >>>>>> >>>>>> Yes I've done that and I've re-submitted the app again >>>>>> >>>>>> I agree that I should not be penalized by the JRE one would hope that Oracle and Apple worked out the JRE do's and don't when it was decided that Java applications can be posted to the OS X App Store. However I don't think it will do much good for me to open Apple bugs. Oracles stick is much bigger than mine!!! >>>>>> >>>>>> Scott >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Sep 30, 2015, at 2:54 PM, Phil Race wrote: >>>>>>> >>>>>>> It looks like there may be something to this :- >>>>>>> >>>>>>> On mac fx in 8u60 is linking webkit against the system icu library to find these symbols. >>>>>>> >>>>>>> $ nm -a libjfxwebkit.dylib | grep ubrk_getRuleStatus >>>>>>> U _ubrk_getRuleStatus >>>>>>> $ otool -L libjfxwebkit.dylib | grep icu >>>>>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 51.1.0) >>>>>>> >>>>>>> webkit has as "undefined" a much longer list than what Apple complained about >>>>>>> so it is not clear if they regard the entire library as off-limits or just some subset. >>>>>>> >>>>>>> So I don't think this is anything to do with QtKit but is a webkit problem. >>>>>>> Removing that dylib is the apparent workaround, assuming you don't need it. >>>>>>> If the packager can't handle that for you I suppose you need to manually >>>>>>> get rid of it out of your JDK directory before packaging. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>>> On 09/30/2015 10:44 AM, Scott Selvia wrote: >>>>>>>> Will do >>>>>>>> >>>>>>>> It seems Apple is not distinguishing the difference of who is using the APIs. Just like the jfx media qt dylib filtered out of the Java packager process when building a Mac store app. I guess at this point they feel the WebKit dylib falls into the category. >>>>>>>> >>>>>>>> I had an apple issue with the embedded info.plist bundle ID that is part of the jre packaged with the Mac application package generated with the packager. I had to hack the jdk update 60 info.plist file and change the bundle ID with a hashcode suffix. This I opened an apple bug for stating that embedded frameworks should not trigger a bundle collision ID error when uploading an application. I have not had any additional responses >>>>>>>> >>>>>>>> I guess I'll add another bug for embedded frameworks (in this case the JRE) using deprecated APIs >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On Sep 30, 2015, at 12:45 PM, Donald Smith wrote: >>>>>>>>> >>>>>>>>> Please let us know what you hear back with Apple on this given the information below we hope they will see this as an oversight. >>>>>>>>> >>>>>>>>> - Don >>>>>>>>> >>>>>>>>>> On 30/09/2015 12:28 PM, Phil Race wrote: >>>>>>>>>> Yes, these look like ICU functions which so far as I know FX only >>>>>>>>>> references from its *own* internal copy of webkit which in turn has a copy of ICU. >>>>>>>>>> >>>>>>>>>> What is very odd is that Apple is essentially then objecting to referencing >>>>>>>>>> functions that are internal to your app. ie referenced by your app and also >>>>>>>>>> fulfilled by your app, whereas I assume the app store checking should be >>>>>>>>>> against deprecated Apple APIs that you reference in your app and that >>>>>>>>>> are fulfilled by OSX (or iOS). >>>>>>>>>> >>>>>>>>>> So something seems wrong here. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>>> On 09/30/2015 09:19 AM, Scott Selvia wrote: >>>>>>>>>>> Chris, >>>>>>>>>>> >>>>>>>>>>> I'll update iTunes connect with that information and ask them to clarify >>>>>>>>>>> >>>>>>>>>>> Thank you for the additional information, Danno explained they are used in the WebKit dylib >>>>>>>>>>> >>>>>>>>>>> Scott >>>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>>> On Sep 30, 2015, at 12:08 PM, Chris Bensen wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Scott, >>>>>>>>>>>> >>>>>>>>>>>> Those APIs are for the text system ICU. I believe the App Store team may be in error. Perhaps they accidentally copied the wrong forbidden APIs when writing the message. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Sep 29, 2015, at 3:15 AM, Scott Selvia wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I?m using JDK 8 update 60 and I just received an email from Apple saying that my application is using deprecated QTKit API?s. I?ve reviewed Danno Ferrin?s JavaOne session from last year; it says that Update 40?s libjfxmedia_qtkit.dylib or Update 20?s libjfxmedia.dylib should be removed and are by the packager. I have this line in my packager output from the packager, as you can see the libfxmedia.dylib is in my app and pkg. Is this an oversight by the packager and the libfxmedia.dylib should also be removed from my packaged application? >>>>>>>>>>>>> >>>>>>>>>>>>> The original message from ITunes Connect said that these API?s are referenced, when I questioned Apple as to what code was referencing these they said it was the JavaFX Media library. >>>>>>>>>>>>> >>>>>>>>>>>>> ITunes Connect Responce: >>>>>>>>>>>>> >>>>>>>>>>>>> 2.31 >>>>>>>>>>>>> >>>>>>>>>>>>> Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary. >>>>>>>>>>>>> >>>>>>>>>>>>> ubrk_getRuleStatus >>>>>>>>>>>>> ubrk_setUText >>>>>>>>>>>>> ucnv_getCanonicalName >>>>>>>>>>>>> ucnv_reset >>>>>>>>>>>>> ucol_strcollIter >>>>>>>>>>>>> >>>>>>>>>>>>> Dear developer, >>>>>>>>>>>>> >>>>>>>>>>>>> We have discovered one or more issues with your recent delivery for "Examine-IT Pro". To process your delivery, the following issues must be corrected: >>>>>>>>>>>>> >>>>>>>>>>>>> Deprecated API Usage - Apple no longer accepts submissions of apps that use QuickTime or QTKit APIs. >>>>>>>>>>>>> >>>>>>>>>>>>> Once these issues have been corrected, you can then redeliver the corrected binary. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> The App Store team >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Running [codesign, -s, 3rd Party Mac Developer Application: THUNDERCLOUD RESOURCES, LLC (82Z9WT6K6N), --prefix, com.thundercloudresources.examineit., -vvvv, --entitlements, /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/macosx/Examine-IT Pro.entitlements, /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib] >>>>>>>>>>>>> /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib: signed Mach-O thin (x86_64) [com.thundercloudresources.examineit.libjfxmedia] >> From sselvia at gmail.com Fri Oct 9 11:43:10 2015 From: sselvia at gmail.com (Scott Selvia) Date: Fri, 9 Oct 2015 07:43:10 -0400 Subject: Mac App Store Refusal because of QTKit API's In-Reply-To: <008C2D51-5988-4F31-81AB-BB96C698CCEA@gmail.com> References: <186D0F4E-EEC6-43DA-AD58-8BD1C207D28C@gmail.com> <560C0DB8.2070607@oracle.com> <560C11C3.9060708@oracle.com> <9A2D841F-E8E6-486D-AE24-68FE95DB2860@gmail.com> <560C2FC9.9080807@oracle.com> <2B828058-D3F4-4128-AF4E-6D6BAA137153@gmail.com> <008C2D51-5988-4F31-81AB-BB96C698CCEA@gmail.com> Message-ID: I also found that the temporary-exception in Apples response was in my Inherit entitlements file however, it was commented out. This was added after the first submission did not upload by using the App Loader application because it complained about missing entitlements. After doing some research on the ITunes Connect site it said that OSx apps also needed the temporary exception. Once that was set in the Inherit entitlement our application was able to be uploaded, which then resulted in a rejected because of the deprecated API?s used within the JRE. At this point I?m updating my bug on the apple bug report system and going to use one of my code tech support requests to get some answers that will get me past this point. To summarize I updated the JDK/JRE Bundle ID to prevent a collision and I removed the JavaFX WebKit dylib that the Apple review team complained about last time. I?ve attached the AppLoaderAPIAnalysisFile just in case someone at Oracle can see something that Apple is complaining about. So my question now, Is there a JavaFX application in the Mac OSx Store? com.apple.security.temporary-exception.files.absolute-path.read-write ?> Thanks, Scott > On Oct 9, 2015, at 6:32 AM, Scott Selvia wrote: > > Same results?Apple just does not like API?s used within the JRE > > October 8, 2015 at 9:10 PM > From Apple > 2.5 - Apps that use non-public APIs will be rejected > 2.31 - Apps that are not sandboxed appropriately may be rejected > 2.5 > > The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The following non-public APIs are included in your application: > > com.apple.security.temporary-exception.files.absolute-path.read-write: True > > If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions. > > Additionally, one or more of the above-mentioned APIs may reside in a library included with your application. If you do not have access to the library's source, you may be able to search the compiled binary using "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides. > > 2.31 > > Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary. > > ubrk_getRuleStatus > ubrk_setUText > ucnv_getCanonicalName > ucnv_reset > ucol_strcollIter > > For information on common app sandboxing issues, please see Technical Q&A QA1773 Common app sandboxing issues . > > See App Sandboxing for links to essential video and documentation to learn how to sandbox your application. > > As of June 1, 2012, apps must be sandboxed. New apps that are not sandboxed will be rejected. Updates to non-sandboxed apps may be submitted if they only addresses bug fixes and new OS X feature adoption provided that your app was on the Mac App Store prior to June 1st. > > Should you need code-level assistance implementing sandboxing, contact Apple Developer Technical Support . > > If you are unable to reproduce this issue, ensure you are testing the exact version of the app that you submitted for review, and that you're doing so in a minimally privileged environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App Store submissions . > > For information on how to symbolicate and read a crash log, please see Technical Note TN2123 - CrashReporter . > > Here is my entitlements, so it must be somewhere, I just don?t know where: > > > "> > > > com.apple.security.app-sandbox > > com.apple.security.files.user-selected.read-write > > > > > >> On Oct 2, 2015, at 2:36 PM, Scott Selvia > wrote: >> >> Chris, >> >> The app is in "waiting for review" state again. Last time it sat there for about 5 days then was rejected. Based on the app getting past the deprecated APIs issue I hope I will hear something soon. The bugs, I plan on updating them with a status note ??? This weekend. >> >> I thinking Apple has some integration issues between OS X apps and iOS apps. My current bundle has a note the it does not include beta testing entitlement. From our understanding of the apple docs, that is for iOS apps only. We do not have that option enabled in iTunes connect >> >> Scott >> >> Sent from my iPhone >> >>> On Oct 2, 2015, at 1:53 PM, Chris Bensen > wrote: >>> >>> Hi Scott, >>> >>> Let me know what happens with this because we are tracking it with two bugs on our end ? one in the packager and one in WebKit. I?ve spoken with a couple friends at Apple and they don?t think it?s right either but none of them have control over the AppStore. At this point there?s really nothing we can do. With regards tot he CFBundleIndentifier collision, that?s another problem on their end as far as I can tell. >>> >>> Thanks, >>> Chris >>> >>> >>>> On Sep 30, 2015, at 3:41 PM, Scott Selvia > wrote: >>>> >>>> See you at JavaOne, hopefully I?ll have good results to pass along. >>>> >>>> Again thanks to ALL, there are two Apple bug reports: 22751708 - CFBundleIdentifier Collision for JavaFX Application because of the embedded JRE Info.plist and 22923832 - Rejection of App based on Deprecated API?s used by JavaFX webkit and component and API?s not reference by App. >>>> >>>> I?ll update the thread once I here back from ITunes Connect on the App submit or when Apple gets back to me on the bug reports. >>>> >>>>> On Sep 30, 2015, at 5:43 PM, Chris Bensen > wrote: >>>>> >>>>> I?ll be doing the JavaOne Packager talk and will include any information I can on the subject of the App Store that?s relevant. >>>>> >>>>> Chris >>>>> >>>>> >>>>>> On Sep 30, 2015, at 12:09 PM, Scott Selvia > wrote: >>>>>> >>>>>> I'll update the thread when I get a response from Apple on my latest submission. I believe someone is doing an App Store talk or packager talk at JavaOne. They can include the information in the thread >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Sep 30, 2015, at 3:05 PM, Scott Selvia > wrote: >>>>>>> >>>>>>> Phil, >>>>>>> >>>>>>> Yes I've done that and I've re-submitted the app again >>>>>>> >>>>>>> I agree that I should not be penalized by the JRE one would hope that Oracle and Apple worked out the JRE do's and don't when it was decided that Java applications can be posted to the OS X App Store. However I don't think it will do much good for me to open Apple bugs. Oracles stick is much bigger than mine!!! >>>>>>> >>>>>>> Scott >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Sep 30, 2015, at 2:54 PM, Phil Race > wrote: >>>>>>>> >>>>>>>> It looks like there may be something to this :- >>>>>>>> >>>>>>>> On mac fx in 8u60 is linking webkit against the system icu library to find these symbols. >>>>>>>> >>>>>>>> $ nm -a libjfxwebkit.dylib | grep ubrk_getRuleStatus >>>>>>>> U _ubrk_getRuleStatus >>>>>>>> $ otool -L libjfxwebkit.dylib | grep icu >>>>>>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 51.1.0) >>>>>>>> >>>>>>>> webkit has as "undefined" a much longer list than what Apple complained about >>>>>>>> so it is not clear if they regard the entire library as off-limits or just some subset. >>>>>>>> >>>>>>>> So I don't think this is anything to do with QtKit but is a webkit problem. >>>>>>>> Removing that dylib is the apparent workaround, assuming you don't need it. >>>>>>>> If the packager can't handle that for you I suppose you need to manually >>>>>>>> get rid of it out of your JDK directory before packaging. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>>> On 09/30/2015 10:44 AM, Scott Selvia wrote: >>>>>>>>> Will do >>>>>>>>> >>>>>>>>> It seems Apple is not distinguishing the difference of who is using the APIs. Just like the jfx media qt dylib filtered out of the Java packager process when building a Mac store app. I guess at this point they feel the WebKit dylib falls into the category. >>>>>>>>> >>>>>>>>> I had an apple issue with the embedded info.plist bundle ID that is part of the jre packaged with the Mac application package generated with the packager. I had to hack the jdk update 60 info.plist file and change the bundle ID with a hashcode suffix. This I opened an apple bug for stating that embedded frameworks should not trigger a bundle collision ID error when uploading an application. I have not had any additional responses >>>>>>>>> >>>>>>>>> I guess I'll add another bug for embedded frameworks (in this case the JRE) using deprecated APIs >>>>>>>>> >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>>> On Sep 30, 2015, at 12:45 PM, Donald Smith > wrote: >>>>>>>>>> >>>>>>>>>> Please let us know what you hear back with Apple on this given the information below we hope they will see this as an oversight. >>>>>>>>>> >>>>>>>>>> - Don >>>>>>>>>> >>>>>>>>>>> On 30/09/2015 12:28 PM, Phil Race wrote: >>>>>>>>>>> Yes, these look like ICU functions which so far as I know FX only >>>>>>>>>>> references from its *own* internal copy of webkit which in turn has a copy of ICU. >>>>>>>>>>> >>>>>>>>>>> What is very odd is that Apple is essentially then objecting to referencing >>>>>>>>>>> functions that are internal to your app. ie referenced by your app and also >>>>>>>>>>> fulfilled by your app, whereas I assume the app store checking should be >>>>>>>>>>> against deprecated Apple APIs that you reference in your app and that >>>>>>>>>>> are fulfilled by OSX (or iOS). >>>>>>>>>>> >>>>>>>>>>> So something seems wrong here. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>>> On 09/30/2015 09:19 AM, Scott Selvia wrote: >>>>>>>>>>>> Chris, >>>>>>>>>>>> >>>>>>>>>>>> I'll update iTunes connect with that information and ask them to clarify >>>>>>>>>>>> >>>>>>>>>>>> Thank you for the additional information, Danno explained they are used in the WebKit dylib >>>>>>>>>>>> >>>>>>>>>>>> Scott >>>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>>> On Sep 30, 2015, at 12:08 PM, Chris Bensen > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Scott, >>>>>>>>>>>>> >>>>>>>>>>>>> Those APIs are for the text system ICU. I believe the App Store team may be in error. Perhaps they accidentally copied the wrong forbidden APIs when writing the message. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Chris >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 29, 2015, at 3:15 AM, Scott Selvia > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I?m using JDK 8 update 60 and I just received an email from Apple saying that my application is using deprecated QTKit API?s. I?ve reviewed Danno Ferrin?s JavaOne session from last year; it says that Update 40?s libjfxmedia_qtkit.dylib or Update 20?s libjfxmedia.dylib should be removed and are by the packager. I have this line in my packager output from the packager, as you can see the libfxmedia.dylib is in my app and pkg. Is this an oversight by the packager and the libfxmedia.dylib should also be removed from my packaged application? >>>>>>>>>>>>>> >>>>>>>>>>>>>> The original message from ITunes Connect said that these API?s are referenced, when I questioned Apple as to what code was referencing these they said it was the JavaFX Media library. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ITunes Connect Responce: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2.31 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ubrk_getRuleStatus >>>>>>>>>>>>>> ubrk_setUText >>>>>>>>>>>>>> ucnv_getCanonicalName >>>>>>>>>>>>>> ucnv_reset >>>>>>>>>>>>>> ucol_strcollIter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Dear developer, >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have discovered one or more issues with your recent delivery for "Examine-IT Pro". To process your delivery, the following issues must be corrected: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Deprecated API Usage - Apple no longer accepts submissions of apps that use QuickTime or QTKit APIs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Once these issues have been corrected, you can then redeliver the corrected binary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The App Store team >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Running [codesign, -s, 3rd Party Mac Developer Application: THUNDERCLOUD RESOURCES, LLC (82Z9WT6K6N), --prefix, com.thundercloudresources.examineit., -vvvv, --entitlements, /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/macosx/Examine-IT Pro.entitlements, /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib] >>>>>>>>>>>>>> /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib: signed Mach-O thin (x86_64) [com.thundercloudresources.examineit.libjfxmedia] >>> > From mp at jugs.org Fri Oct 9 12:05:11 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 9 Oct 2015 14:05:11 +0200 Subject: Mac App Store Refusal because of QTKit API's In-Reply-To: References: <186D0F4E-EEC6-43DA-AD58-8BD1C207D28C@gmail.com> <560C0DB8.2070607@oracle.com> <560C11C3.9060708@oracle.com> <9A2D841F-E8E6-486D-AE24-68FE95DB2860@gmail.com> <560C2FC9.9080807@oracle.com> <2B828058-D3F4-4128-AF4E-6D6BAA137153@gmail.com> <008C2D51-5988-4F31-81AB-BB96C698CCEA@gmail.com> Message-ID: <5617AD77.7070200@jugs.org> Am 09.10.15 um 13:43 schrieb Scott Selvia: > > So my question now, Is there a JavaFX application in the Mac OSx Store? There still is the Ensemble 8 app in the OSX store. But it is already more than a year old. > > com.apple.security.temporary-exception.files.absolute-path.read-write > > ?> > > Thanks, > > Scott > >> On Oct 9, 2015, at 6:32 AM, Scott Selvia wrote: >> >> Same results?Apple just does not like API?s used within the JRE >> >> October 8, 2015 at 9:10 PM >> From Apple >> 2.5 - Apps that use non-public APIs will be rejected >> 2.31 - Apps that are not sandboxed appropriately may be rejected >> 2.5 >> >> The use of non-public APIs can lead to a poor user experience should these APIs change in the future, and is therefore not permitted. The following non-public APIs are included in your application: >> >> com.apple.security.temporary-exception.files.absolute-path.read-write: True >> >> If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions. >> >> Additionally, one or more of the above-mentioned APIs may reside in a library included with your application. If you do not have access to the library's source, you may be able to search the compiled binary using "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides. >> >> 2.31 >> >> Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary. >> >> ubrk_getRuleStatus >> ubrk_setUText >> ucnv_getCanonicalName >> ucnv_reset >> ucol_strcollIter >> >> For information on common app sandboxing issues, please see Technical Q&A QA1773 Common app sandboxing issues . >> >> See App Sandboxing for links to essential video and documentation to learn how to sandbox your application. >> >> As of June 1, 2012, apps must be sandboxed. New apps that are not sandboxed will be rejected. Updates to non-sandboxed apps may be submitted if they only addresses bug fixes and new OS X feature adoption provided that your app was on the Mac App Store prior to June 1st. >> >> Should you need code-level assistance implementing sandboxing, contact Apple Developer Technical Support . >> >> If you are unable to reproduce this issue, ensure you are testing the exact version of the app that you submitted for review, and that you're doing so in a minimally privileged environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App Store submissions . >> >> For information on how to symbolicate and read a crash log, please see Technical Note TN2123 - CrashReporter . >> >> Here is my entitlements, so it must be somewhere, I just don?t know where: >> >> >> "> >> >> >> com.apple.security.app-sandbox >> >> com.apple.security.files.user-selected.read-write >> >> >> >> >> >>> On Oct 2, 2015, at 2:36 PM, Scott Selvia > wrote: >>> >>> Chris, >>> >>> The app is in "waiting for review" state again. Last time it sat there for about 5 days then was rejected. Based on the app getting past the deprecated APIs issue I hope I will hear something soon. The bugs, I plan on updating them with a status note ??? This weekend. >>> >>> I thinking Apple has some integration issues between OS X apps and iOS apps. My current bundle has a note the it does not include beta testing entitlement. From our understanding of the apple docs, that is for iOS apps only. We do not have that option enabled in iTunes connect >>> >>> Scott >>> >>> Sent from my iPhone >>> >>>> On Oct 2, 2015, at 1:53 PM, Chris Bensen > wrote: >>>> >>>> Hi Scott, >>>> >>>> Let me know what happens with this because we are tracking it with two bugs on our end ? one in the packager and one in WebKit. I?ve spoken with a couple friends at Apple and they don?t think it?s right either but none of them have control over the AppStore. At this point there?s really nothing we can do. With regards tot he CFBundleIndentifier collision, that?s another problem on their end as far as I can tell. >>>> >>>> Thanks, >>>> Chris >>>> >>>> >>>>> On Sep 30, 2015, at 3:41 PM, Scott Selvia > wrote: >>>>> >>>>> See you at JavaOne, hopefully I?ll have good results to pass along. >>>>> >>>>> Again thanks to ALL, there are two Apple bug reports: 22751708 - CFBundleIdentifier Collision for JavaFX Application because of the embedded JRE Info.plist and 22923832 - Rejection of App based on Deprecated API?s used by JavaFX webkit and component and API?s not reference by App. >>>>> >>>>> I?ll update the thread once I here back from ITunes Connect on the App submit or when Apple gets back to me on the bug reports. >>>>> >>>>>> On Sep 30, 2015, at 5:43 PM, Chris Bensen > wrote: >>>>>> >>>>>> I?ll be doing the JavaOne Packager talk and will include any information I can on the subject of the App Store that?s relevant. >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>>> On Sep 30, 2015, at 12:09 PM, Scott Selvia > wrote: >>>>>>> >>>>>>> I'll update the thread when I get a response from Apple on my latest submission. I believe someone is doing an App Store talk or packager talk at JavaOne. They can include the information in the thread >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Sep 30, 2015, at 3:05 PM, Scott Selvia > wrote: >>>>>>>> >>>>>>>> Phil, >>>>>>>> >>>>>>>> Yes I've done that and I've re-submitted the app again >>>>>>>> >>>>>>>> I agree that I should not be penalized by the JRE one would hope that Oracle and Apple worked out the JRE do's and don't when it was decided that Java applications can be posted to the OS X App Store. However I don't think it will do much good for me to open Apple bugs. Oracles stick is much bigger than mine!!! >>>>>>>> >>>>>>>> Scott >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On Sep 30, 2015, at 2:54 PM, Phil Race > wrote: >>>>>>>>> >>>>>>>>> It looks like there may be something to this :- >>>>>>>>> >>>>>>>>> On mac fx in 8u60 is linking webkit against the system icu library to find these symbols. >>>>>>>>> >>>>>>>>> $ nm -a libjfxwebkit.dylib | grep ubrk_getRuleStatus >>>>>>>>> U _ubrk_getRuleStatus >>>>>>>>> $ otool -L libjfxwebkit.dylib | grep icu >>>>>>>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 51.1.0) >>>>>>>>> >>>>>>>>> webkit has as "undefined" a much longer list than what Apple complained about >>>>>>>>> so it is not clear if they regard the entire library as off-limits or just some subset. >>>>>>>>> >>>>>>>>> So I don't think this is anything to do with QtKit but is a webkit problem. >>>>>>>>> Removing that dylib is the apparent workaround, assuming you don't need it. >>>>>>>>> If the packager can't handle that for you I suppose you need to manually >>>>>>>>> get rid of it out of your JDK directory before packaging. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>>> On 09/30/2015 10:44 AM, Scott Selvia wrote: >>>>>>>>>> Will do >>>>>>>>>> >>>>>>>>>> It seems Apple is not distinguishing the difference of who is using the APIs. Just like the jfx media qt dylib filtered out of the Java packager process when building a Mac store app. I guess at this point they feel the WebKit dylib falls into the category. >>>>>>>>>> >>>>>>>>>> I had an apple issue with the embedded info.plist bundle ID that is part of the jre packaged with the Mac application package generated with the packager. I had to hack the jdk update 60 info.plist file and change the bundle ID with a hashcode suffix. This I opened an apple bug for stating that embedded frameworks should not trigger a bundle collision ID error when uploading an application. I have not had any additional responses >>>>>>>>>> >>>>>>>>>> I guess I'll add another bug for embedded frameworks (in this case the JRE) using deprecated APIs >>>>>>>>>> >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>>> On Sep 30, 2015, at 12:45 PM, Donald Smith > wrote: >>>>>>>>>>> >>>>>>>>>>> Please let us know what you hear back with Apple on this given the information below we hope they will see this as an oversight. >>>>>>>>>>> >>>>>>>>>>> - Don >>>>>>>>>>> >>>>>>>>>>>> On 30/09/2015 12:28 PM, Phil Race wrote: >>>>>>>>>>>> Yes, these look like ICU functions which so far as I know FX only >>>>>>>>>>>> references from its *own* internal copy of webkit which in turn has a copy of ICU. >>>>>>>>>>>> >>>>>>>>>>>> What is very odd is that Apple is essentially then objecting to referencing >>>>>>>>>>>> functions that are internal to your app. ie referenced by your app and also >>>>>>>>>>>> fulfilled by your app, whereas I assume the app store checking should be >>>>>>>>>>>> against deprecated Apple APIs that you reference in your app and that >>>>>>>>>>>> are fulfilled by OSX (or iOS). >>>>>>>>>>>> >>>>>>>>>>>> So something seems wrong here. >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>>> On 09/30/2015 09:19 AM, Scott Selvia wrote: >>>>>>>>>>>>> Chris, >>>>>>>>>>>>> >>>>>>>>>>>>> I'll update iTunes connect with that information and ask them to clarify >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for the additional information, Danno explained they are used in the WebKit dylib >>>>>>>>>>>>> >>>>>>>>>>>>> Scott >>>>>>>>>>>>> >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 30, 2015, at 12:08 PM, Chris Bensen > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Scott, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Those APIs are for the text system ICU. I believe the App Store team may be in error. Perhaps they accidentally copied the wrong forbidden APIs when writing the message. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Chris >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sep 29, 2015, at 3:15 AM, Scott Selvia > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I?m using JDK 8 update 60 and I just received an email from Apple saying that my application is using deprecated QTKit API?s. I?ve reviewed Danno Ferrin?s JavaOne session from last year; it says that Update 40?s libjfxmedia_qtkit.dylib or Update 20?s libjfxmedia.dylib should be removed and are by the packager. I have this line in my packager output from the packager, as you can see the libfxmedia.dylib is in my app and pkg. Is this an oversight by the packager and the libfxmedia.dylib should also be removed from my packaged application? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The original message from ITunes Connect said that these API?s are referenced, when I questioned Apple as to what code was referencing these they said it was the JavaFX Media library. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ITunes Connect Responce: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2.31 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issues before resubmitting a new binary. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ubrk_getRuleStatus >>>>>>>>>>>>>>> ubrk_setUText >>>>>>>>>>>>>>> ucnv_getCanonicalName >>>>>>>>>>>>>>> ucnv_reset >>>>>>>>>>>>>>> ucol_strcollIter >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Dear developer, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We have discovered one or more issues with your recent delivery for "Examine-IT Pro". To process your delivery, the following issues must be corrected: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Deprecated API Usage - Apple no longer accepts submissions of apps that use QuickTime or QTKit APIs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Once these issues have been corrected, you can then redeliver the corrected binary. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The App Store team >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Running [codesign, -s, 3rd Party Mac Developer Application: THUNDERCLOUD RESOURCES, LLC (82Z9WT6K6N), --prefix, com.thundercloudresources.examineit., -vvvv, --entitlements, /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/macosx/Examine-IT Pro.entitlements, /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib] >>>>>>>>>>>>>>> /var/folders/wd/0dvkql1x0yxc9911tp1tz57c0000gq/T/fxbundler8869305413596109692/images/image-2516465556090179709/Examine-IT Pro.app/Contents/PlugIns/Java.runtime/Contents/Home/jre/lib/libjfxmedia.dylib: signed Mach-O thin (x86_64) [com.thundercloudresources.examineit.libjfxmedia] From vadim.pakhnushev at oracle.com Fri Oct 9 16:00:34 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 9 Oct 2015 19:00:34 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <5617E4A2.7020501@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From David.Hill at Oracle.com Fri Oct 9 16:36:45 2015 From: David.Hill at Oracle.com (David Hill) Date: Fri, 09 Oct 2015 12:36:45 -0400 Subject: Linux X11 based setup: touch gesture related problem In-Reply-To: References: Message-ID: <5617ED1D.7060807@Oracle.com> On 10/9/15, 3:55 AM, Prasant J wrote: > Hi, Hi Prasant, Not a known issue. I suspect that the gesture recognition is not getting reset properly, expecting that both fingers should be lifted. Probably not terribly hard to fix, but would have to add it to the queue. You should file a bug. Dave > > > I'm using Intel atom based hardware (which runs custom linux and has intel > HD graphics) to test JavaFX based application. I have built javaFX with > monocle X11 support. I have correct graphics library setup and the verbose > log confirms that es2 pipeline (X11 platform) is being used. > > > My trouble is with touch gesture. Generally speaking gestures are working > but not completely as expected. I'm not using X11 touch, but the touch > events are being taken from linux drivers directly. I have an eGalax touch > controller. > > > One specific touch gesture trouble is (can be reproduced by the following > steps): > 1) Two finger pinch and zoom (works) > 2) Lift only one finger from touch screen > 3) Put the finger back on the touch screen > 4) Pinch and zoom again (does not work) until both fingers are lifted > > > Does it sound like a known issue in JavaFX (es2 X11 pipeline)? > > > Some more information about my setup: > - monocle.input.touchRadius is set to 1 (my application needs that > resolution) > - I'm not setting any monocle touch filters > - The same application and touch controller work fine when used on Windows > system. > > > This is a very critical problem for us and we may not consider this > platform if this problem is not solved. So all input is welcome. Any inputs > will be of help. > > > Thanks in advance. > > > Regards, Pj -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Fri Oct 9 21:27:03 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 09 Oct 2015 14:27:03 -0700 Subject: [9] review request: 8139326: [TEST] Unit tests for JFXPanel with security manager don't detect errors Message-ID: <56183127.1060901@oracle.com> Chien, Please review the following test fix: https://bugs.openjdk.java.net/browse/JDK-8139326 http://cr.openjdk.java.net/~kcr/8139326/webrev.00/ -- Kevin From john2011uk at gmail.com Sun Oct 11 08:35:46 2015 From: john2011uk at gmail.com (John Maton) Date: Sun, 11 Oct 2015 10:35:46 +0200 Subject: JDJ-8139122 - thanks for the work-around Message-ID: Guru, Thanks for your work-around, it works fine for me: "Alternatively : Please try to set a custom User agent by removing "JavaFX/8.0" as mentioned below browser.getEngine().setUserAgent("Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/538.19 (KHTML, like Gecko) Safari/538.19"); " Instead of doing that I did the following to make sure future changes do not affect me: browser.getEngine().setUserAgent(browser.getEngine().getUserAgent().replaceFirst("JavaFX/\\d.\\d ","")); Please add my comments to JDJ-8139122 thanks again, John Maton From tobi at ultramixer.com Mon Oct 12 07:26:16 2015 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 12 Oct 2015 09:26:16 +0200 Subject: WebView + Youtube = NullPointerException Message-ID: <7E1601DB-1159-4F41-A223-97CE1F4D24FE@ultramixer.com> Hi, we tried to replace our in house Java based browser rapper (Webkit on Mac, InternetExplorer on Windows) with WebView. But that?s currently not possible because of NullPointerException and graphic errors (texture failures). Here is a simple test case: https://github.com/UltraMixer/JavaFXPerformanceTest/blob/master/src/main/java/com/ultramixer/javafxperformancetest/WebViewYoutubeTest.java The test class loads a video in youtube.com and resizes the window periodically. After just a few seconds WebView is thrown NullPointerExceptions and shows up render issues?. Outstanding resource locks detected: ES2 Vram Pool: 536.788.704 used (100,0%), 536.870.912 target (100,0%), 536.870.912 max 46 total resources being managed average resource age is 0,1 frames 0 resources at maximum supported age (0,0%) 41 resources marked permanent (89,1%) 3 resources have had mismatched locks (6,5%) 3 resources locked (6,5%) 42 resources contain interesting data (91,3%) 0 resources disappeared (0,0%) java.lang.NullPointerException at com.sun.javafx.webkit.prism.WCPageBackBufferImpl.validate(WCPageBackBufferImpl.java:115) at com.sun.webkit.WebPage.paint(WebPage.java:644) at com.sun.javafx.sg.prism.web.NGWebView.renderContent(NGWebView.java:96) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2053) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1945) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:474) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:327) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:91) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.lang.Thread.run(Thread.java:745) Tested with: Java 1.8.0_60 and 1.8.0_66 on Mac OS X 10.11 (MacBookPro Retina) Best regards, Tobi From danno.ferrin at oracle.com Mon Oct 12 18:50:31 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Mon, 12 Oct 2015 12:50:31 -0600 Subject: [9-sandbox-jake] Request for Approval - 8080531 - Modular Java Application Packaging Message-ID: <63947E30-3EFC-4B76-9982-C325DAA2FB31@oracle.com> Kevin, Chris, This is a Work in Progress to be put in the jake sandbox for JEP-275 work. Mostly so we can get it out in the open before JavaOne at the end of the month. This patch breaks the deployment samples, and there isn't a plan in place to fix them. The issues are deep and relate to Ant. This patch requires JDK9_HOME to be set to a current jigsaw build. So current you have to sync as of 12 Oct or later because some of the JLink APIs are also a work in progress. If you don't set JDK9_HOME then the packager won't be built at all. The previous webrevs use the older APIs. Only Mac has received much in the way of testing. And then only the most basic testing since Gradle for the foreseeable future cannot run the unit tests on Java 9 (this is a problem with Gradle). webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.04/ jira: https://bugs.openjdk.java.net/browse/JDK-8080531 From kevin.rushforth at oracle.com Mon Oct 12 19:29:57 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Oct 2015 12:29:57 -0700 Subject: [9] Review request: 8139450: JavaFX applications cannot be run with JDK 9-b85 promoted build Message-ID: <561C0A35.4010109@oracle.com> Hi Jonathan, Please review this P1 fix: https://bugs.openjdk.java.net/browse/JDK-8139450 http://cr.openjdk.java.net/~kcr/8139450/webrev.00/ Thanks. -- Kevin From jonathan.giles at oracle.com Mon Oct 12 20:21:25 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 13 Oct 2015 09:21:25 +1300 Subject: Backport for [JDK-8131151] Pressing ESC in a nested alert closes self and parent alert In-Reply-To: <5603B62F.2060208@media-interactive.de> References: <5603B62F.2060208@media-interactive.de> Message-ID: <561C1645.4040205@oracle.com> FYI - this is now backported and will be in 8u72. -- Jonathan On 24/09/2015 8:37 p.m., Werner Lehmann wrote: > Hi, > > since there seems to be an opportunity to have fixes backported to 8, > I'd like to ask for a backport of the fix for > > [JDK-8131151] Pressing ESC in a nested alert closes self and parent alert > https://bugs.openjdk.java.net/browse/JDK-8131151 > > Looks as if the fix is pretty simple. Without this we seem to be > forced to disallow closing dialogs with escape key because the > following yes/no/cancel alert would be dismissed right away from the > same keypress. Admittedly, it is not critical in any way but the > backport risk should be low. > > Rgds > Werner From kevin.rushforth at oracle.com Mon Oct 12 20:46:09 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 12 Oct 2015 13:46:09 -0700 Subject: 9-dev unlocked following sanity testing Message-ID: <561C1C11.2080104@oracle.com> From chris.bensen at oracle.com Tue Oct 13 16:04:00 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 13 Oct 2015 09:04:00 -0700 Subject: [9-sandbox-jake] Request for Approval - 8080531 - Modular Java Application Packaging In-Reply-To: <63947E30-3EFC-4B76-9982-C325DAA2FB31@oracle.com> References: <63947E30-3EFC-4B76-9982-C325DAA2FB31@oracle.com> Message-ID: <7CCABD98-357C-4E9B-BB1E-3BAEB7521CC3@oracle.com> +1 > On Oct 12, 2015, at 11:50 AM, Danno Ferrin wrote: > > Kevin, Chris, > > This is a Work in Progress to be put in the jake sandbox for JEP-275 work. Mostly so we can get it out in the open before JavaOne at the end of the month. > > This patch breaks the deployment samples, and there isn't a plan in place to fix them. The issues are deep and relate to Ant. > > This patch requires JDK9_HOME to be set to a current jigsaw build. So current you have to sync as of 12 Oct or later because some of the JLink APIs are also a work in progress. If you don't set JDK9_HOME then the packager won't be built at all. The previous webrevs use the older APIs. > > Only Mac has received much in the way of testing. And then only the most basic testing since Gradle for the foreseeable future cannot run the unit tests on Java 9 (this is a problem with Gradle). > > webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.04/ > jira: https://bugs.openjdk.java.net/browse/JDK-8080531 From kevin.rushforth at oracle.com Wed Oct 14 15:24:13 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Oct 2015 08:24:13 -0700 Subject: [9] Review request: 8139593: Running apps on FX 9 + JDK 8u fails when security manager is enabled Message-ID: <561E739D.2060707@oracle.com> Dave, Please review this simple fix, which is a follow-on to JDK-8139450: https://bugs.openjdk.java.net/browse/JDK-8139593 http://cr.openjdk.java.net/~kcr/8139593/webrev.00/ Thanks. -- Kevin From leif.samuelsson at oracle.com Wed Oct 14 18:21:07 2015 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Wed, 14 Oct 2015 11:21:07 -0700 Subject: [9] Review request for 8139606: [MenuBar] Menus should activate on ALT released, not pressed, on Windows/Linux Message-ID: <561E9D13.5020000@oracle.com> Hi Jonathan, https://bugs.openjdk.java.net/browse/JDK-8139606 http://cr.openjdk.java.net/~leifs/8139606/webrev.00/ Thanks, Leif From kevin.rushforth at oracle.com Wed Oct 14 21:13:36 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 14 Oct 2015 14:13:36 -0700 Subject: [9-sandbox-jake] Request for Approval - 8080531 - Modular Java Application Packaging In-Reply-To: <63947E30-3EFC-4B76-9982-C325DAA2FB31@oracle.com> References: <63947E30-3EFC-4B76-9982-C325DAA2FB31@oracle.com> Message-ID: <561EC580.5030802@oracle.com> +1 Looks good to me. -- Kevin Danno Ferrin wrote: > Kevin, Chris, > > This is a Work in Progress to be put in the jake sandbox for JEP-275 work. Mostly so we can get it out in the open before JavaOne at the end of the month. > > This patch breaks the deployment samples, and there isn't a plan in place to fix them. The issues are deep and relate to Ant. > > This patch requires JDK9_HOME to be set to a current jigsaw build. So current you have to sync as of 12 Oct or later because some of the JLink APIs are also a work in progress. If you don't set JDK9_HOME then the packager won't be built at all. The previous webrevs use the older APIs. > > Only Mac has received much in the way of testing. And then only the most basic testing since Gradle for the foreseeable future cannot run the unit tests on Java 9 (this is a problem with Gradle). > > webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.04/ > jira: https://bugs.openjdk.java.net/browse/JDK-8080531 From johan.vos at gluonhq.com Thu Oct 15 11:27:26 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 15 Oct 2015 13:27:26 +0200 Subject: pisces, produceFillAlphas Message-ID: After spending lots of time optimizing JavaFX on iOS, I am now at the point where scrolling is 10 times faster on iOS than on Android. The scrolling in the iOS version of the Gluon JavaOne mobile schedule builder is pretty good imho. On Android, it is much slower. I profiled and compared both, and it turns out that on Android, we spend lots of time in the native implementation of NativePiscesRasterizer.produceFillAlphas (implemented in native-prism/NativePiscesRasterizer.c) On average, calling this native function on an iPhone 6 takes 40,000ns whereas on a Nexus 6, this takes about 800,000ns. If anyone has a suggestion on how to improve or avoid this, I'm all ears. Thanks, - Johan From lehmann at media-interactive.de Thu Oct 15 14:37:57 2015 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 15 Oct 2015 16:37:57 +0200 Subject: Scroll Gesture in ListView In-Reply-To: References: Message-ID: <561FBA45.7080809@media-interactive.de> Hi Johan, wouldn't it be possible to use an event filter on the listview? It would see (and consume) the event before it even gets to the listcell. Werner On 06.10.2015 10:02, Johan Vos wrote: > So it seems to me we need something like "gestureTransparent", by which we > can indicate a Node not to be interested in handling gestures. The code for > picking the target Node currently ignores the Node if it has the > mouseTransparent set. I would propose to add a gestureTransparent property > on Node, and to add the following check: > if we need to find the pickedTarget for a gestureEvent, it should never > return a node with gestureTransparent set to true. From morris.meyer at oracle.com Thu Oct 15 15:55:07 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 15 Oct 2015 11:55:07 -0400 Subject: RFR: JDK-8088993: Accepting object is null after a drop Message-ID: <561FCC5B.10109@oracle.com> Jonathan and Kevin, Please review this simple fix to DragEvent.java. It uses the existing template for the acceptingObject and has been tested on Mac and Windows. Thanks much, --morris BUG - https://bugs.openjdk.java.net/browse/JDK-8088993 WEBREV - http://cr.openjdk.java.net/~morris/JDK-8088993.01/ From rahman.usta.88 at gmail.com Thu Oct 15 16:09:00 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 15 Oct 2015 19:09:00 +0300 Subject: Process manager already initialized: can't fully enable headless mode In-Reply-To: References: Message-ID: Is it a bug ? or what? Could someone help me for this issue? Thanks. 2015-10-06 22:27 GMT+03:00 Rahman USTA : > Hello; > > Some of Mac users are facing with following problem. What can be the > reason? Thanks. > > Hello I have > > Software OS X 10.8.5 (12F2560) > Java 8 U 60 > I just have installed the AsciidocFX v1.3.8 for Mac > > When I open/execute the program I can see the main window just one second > and it crash, the app is still running, immediately for few seconds below > in the dock an icon about Updater appears and disappears. > > If I open the app through a terminal, no error message appears. But using > or checking the > Console -> system.log, I can see the following: > > JavaApplicationStub[261]: [JRSAppKitAWT markAppIsDaemon]: Process > manager already initialized: can't fully enable headless mode. > JavaApplicationStub[261]: *** -[__NSArrayM insertObject:atIndex:]: > object cannot be nil > JavaApplicationStub[261]: ( > 0 CoreFoundation 0x00007fff8da96b06 > __exceptionPreprocess + 198 > 1 libobjc.A.dylib 0x00007fff880983f0 > objc_exception_throw + 43 > 2 CoreFoundation 0x00007fff8da4727a > -[__NSArrayM insertObject:atIndex:] + 282 > 3 AppKit 0x00007fff892f9794 > -[NSMenu insertItem:atIndex:] + 505 > 4 libawt_lwawt.dylib 0x000000012cc435e7 > addMenuItem + 185 > 5 libawt_lwawt.dylib 0x000000012cc42f54 > -[ApplicationDelegate _updatePreferencesMenu:enabled:] + 211 > 6 libawt_lwawt.dylib 0x000000012cc43179 > __Java_com_apple_eawt__1AppMenuBarHandler_nativeSetMenuState_block_invoke_1 > + 159 > 7 JavaNativeFoundation 0x00000001007f15f5 > +[JNFRunLoop _performCopiedBlock:] + 20 > 8 Foundation 0x00007fff8e25b59a > __NSThreadPerformPerform + 225 > 9 CoreFoundation 0x00007fff8da15b31 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 10 CoreFoundation 0x00007fff8da1551d > __CFRunLoopDoSources0 + 445 > 11 CoreFoundation 0x00007fff8da387f5 > __CFRunLoopRun + 789 > 12 CoreFoundation 0x00007fff8da380e2 > CFRunLoopRunSpecific + 290 > 13 HIToolbox 0x00007fff8b412eb4 > RunCurrentEventLoopInMode + 209 > 14 HIToolbox 0x00007fff8b412b94 > ReceiveNextEventCommon + 166 > 15 HIToolbox 0x00007fff8b412ae3 > BlockUntilNextEventMatchingListInMode + 62 > 16 AppKit 0x00007fff89307533 > _DPSNextEvent + 685 > 17 AppKit 0x00007fff89306df2 > -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 > 18 AppKit 0x00007fff892fe1a3 > -[NSApplication run] + 517 > 19 libglass.dylib 0x000000011e2c15ec > -[GlassApplication runLoop:] + 1836 > 20 Foundation 0x00007fff8e25b59a > __NSThreadPerformPerform + 225 > 21 CoreFoundation 0x00007fff8da15b31 > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 > 22 CoreFoundation 0x00007fff8da15455 > __CFRunLoopDoSources0 + 245 > 23 CoreFoundation 0x00007fff8da387f5 > __CFRunLoopRun + 789 > 24 CoreFoundation 0x00007fff8da380e2 > CFRunLoopRunSpecific + 290 > 25 libjli.dylib 0x00000001000f28fb > CreateExecutionEnvironment + 871 > 26 libjli.dylib 0x00000001000ee644 > JLI_Launch + 1952 > 27 JavaApplicationStub 0x0000000100006e98 > -[Launcher launch] + 872 > 28 JavaApplicationStub 0x00000001000075b5 > launcher_main + 645 > 29 JavaApplicationStub 0x0000000100007722 main + > 34 > 30 JavaApplicationStub 0x0000000100001854 start + > 52 > ) > ?. more > > CGXDisableUpdate: UI updates were forcibly disabled by application > "AsciidocFX" for over 1.00 seconds. Server has re-enabled them. > WindowServer[76]: disable_update_likely_unbalanced: UI updates still > disabled by application "AsciidocFX" after 15.00 seconds (server forcibly > re-enabled them after 1.00 seconds). Likely an unbalanced disableUpdate > call. > What is wrong? > > Thanks > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From johan.vos at gluonhq.com Thu Oct 15 16:42:41 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 15 Oct 2015 18:42:41 +0200 Subject: Scroll Gesture in ListView In-Reply-To: <561FBA45.7080809@media-interactive.de> References: <561FBA45.7080809@media-interactive.de> Message-ID: Hi Werner, The event is first considered for the ListCell, so when the filter on ListView would be called, it is already too late. - Johan On Thu, Oct 15, 2015 at 4:37 PM, Werner Lehmann < lehmann at media-interactive.de> wrote: > Hi Johan, > > wouldn't it be possible to use an event filter on the listview? It would > see (and consume) the event before it even gets to the listcell. > > Werner > > > On 06.10.2015 10:02, Johan Vos wrote: > >> So it seems to me we need something like "gestureTransparent", by which we >> can indicate a Node not to be interested in handling gestures. The code >> for >> picking the target Node currently ignores the Node if it has the >> mouseTransparent set. I would propose to add a gestureTransparent property >> on Node, and to add the following check: >> if we need to find the pickedTarget for a gestureEvent, it should never >> return a node with gestureTransparent set to true. >> > From james.graham at oracle.com Thu Oct 15 19:02:22 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 15 Oct 2015 12:02:22 -0700 Subject: pisces, produceFillAlphas In-Reply-To: References: Message-ID: <561FF83E.3000407@oracle.com> Perhaps optimization flags with the native compiler? Also, was it called a similar number of times on both? Ideally we'd just be using copyArea for the scrolling, but at one point we disabled the scrolling optimizations on retina MBP because they didn't work with a scale factor and I don't think we reenabled them yet. That would kill scrolling performance on mobile as a result of having to rerender the scene on each scroll regardless of how long produceAlphas takes... ...jim On 10/15/15 4:27 AM, Johan Vos wrote: > After spending lots of time optimizing JavaFX on iOS, I am now at the point > where scrolling is 10 times faster on iOS than on Android. > The scrolling in the iOS version of the Gluon JavaOne mobile schedule > builder is pretty good imho. On Android, it is much slower. I profiled and > compared both, and it turns out that on Android, we spend lots of time in > the native implementation of NativePiscesRasterizer.produceFillAlphas > (implemented in native-prism/NativePiscesRasterizer.c) > > On average, calling this native function on an iPhone 6 takes 40,000ns > whereas on a Nexus 6, this takes about 800,000ns. > > If anyone has a suggestion on how to improve or avoid this, I'm all ears. > > Thanks, > > - Johan > From johan.vos at gluonhq.com Thu Oct 15 19:30:45 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 15 Oct 2015 21:30:45 +0200 Subject: pisces, produceFillAlphas In-Reply-To: <561FF83E.3000407@oracle.com> References: <561FF83E.3000407@oracle.com> Message-ID: Thanks Jim. I tried with different optimization flags, but it doesn't make a big difference. Tracing it down to system calls, somehow the gl implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) per invocation. The number of invocations is comparable between iOS and Android. If you can give me a direction on where to search for the disabled scrolling optimization, I'll try to re-enable that and see how it improves performance. It might be a huge and quick win... Thanks again, - Johan On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham wrote: > Perhaps optimization flags with the native compiler? Also, was it called > a similar number of times on both? > > Ideally we'd just be using copyArea for the scrolling, but at one point we > disabled the scrolling optimizations on retina MBP because they didn't work > with a scale factor and I don't think we reenabled them yet. That would > kill scrolling performance on mobile as a result of having to rerender the > scene on each scroll regardless of how long produceAlphas takes... > > ...jim > > > On 10/15/15 4:27 AM, Johan Vos wrote: > >> After spending lots of time optimizing JavaFX on iOS, I am now at the >> point >> where scrolling is 10 times faster on iOS than on Android. >> The scrolling in the iOS version of the Gluon JavaOne mobile schedule >> builder is pretty good imho. On Android, it is much slower. I profiled and >> compared both, and it turns out that on Android, we spend lots of time in >> the native implementation of NativePiscesRasterizer.produceFillAlphas >> (implemented in native-prism/NativePiscesRasterizer.c) >> >> On average, calling this native function on an iPhone 6 takes 40,000ns >> whereas on a Nexus 6, this takes about 800,000ns. >> >> If anyone has a suggestion on how to improve or avoid this, I'm all ears. >> >> Thanks, >> >> - Johan >> >> From richard.bair at oracle.com Thu Oct 15 19:33:44 2015 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 15 Oct 2015 12:33:44 -0700 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> Message-ID: Is it consistent among all android devices, or is it a specific device? > On Oct 15, 2015, at 12:30 PM, Johan Vos wrote: > > Thanks Jim. > I tried with different optimization flags, but it doesn't make a big > difference. Tracing it down to system calls, somehow the gl implementation > seems be be slower (glDrawElements(GL_TRIANGLES, numQuads * 2 * 3, > GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) per > invocation. The number of invocations is comparable between iOS and Android. > > If you can give me a direction on where to search for the disabled > scrolling optimization, I'll try to re-enable that and see how it improves > performance. It might be a huge and quick win... > > Thanks again, > > - Johan > > On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham wrote: > >> Perhaps optimization flags with the native compiler? Also, was it called >> a similar number of times on both? >> >> Ideally we'd just be using copyArea for the scrolling, but at one point we >> disabled the scrolling optimizations on retina MBP because they didn't work >> with a scale factor and I don't think we reenabled them yet. That would >> kill scrolling performance on mobile as a result of having to rerender the >> scene on each scroll regardless of how long produceAlphas takes... >> >> ...jim >> >> >> On 10/15/15 4:27 AM, Johan Vos wrote: >> >>> After spending lots of time optimizing JavaFX on iOS, I am now at the >>> point >>> where scrolling is 10 times faster on iOS than on Android. >>> The scrolling in the iOS version of the Gluon JavaOne mobile schedule >>> builder is pretty good imho. On Android, it is much slower. I profiled and >>> compared both, and it turns out that on Android, we spend lots of time in >>> the native implementation of NativePiscesRasterizer.produceFillAlphas >>> (implemented in native-prism/NativePiscesRasterizer.c) >>> >>> On average, calling this native function on an iPhone 6 takes 40,000ns >>> whereas on a Nexus 6, this takes about 800,000ns. >>> >>> If anyone has a suggestion on how to improve or avoid this, I'm all ears. >>> >>> Thanks, >>> >>> - Johan >>> >>> From johan.vos at gluonhq.com Thu Oct 15 19:35:46 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 15 Oct 2015 21:35:46 +0200 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> Message-ID: At least on the Nexus 5 and Nexus 6 devices. - Johan On Thu, Oct 15, 2015 at 9:33 PM, Richard Bair wrote: > Is it consistent among all android devices, or is it a specific device? > > > On Oct 15, 2015, at 12:30 PM, Johan Vos wrote: > > > > Thanks Jim. > > I tried with different optimization flags, but it doesn't make a big > > difference. Tracing it down to system calls, somehow the gl > implementation > > seems be be slower (glDrawElements(GL_TRIANGLES, numQuads * 2 * 3, > > GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) per > > invocation. The number of invocations is comparable between iOS and > Android. > > > > If you can give me a direction on where to search for the disabled > > scrolling optimization, I'll try to re-enable that and see how it > improves > > performance. It might be a huge and quick win... > > > > Thanks again, > > > > - Johan > > > > On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham > wrote: > > > >> Perhaps optimization flags with the native compiler? Also, was it > called > >> a similar number of times on both? > >> > >> Ideally we'd just be using copyArea for the scrolling, but at one point > we > >> disabled the scrolling optimizations on retina MBP because they didn't > work > >> with a scale factor and I don't think we reenabled them yet. That would > >> kill scrolling performance on mobile as a result of having to rerender > the > >> scene on each scroll regardless of how long produceAlphas takes... > >> > >> ...jim > >> > >> > >> On 10/15/15 4:27 AM, Johan Vos wrote: > >> > >>> After spending lots of time optimizing JavaFX on iOS, I am now at the > >>> point > >>> where scrolling is 10 times faster on iOS than on Android. > >>> The scrolling in the iOS version of the Gluon JavaOne mobile schedule > >>> builder is pretty good imho. On Android, it is much slower. I profiled > and > >>> compared both, and it turns out that on Android, we spend lots of time > in > >>> the native implementation of NativePiscesRasterizer.produceFillAlphas > >>> (implemented in native-prism/NativePiscesRasterizer.c) > >>> > >>> On average, calling this native function on an iPhone 6 takes 40,000ns > >>> whereas on a Nexus 6, this takes about 800,000ns. > >>> > >>> If anyone has a suggestion on how to improve or avoid this, I'm all > ears. > >>> > >>> Thanks, > >>> > >>> - Johan > >>> > >>> > > From chien.yang at oracle.com Thu Oct 15 19:42:28 2015 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 15 Oct 2015 12:42:28 -0700 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> Message-ID: <562001A4.4020604@oracle.com> Hi Johan, This optimization is buggy but to see whether it helps you can try setting -Dprism.scrollcacheopt=true Please see JDK-8093860 for reason why it was disabled: https://bugs.openjdk.java.net/browse/JDK-8093860 - Chien On 10/15/15, 12:30 PM, Johan Vos wrote: > Thanks Jim. > I tried with different optimization flags, but it doesn't make a big > difference. Tracing it down to system calls, somehow the gl implementation > seems be be slower (glDrawElements(GL_TRIANGLES, numQuads * 2 * 3, > GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) per > invocation. The number of invocations is comparable between iOS and Android. > > If you can give me a direction on where to search for the disabled > scrolling optimization, I'll try to re-enable that and see how it improves > performance. It might be a huge and quick win... > > Thanks again, > > - Johan > > On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham wrote: > >> Perhaps optimization flags with the native compiler? Also, was it called >> a similar number of times on both? >> >> Ideally we'd just be using copyArea for the scrolling, but at one point we >> disabled the scrolling optimizations on retina MBP because they didn't work >> with a scale factor and I don't think we reenabled them yet. That would >> kill scrolling performance on mobile as a result of having to rerender the >> scene on each scroll regardless of how long produceAlphas takes... >> >> ...jim >> >> >> On 10/15/15 4:27 AM, Johan Vos wrote: >> >>> After spending lots of time optimizing JavaFX on iOS, I am now at the >>> point >>> where scrolling is 10 times faster on iOS than on Android. >>> The scrolling in the iOS version of the Gluon JavaOne mobile schedule >>> builder is pretty good imho. On Android, it is much slower. I profiled and >>> compared both, and it turns out that on Android, we spend lots of time in >>> the native implementation of NativePiscesRasterizer.produceFillAlphas >>> (implemented in native-prism/NativePiscesRasterizer.c) >>> >>> On average, calling this native function on an iPhone 6 takes 40,000ns >>> whereas on a Nexus 6, this takes about 800,000ns. >>> >>> If anyone has a suggestion on how to improve or avoid this, I'm all ears. >>> >>> Thanks, >>> >>> - Johan >>> >>> From james.graham at oracle.com Thu Oct 15 22:18:07 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 15 Oct 2015 15:18:07 -0700 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> Message-ID: <5620261F.7060206@oracle.com> Chien pointed out a system property that is currently disabling the scrolling optimization. For its implementation look at CacheFilter.java, in particular the invalidateByTranslation() method and all that it kicks off. Another thing to look at is that we added alpha batching to the code which should be batching all of the output of the produceAlphas calls into a texture and then drawing all of the quads together - provided that they are all being filled with simple colors (they can have alpha, but they can't be gradients, etc.). This should be managed by the BaseContext.updateMaskTexture() method which controls the single batch texture. Again, are there similar number of invocations of the glDrawElements on the 2 platforms? ...jim On 10/15/15 12:30 PM, Johan Vos wrote: > Thanks Jim. > I tried with different optimization flags, but it doesn't make a big > difference. Tracing it down to system calls, somehow the gl > implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads > * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) > per invocation. The number of invocations is comparable between iOS and > Android. > > If you can give me a direction on where to search for the disabled > scrolling optimization, I'll try to re-enable that and see how it > improves performance. It might be a huge and quick win... > > Thanks again, > > - Johan > > On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham > wrote: > > Perhaps optimization flags with the native compiler? Also, was it > called a similar number of times on both? > > Ideally we'd just be using copyArea for the scrolling, but at one > point we disabled the scrolling optimizations on retina MBP because > they didn't work with a scale factor and I don't think we reenabled > them yet. That would kill scrolling performance on mobile as a > result of having to rerender the scene on each scroll regardless of > how long produceAlphas takes... > > ...jim > > > On 10/15/15 4:27 AM, Johan Vos wrote: > > After spending lots of time optimizing JavaFX on iOS, I am now > at the point > where scrolling is 10 times faster on iOS than on Android. > The scrolling in the iOS version of the Gluon JavaOne mobile > schedule > builder is pretty good imho. On Android, it is much slower. I > profiled and > compared both, and it turns out that on Android, we spend lots > of time in > the native implementation of > NativePiscesRasterizer.produceFillAlphas > (implemented in native-prism/NativePiscesRasterizer.c) > > On average, calling this native function on an iPhone 6 takes > 40,000ns > whereas on a Nexus 6, this takes about 800,000ns. > > If anyone has a suggestion on how to improve or avoid this, I'm > all ears. > > Thanks, > > - Johan > > From james.graham at oracle.com Thu Oct 15 22:18:50 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 15 Oct 2015 15:18:50 -0700 Subject: pisces, produceFillAlphas In-Reply-To: <5620261F.7060206@oracle.com> References: <561FF83E.3000407@oracle.com> <5620261F.7060206@oracle.com> Message-ID: <5620264A.8050303@oracle.com> Ignore that last question - I just realized that you already answered it, my apologies... ...jim On 10/15/15 3:18 PM, Jim Graham wrote: > Chien pointed out a system property that is currently disabling the > scrolling optimization. For its implementation look at > CacheFilter.java, in particular the invalidateByTranslation() method and > all that it kicks off. > > Another thing to look at is that we added alpha batching to the code > which should be batching all of the output of the produceAlphas calls > into a texture and then drawing all of the quads together - provided > that they are all being filled with simple colors (they can have alpha, > but they can't be gradients, etc.). This should be managed by the > BaseContext.updateMaskTexture() method which controls the single batch > texture. > > Again, are there similar number of invocations of the glDrawElements on > the 2 platforms? > > ...jim > > On 10/15/15 12:30 PM, Johan Vos wrote: >> Thanks Jim. >> I tried with different optimization flags, but it doesn't make a big >> difference. Tracing it down to system calls, somehow the gl >> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads >> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) >> per invocation. The number of invocations is comparable between iOS and >> Android. >> >> If you can give me a direction on where to search for the disabled >> scrolling optimization, I'll try to re-enable that and see how it >> improves performance. It might be a huge and quick win... >> >> Thanks again, >> >> - Johan >> >> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham > > wrote: >> >> Perhaps optimization flags with the native compiler? Also, was it >> called a similar number of times on both? >> >> Ideally we'd just be using copyArea for the scrolling, but at one >> point we disabled the scrolling optimizations on retina MBP because >> they didn't work with a scale factor and I don't think we reenabled >> them yet. That would kill scrolling performance on mobile as a >> result of having to rerender the scene on each scroll regardless of >> how long produceAlphas takes... >> >> ...jim >> >> >> On 10/15/15 4:27 AM, Johan Vos wrote: >> >> After spending lots of time optimizing JavaFX on iOS, I am now >> at the point >> where scrolling is 10 times faster on iOS than on Android. >> The scrolling in the iOS version of the Gluon JavaOne mobile >> schedule >> builder is pretty good imho. On Android, it is much slower. I >> profiled and >> compared both, and it turns out that on Android, we spend lots >> of time in >> the native implementation of >> NativePiscesRasterizer.produceFillAlphas >> (implemented in native-prism/NativePiscesRasterizer.c) >> >> On average, calling this native function on an iPhone 6 takes >> 40,000ns >> whereas on a Nexus 6, this takes about 800,000ns. >> >> If anyone has a suggestion on how to improve or avoid this, I'm >> all ears. >> >> Thanks, >> >> - Johan >> >> From hemmerling at gmx.net Fri Oct 16 11:54:25 2015 From: hemmerling at gmx.net (Rolf Hemmerling) Date: Fri, 16 Oct 2015 13:54:25 +0200 Subject: Feature request: DirectX Support for Java3D / JavaFX on Windows & "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX in a way, that OpenGL1-only computers are not excluded from any function" Message-ID: <5620E571.6040100@gmx.net> Hello Java3D / JavaFX core developers! Feature request: 1. DirectX Support for Java3D / JavaFX on Windows 2. "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX in a way, that OpenGL1-only computers are not excluded from any function, and OpenGL2 computers benefit from better look of the visual view" ( but have no "exclusive" commands which don?t compile or generate runtime errors with OpenGL1 systems ). 3. Let the end user ( not the Java application developer) select between DirectX and OpenGL - similar to the choice available with the 3D engine "Unity3d". Reason: 1. The Past: 10-15 years ago, standard desktop PCs were used for gaming on Windows too, so with state-of-the-art graphics cards ( with 64-256 MB RAM ) the graphics card manufacurers provided state-of-the-art graphics drivers (OpenGL1, DirectX). 2. Nowadays: 2.1 most PCs running Windows use standard graphics drivers supplied by Microsoft ( especially for "legacy" computers, especially after upgrade of the operating system, e.g. Vista -> Win7 -> Win8 > Win10, especially for busines PCs which are not gamer PCs, e.g. notebooks with non-dedicated graphics cards ), and not by the graphics card manufacturers AMD & NVidia. 2.2 Microsoft's standard drivers supplied win Win7 / Win8 support still OpenGL1 and DirectX ( by installation of a DirectX runtime), but usually not OpenGL2. There is no option to upgrade a PC by installing a (newer) OpenGL1 or OpenGL2 driver. 2.3 Even with some Macintosh PCs, there is some lack of (advanced) OpenGL2 support I was told by the team which develop "Processing" ( see below ) 3. My observations & opinion: 3.1 Directx9 is standard on the Windows platform since 15 years ( works with all AGP graphics cards and first generations of PCIExpress graphics cards, and any non-dedicated graphics cards of notebooks ), while DirectX 10 / 11 / 12 is just upgrade available for gamer PCs. Request: So if there should be DirectX for Java3D / JavaFX on Windows, then it should be full support of DirectX9, and optional use of DirectX 10 /11 /12. 3.2 OpenGL1 is outdated ( does not make use of advanced hardware graphics functions,.. ) but supported by almost all PCs. OpenGL 2.0 is not available with most PCs running Windows, while running Ubuntu Linux on the same machine offers such support in some cases even on the same hardware. OpenGL 2.0 is even not available to some current Macintosh PCs My case: I installed http://www.processing.org/ http://www.github.com/processing/ , a Java application with special OpenGL1 libraries ( Processing 1.5.1 ) and special OpenGL2 libraries ( Processign 2.2.1 and newer ) 3.2.1 Processing 1.5.1, using OpenGL1: The 3D demo applications works fine on all my Windows computers 3.2.2 Processing 2.2.1, using OpenGL2: 3.2.1.1 The demo applications of the folder ?Camera?, ?Demos? - and maybe some others, but not all - crash by the Java error message ?Framebuffer objects are not supported by this hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues for help? , on my 1. ?Athlon XP2400? desktop computer with NVIDIA GeForce 6600 graphics card and webcam, with Win7 . 2. Notebook ?Dell Vostro 1000?, with Win8.1 . 3. Notebook ?ASUS Eee PC T101MT?, with Win8.1 . 3.2.1.2 The demo applications work well on my 1. Notebook ?Dell Vostro 1000?, with Ubuntu Linux 14 LTE . See above, its the same hardware, just other operating system. ****************** The Processing developers gives some explanations about the use of OpenGL .. https://github.com/processing/processing/wiki/OpenGL-Issues and why / that OpenGL2 is not a standard for most PCs, both Windows-hardware and even some Macintosh-hardware. And they point to the fact, that OpenGL2 support for "older" PCs is not available with Linux too... ****************** So they just don?t support all my computers with their new Processing 2.2.1 version, and its successors Processing 3,.. My statement: Java3D / JavaFX is not for gamers, but also for business graphics, so missing "state of the art 3D power" is no reason not to provide full 3D support - usual Java applications are not counted by "frames / second". And JavaFX is for business menu applications too! 4. Feature request: Please let check your JavaFX / Java3D API, if it uses the OpenGL Framebuffer feature in a way, so that Java error message ?Framebuffer objects are not supported by this hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues for help? might happen too. If so, please fix that. Find a way to support both: 4.1 OpenGl1 ( for legacy and business PCs, or PCs which were just "upgraded" with a new Windows where the graphics card manufacturer doesn?t provide specific graphics drivers and so you are stuck to Microsoft's standard drivers ), 4.2 and OpenGL2 with the same library - so give full power of Java3D / JavaFX even for OpenGL1 computers without need to adopt the software, but give more speed or better / prettier view to those users which have an OpenGL2 computer. In case of the "Processing" platform, the small team states that they don?t have enough manpower to do that. Ok. But please Java-Developer team, don?t use that as excuse for the "big" Java3D / JavaFX development. 5. Warning: If I should ever see a message "Java error message ?Framebuffer objects are not supported by this hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues for help? with a business or technical software which by this prevents me from using, on my PCs, as end-user of the software on a state-of-the-art operating system ( currently Win7, Win8, Win10 ) - even if my PC is legacy but properly running this operating system -, I would be very dissatisfied, and this would make anger against Java definitely probably not just with me. Remember that it is/was "normal" to exclude people from using software, in the Windows world, by claiming "oh it just works on W2k / WinXp / Win7, please buy a new computer or upgrade your operating system". Well this urging doesn?t work with Java, the Java communmity is not in the position to demand to buy "openGL2 compatible hardware", if it lacks in the shops, especially with budget offers. From that point of view, "Processing" is dead for me, though intended for education ( of kid, pupils, students ), who cares if the 3D graphics doesn?t run on most computers ( owned by the kids, pupils, students,..)? Do you want the teacher ask the parents "oh buy another new computer or change the operating system, as the computer with which your child is coming to the classroom, doesn?t support OpenGL2, so its a garbage and worthless. Without another computer with OpenGL support the pupil can?t participate in our computer course" ?! Yes I want to start a flame.... in the mind of Java3D / JavaFX developers :-). OpenGL is dead.. ist doesn?t just smell funny. Sincerely Rolf Hemmerling -- http://www.hemmerling.com SCADA Expertness - Quality Intensification for IT + Automation Member of Texas Instruments Expert Advisory Panel CeBIT Competence Store Partner From vadim.pakhnushev at oracle.com Fri Oct 16 14:30:11 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 16 Oct 2015 17:30:11 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <562109F3.1000901@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From johan.vos at gluonhq.com Fri Oct 16 17:55:18 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 16 Oct 2015 19:55:18 +0200 Subject: pisces, produceFillAlphas In-Reply-To: <5620261F.7060206@oracle.com> References: <561FF83E.3000407@oracle.com> <5620261F.7060206@oracle.com> Message-ID: Hi, Thanks for the suggestions. There are 2 different things: 1. It seems indeed there is not much being cached, so there are definitely improvements possible. It also require e.g. VirtualFlow to use the Node.setCache(true) in order to cache. The combination of this with the prism.scrollcacheopt reduces the rendering calls. I think the only penalty is memory, but so far, we didn't run into issues with too high GC activity. 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns). I'll have to look into some EGL options. - Johan On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham wrote: > Chien pointed out a system property that is currently disabling the > scrolling optimization. For its implementation look at CacheFilter.java, > in particular the invalidateByTranslation() method and all that it kicks > off. > > Another thing to look at is that we added alpha batching to the code which > should be batching all of the output of the produceAlphas calls into a > texture and then drawing all of the quads together - provided that they are > all being filled with simple colors (they can have alpha, but they can't be > gradients, etc.). This should be managed by the > BaseContext.updateMaskTexture() method which controls the single batch > texture. > > Again, are there similar number of invocations of the glDrawElements on > the 2 platforms? > > ...jim > > On 10/15/15 12:30 PM, Johan Vos wrote: > >> Thanks Jim. >> I tried with different optimization flags, but it doesn't make a big >> difference. Tracing it down to system calls, somehow the gl >> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads >> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) >> per invocation. The number of invocations is comparable between iOS and >> Android. >> >> If you can give me a direction on where to search for the disabled >> scrolling optimization, I'll try to re-enable that and see how it >> improves performance. It might be a huge and quick win... >> >> Thanks again, >> >> - Johan >> >> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham > > wrote: >> >> Perhaps optimization flags with the native compiler? Also, was it >> called a similar number of times on both? >> >> Ideally we'd just be using copyArea for the scrolling, but at one >> point we disabled the scrolling optimizations on retina MBP because >> they didn't work with a scale factor and I don't think we reenabled >> them yet. That would kill scrolling performance on mobile as a >> result of having to rerender the scene on each scroll regardless of >> how long produceAlphas takes... >> >> ...jim >> >> >> On 10/15/15 4:27 AM, Johan Vos wrote: >> >> After spending lots of time optimizing JavaFX on iOS, I am now >> at the point >> where scrolling is 10 times faster on iOS than on Android. >> The scrolling in the iOS version of the Gluon JavaOne mobile >> schedule >> builder is pretty good imho. On Android, it is much slower. I >> profiled and >> compared both, and it turns out that on Android, we spend lots >> of time in >> the native implementation of >> NativePiscesRasterizer.produceFillAlphas >> (implemented in native-prism/NativePiscesRasterizer.c) >> >> On average, calling this native function on an iPhone 6 takes >> 40,000ns >> whereas on a Nexus 6, this takes about 800,000ns. >> >> If anyone has a suggestion on how to improve or avoid this, I'm >> all ears. >> >> Thanks, >> >> - Johan >> >> >> From johan.vos at gluonhq.com Sat Oct 17 08:49:46 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 17 Oct 2015 10:49:46 +0200 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> <5620261F.7060206@oracle.com> Message-ID: As a follow-up on the second part: after about 2 years working on JavaFX on Android, I discovered we are not even using Hardware Acceleration. We create a SurfaceView and render on that, but it turns out SurfaceView is never Hardware Accelerated. The positive thing is that this means there is even more room for optimization :) - Johan On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos wrote: > Hi, > > Thanks for the suggestions. There are 2 different things: > > 1. It seems indeed there is not much being cached, so there are definitely > improvements possible. It also require e.g. VirtualFlow to use the > Node.setCache(true) in order to cache. The combination of this with the > prism.scrollcacheopt reduces the rendering calls. I think the only penalty > is memory, but so far, we didn't run into issues with too high GC activity. > > 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times > longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns). > I'll have to look into some EGL options. > > - Johan > > > On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham > wrote: > >> Chien pointed out a system property that is currently disabling the >> scrolling optimization. For its implementation look at CacheFilter.java, >> in particular the invalidateByTranslation() method and all that it kicks >> off. >> >> Another thing to look at is that we added alpha batching to the code >> which should be batching all of the output of the produceAlphas calls into >> a texture and then drawing all of the quads together - provided that they >> are all being filled with simple colors (they can have alpha, but they >> can't be gradients, etc.). This should be managed by the >> BaseContext.updateMaskTexture() method which controls the single batch >> texture. >> >> Again, are there similar number of invocations of the glDrawElements on >> the 2 platforms? >> >> ...jim >> >> On 10/15/15 12:30 PM, Johan Vos wrote: >> >>> Thanks Jim. >>> I tried with different optimization flags, but it doesn't make a big >>> difference. Tracing it down to system calls, somehow the gl >>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads >>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) >>> per invocation. The number of invocations is comparable between iOS and >>> Android. >>> >>> If you can give me a direction on where to search for the disabled >>> scrolling optimization, I'll try to re-enable that and see how it >>> improves performance. It might be a huge and quick win... >>> >>> Thanks again, >>> >>> - Johan >>> >>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham >> > wrote: >>> >>> Perhaps optimization flags with the native compiler? Also, was it >>> called a similar number of times on both? >>> >>> Ideally we'd just be using copyArea for the scrolling, but at one >>> point we disabled the scrolling optimizations on retina MBP because >>> they didn't work with a scale factor and I don't think we reenabled >>> them yet. That would kill scrolling performance on mobile as a >>> result of having to rerender the scene on each scroll regardless of >>> how long produceAlphas takes... >>> >>> ...jim >>> >>> >>> On 10/15/15 4:27 AM, Johan Vos wrote: >>> >>> After spending lots of time optimizing JavaFX on iOS, I am now >>> at the point >>> where scrolling is 10 times faster on iOS than on Android. >>> The scrolling in the iOS version of the Gluon JavaOne mobile >>> schedule >>> builder is pretty good imho. On Android, it is much slower. I >>> profiled and >>> compared both, and it turns out that on Android, we spend lots >>> of time in >>> the native implementation of >>> NativePiscesRasterizer.produceFillAlphas >>> (implemented in native-prism/NativePiscesRasterizer.c) >>> >>> On average, calling this native function on an iPhone 6 takes >>> 40,000ns >>> whereas on a Nexus 6, this takes about 800,000ns. >>> >>> If anyone has a suggestion on how to improve or avoid this, I'm >>> all ears. >>> >>> Thanks, >>> >>> - Johan >>> >>> >>> > From john2011uk at gmail.com Sat Oct 17 09:44:17 2015 From: john2011uk at gmail.com (John Maton) Date: Sat, 17 Oct 2015 11:44:17 +0200 Subject: WebKit Cache Message-ID: I have been trying to implement a disc based cache for WebView but with only partial success, I am particularly trying to cache the .js javascript external files which slow down the loading of javascript web pages a lot. The Oracle documentation states that: "When working with the WebView component, you should remember that it has the default in-memory cache. It means that any cached content is lost once the application containing the WebView component is closed. However, developers can implement cache at the application level by means of the java.net.ResponseCache class. " but this is not the case. I implemented an in-memory cache using the java.net.ResponseCache class but it is very rarely used by WebView - from time to time it stores and retrieves favicon.png from the cache - no performance gain. I confirmed by analysing the net traffic that WebView is not caching, thus confirming what is stated in JDK-8014501: "While navigating with JavaFX WebView component javafx.scene.web.WebView, it was found, that every request retrieves all resources from the server each time even if previous activities have just retrieved the resources. This behaviour was verified by capturing and analyzing the network traffic. The performance impact is considerable. " nothing seems to have come out of JDK-8014501, so I then wrote a cache handler using "URL.setURLStreamHandlerFactory" to intercept all URLConnections to the default sun handler. I had some success with this and was able to cache .js javascript files and increase performance significantly, but there were bugs on a few web sites, notably Outlook's email. On looking into the way my code was handled, I found for example that the URLLoader code was setting setUsesCaches(false) with the following comments in the code (at line 279 of URLLoader.java in current 1.8.0_66 code): // Given that WebKit has its own cache, do not use // any URLConnection caches, even if someone installs them. // As a side effect, this fixes the problem of WebPane not // working well with the plug-in cache, which was one of // the causes for RT-11880. So can somebody out there please give me a heads up on what is really going on? - Oracle documentation says WebKit has an in-memory cache which can be overriden by ResponseCache, this is not the case. - JDK-8014501 states the problem, but has been flagged "not an issue". Why is it not an issue? - signifant coding around "URL.setURLStreamHandlerFactory" and "URLConnection" interception produces a functional cache with significant performance gains, but is undone by problems deliberately introduced into URLLoader code. Thanks in advance for any feedback, John Maton From felix.bembrick at gmail.com Sun Oct 18 08:01:49 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sun, 18 Oct 2015 19:01:49 +1100 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> <5620261F.7060206@oracle.com> Message-ID: Hi Johan, If you have been getting acceptable but not stunning performance on Android and all this time hardware acceleration was not being utilised then it sounds like there is some serious room for some dramatic performance increases. Not being that familiar with the finer points of how JavaFX is implemented on Android, just how much work is involved in accessing that hardware acceleration? Any timeline? I expect that implementing this significant change could be a make-or-break factor in determining whether JavaFX is truly viable and successful on Android. Good luck Johan! Cheers, Felix > On 17 Oct 2015, at 19:49, Johan Vos wrote: > > As a follow-up on the second part: after about 2 years working on JavaFX on > Android, I discovered we are not even using Hardware Acceleration. We > create a SurfaceView and render on that, but it turns out SurfaceView is > never Hardware Accelerated. The positive thing is that this means there is > even more room for optimization :) > > - Johan > >> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos wrote: >> >> Hi, >> >> Thanks for the suggestions. There are 2 different things: >> >> 1. It seems indeed there is not much being cached, so there are definitely >> improvements possible. It also require e.g. VirtualFlow to use the >> Node.setCache(true) in order to cache. The combination of this with the >> prism.scrollcacheopt reduces the rendering calls. I think the only penalty >> is memory, but so far, we didn't run into issues with too high GC activity. >> >> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times >> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns). >> I'll have to look into some EGL options. >> >> - Johan >> >> >> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham >> wrote: >> >>> Chien pointed out a system property that is currently disabling the >>> scrolling optimization. For its implementation look at CacheFilter.java, >>> in particular the invalidateByTranslation() method and all that it kicks >>> off. >>> >>> Another thing to look at is that we added alpha batching to the code >>> which should be batching all of the output of the produceAlphas calls into >>> a texture and then drawing all of the quads together - provided that they >>> are all being filled with simple colors (they can have alpha, but they >>> can't be gradients, etc.). This should be managed by the >>> BaseContext.updateMaskTexture() method which controls the single batch >>> texture. >>> >>> Again, are there similar number of invocations of the glDrawElements on >>> the 2 platforms? >>> >>> ...jim >>> >>>> On 10/15/15 12:30 PM, Johan Vos wrote: >>>> >>>> Thanks Jim. >>>> I tried with different optimization flags, but it doesn't make a big >>>> difference. Tracing it down to system calls, somehow the gl >>>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads >>>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) >>>> per invocation. The number of invocations is comparable between iOS and >>>> Android. >>>> >>>> If you can give me a direction on where to search for the disabled >>>> scrolling optimization, I'll try to re-enable that and see how it >>>> improves performance. It might be a huge and quick win... >>>> >>>> Thanks again, >>>> >>>> - Johan >>>> >>>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham >>> > wrote: >>>> >>>> Perhaps optimization flags with the native compiler? Also, was it >>>> called a similar number of times on both? >>>> >>>> Ideally we'd just be using copyArea for the scrolling, but at one >>>> point we disabled the scrolling optimizations on retina MBP because >>>> they didn't work with a scale factor and I don't think we reenabled >>>> them yet. That would kill scrolling performance on mobile as a >>>> result of having to rerender the scene on each scroll regardless of >>>> how long produceAlphas takes... >>>> >>>> ...jim >>>> >>>> >>>> On 10/15/15 4:27 AM, Johan Vos wrote: >>>> >>>> After spending lots of time optimizing JavaFX on iOS, I am now >>>> at the point >>>> where scrolling is 10 times faster on iOS than on Android. >>>> The scrolling in the iOS version of the Gluon JavaOne mobile >>>> schedule >>>> builder is pretty good imho. On Android, it is much slower. I >>>> profiled and >>>> compared both, and it turns out that on Android, we spend lots >>>> of time in >>>> the native implementation of >>>> NativePiscesRasterizer.produceFillAlphas >>>> (implemented in native-prism/NativePiscesRasterizer.c) >>>> >>>> On average, calling this native function on an iPhone 6 takes >>>> 40,000ns >>>> whereas on a Nexus 6, this takes about 800,000ns. >>>> >>>> If anyone has a suggestion on how to improve or avoid this, I'm >>>> all ears. >>>> >>>> Thanks, >>>> >>>> - Johan >> From pedro.duquevieira at gmail.com Mon Oct 19 16:58:07 2015 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 19 Oct 2015 17:58:07 +0100 Subject: Arabic text in webview Message-ID: Hi, Arabic text is not displaying correctly in webview., go to " https://twitter.com/muttardi" you'll see the characters appearing each in its own line, now compare that with the output from google chrome. Is this a known issue? I wanted to file a bug report but I can't log in, it says:"Account is inaccessible until email address is verified." I don't recall having received any email to verify the email address of my account. Thanks, best regards, -- Pedro Duque Vieira From kevin.rushforth at oracle.com Mon Oct 19 19:54:01 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 19 Oct 2015 12:54:01 -0700 Subject: Arabic text in webview In-Reply-To: References: Message-ID: <56254A59.6030005@oracle.com> I don't see a bug filed against this, but I can confirm that it is broken as you say. If you don't get your login issue resolved in the next couple of days, let me know and I'll file the bug. -- Kevin Pedro Duque Vieira wrote: > Hi, > > Arabic text is not displaying correctly in webview., go to " > https://twitter.com/muttardi" you'll see the characters appearing each in > its own line, now compare that with the output from google chrome. > Is this a known issue? > > I wanted to file a bug report but I can't log in, it says:"Account is > inaccessible until email address is verified." I don't recall having > received any email to verify the email address of my account. > > Thanks, best regards, > > From kevin.rushforth at oracle.com Mon Oct 19 19:58:40 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 19 Oct 2015 12:58:40 -0700 (PDT) Subject: 9-dev unlocked following sanity testing Message-ID: <56254B70.2040801@oracle.com> From danno.ferrin at oracle.com Mon Oct 19 20:02:15 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Mon, 19 Oct 2015 14:02:15 -0600 Subject: [sandbox-9-jake] Review Request 8080531 - fix ant-javafx ant tasks Message-ID: Kevin, Chris, Dmitry Because of the way resources are being handled in current revs of Jake we need to pull the main ant task classes back into ant-javafx and not deploy them into the main packager module. Properly exported in module-info.java all of the other classes are just fine. It touches the build.gradle hence the need for Kevin's vote. This patch adds the notion of a set of classes to exclude from the generated module. FXPackager then excludes the ant classes from the module and makes sure those are the only classes included in ant-javafx.jar. Fairly straightforward (for once). webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.05/ supporting jira: https://bugs.openjdk.java.net/browse/JDK-8080531 From kevin.rushforth at oracle.com Mon Oct 19 20:04:40 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 19 Oct 2015 13:04:40 -0700 Subject: [sandbox-9-jake] Review Request 8080531 - fix ant-javafx ant tasks In-Reply-To: References: Message-ID: <56254CD8.1030508@oracle.com> Looks fine to me. +1 -- Kevin Danno Ferrin wrote: > Kevin, Chris, Dmitry > Because of the way resources are being handled in current revs of > Jake we need to pull the main ant task classes back into ant-javafx > and not deploy them into the main packager module. Properly exported > in module-info.java all of the other classes are just fine. It > touches the build.gradle hence the need for Kevin's vote. > > This patch adds the notion of a set of classes to exclude from the > generated module. FXPackager then excludes the ant classes from the > module and makes sure those are the only classes included in > ant-javafx.jar. Fairly straightforward (for once). > > webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.05/ > > supporting jira: https://bugs.openjdk.java.net/browse/JDK-8080531 From dmitry.cherepanov at oracle.com Mon Oct 19 20:22:51 2015 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 19 Oct 2015 23:22:51 +0300 Subject: [sandbox-9-jake] Review Request 8080531 - fix ant-javafx ant tasks In-Reply-To: References: Message-ID: <5625511B.5000408@oracle.com> Looks fine to me. Dmitry On 10/19/15 11:02 PM, Danno Ferrin wrote: > Kevin, Chris, Dmitry > Because of the way resources are being handled in current revs of > Jake we need to pull the main ant task classes back into ant-javafx > and not deploy them into the main packager module. Properly exported > in module-info.java all of the other classes are just fine. It > touches the build.gradle hence the need for Kevin's vote. > > This patch adds the notion of a set of classes to exclude from the > generated module. FXPackager then excludes the ant classes from the > module and makes sure those are the only classes included in > ant-javafx.jar. Fairly straightforward (for once). > > webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.05/ > > supporting jira: https://bugs.openjdk.java.net/browse/JDK-8080531 From chris.bensen at oracle.com Mon Oct 19 20:22:10 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Mon, 19 Oct 2015 13:22:10 -0700 Subject: [sandbox-9-jake] Review Request 8080531 - fix ant-javafx ant tasks In-Reply-To: References: Message-ID: <22506F13-E5B2-4935-BF7A-9081AAD1D3E5@oracle.com> +1 Chris > On Oct 19, 2015, at 1:02 PM, Danno Ferrin wrote: > > Kevin, Chris, Dmitry > Because of the way resources are being handled in current revs of Jake we need to pull the main ant task classes back into ant-javafx and not deploy them into the main packager module. Properly exported in module-info.java all of the other classes are just fine. It touches the build.gradle hence the need for Kevin's vote. > > This patch adds the notion of a set of classes to exclude from the generated module. FXPackager then excludes the ant classes from the module and makes sure those are the only classes included in ant-javafx.jar. Fairly straightforward (for once). > > webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.05/ > supporting jira: https://bugs.openjdk.java.net/browse/JDK-8080531 From tom.schindl at bestsolution.at Tue Oct 20 13:12:20 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 20 Oct 2015 15:12:20 +0200 Subject: Feature request: DirectX Support for Java3D / JavaFX on Windows & "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX in a way, that OpenGL1-only computers are not excluded from any function" In-Reply-To: <5620E571.6040100@gmx.net> References: <5620E571.6040100@gmx.net> Message-ID: <56263DB4.40602@bestsolution.at> Hi, I've to admit that I could not follow you completely but JavaFX on Windows is based on DirectX (OpenGL is only provided for Linux/OS-X where it is the defacto standard and far from dead). Tom On 16.10.15 13:54, Rolf Hemmerling wrote: > Hello Java3D / JavaFX core developers! > > Feature request: > 1. DirectX Support for Java3D / JavaFX on Windows > 2. "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX > in a way, that OpenGL1-only computers are not excluded from any > function, and OpenGL2 computers benefit from better look of the visual > view" ( but have no "exclusive" commands which don?t compile or generate > runtime errors with OpenGL1 systems ). > 3. Let the end user ( not the Java application developer) select between > DirectX and OpenGL - similar to the choice available with the 3D engine > "Unity3d". > > Reason: > 1. The Past: > 10-15 years ago, standard desktop PCs were used for gaming on Windows > too, so with state-of-the-art graphics cards ( with 64-256 MB RAM ) the > graphics card manufacurers provided state-of-the-art graphics drivers > (OpenGL1, DirectX). > > 2. Nowadays: > 2.1 most PCs running Windows use standard graphics drivers supplied by > Microsoft ( especially for "legacy" computers, especially after upgrade > of the operating system, e.g. Vista -> Win7 -> Win8 > Win10, especially > for busines PCs which are not gamer PCs, e.g. notebooks with > non-dedicated graphics cards ), and not by the graphics card > manufacturers AMD & NVidia. > 2.2 Microsoft's standard drivers supplied win Win7 / Win8 support still > OpenGL1 and DirectX ( by installation of a DirectX runtime), but usually > not OpenGL2. There is no option to upgrade a PC by installing a (newer) > OpenGL1 or OpenGL2 driver. > 2.3 Even with some Macintosh PCs, there is some lack of (advanced) > OpenGL2 support I was told by the team which develop "Processing" ( see > below ) > > 3. My observations & opinion: > 3.1 > Directx9 is standard on the Windows platform since 15 years ( works with > all AGP graphics cards and first generations of PCIExpress graphics > cards, and any non-dedicated graphics cards of notebooks ), while > DirectX 10 / 11 / 12 is just upgrade available for gamer PCs. > > Request: So if there should be DirectX for Java3D / JavaFX on Windows, > then it should be full support of DirectX9, and optional use of DirectX > 10 /11 /12. > > 3.2 > OpenGL1 is outdated ( does not make use of advanced hardware graphics > functions,.. ) but supported by almost all PCs. > OpenGL 2.0 is not available with most PCs running Windows, while running > Ubuntu Linux on the same machine offers such support in some cases even > on the same hardware. > OpenGL 2.0 is even not available to some current Macintosh PCs > > My case: > I installed > http://www.processing.org/ > http://www.github.com/processing/ > , a Java application with special OpenGL1 libraries ( Processing 1.5.1 ) > and special OpenGL2 libraries ( Processign 2.2.1 and newer ) > > 3.2.1 > Processing 1.5.1, using OpenGL1: > The 3D demo applications works fine on all my Windows computers > > 3.2.2 > Processing 2.2.1, using OpenGL2: > 3.2.1.1 > The demo applications of the folder ?Camera?, ?Demos? - and maybe some > others, but not all - crash by the Java error message > > ?Framebuffer objects are not supported by this hardware (or driver) Read > http://wiki.processing.org/w/OpenGL_Issues for help? > > , on my > 1. ?Athlon XP2400? desktop computer with NVIDIA GeForce 6600 graphics > card and webcam, with Win7 . > 2. Notebook ?Dell Vostro 1000?, with Win8.1 . > 3. Notebook ?ASUS Eee PC T101MT?, with Win8.1 . > > 3.2.1.2 > The demo applications work well on my > 1. Notebook ?Dell Vostro 1000?, with Ubuntu Linux 14 LTE . > See above, its the same hardware, just other operating system. > > ****************** > The Processing developers gives some explanations about the use of > OpenGL .. > https://github.com/processing/processing/wiki/OpenGL-Issues > and why / that OpenGL2 is not a standard for most PCs, both > Windows-hardware and even some Macintosh-hardware. And they point to the > fact, that OpenGL2 support for "older" PCs is not available with Linux > too... > ****************** > So they just don?t support all my computers with their new Processing > 2.2.1 version, and its successors Processing 3,.. > > My statement: Java3D / JavaFX is not for gamers, but also for business > graphics, so missing "state of the art 3D power" is no reason not to > provide full 3D support - usual Java applications are not counted by > "frames / second". And JavaFX is for business menu applications too! > > 4. > Feature request: Please let check your JavaFX / Java3D API, if it uses > the OpenGL Framebuffer feature in a way, so that Java error message > ?Framebuffer objects are not supported by this hardware (or driver) Read > http://wiki.processing.org/w/OpenGL_Issues for help? > might happen too. If so, please fix that. > > Find a way to support both: > > 4.1 OpenGl1 ( for legacy and business PCs, or PCs which were just > "upgraded" with a new Windows where the graphics card manufacturer > doesn?t provide specific graphics drivers and so you are stuck to > Microsoft's standard drivers ), > > 4.2 and OpenGL2 with the same library - so give full power of Java3D / > JavaFX even for OpenGL1 computers without need to adopt the software, > but give more speed or better / prettier view to those users which have > an OpenGL2 computer. > > In case of the "Processing" platform, the small team states that they > don?t have enough manpower to do that. Ok. But please Java-Developer > team, don?t use that as excuse for the "big" Java3D / JavaFX development. > > 5. Warning: > If I should ever see a message > "Java error message ?Framebuffer objects are not supported by this > hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues for > help? > with a business or technical software which by this prevents me from > using, on my PCs, as end-user of the software on a state-of-the-art > operating system ( currently Win7, Win8, Win10 ) - even if my PC is > legacy but properly running this operating system -, I would be very > dissatisfied, and this would make anger against Java definitely probably > not just with me. > > Remember that it is/was "normal" to exclude people from using software, > in the Windows world, by claiming "oh it just works on W2k / WinXp / > Win7, please buy a new computer or upgrade your operating system". > Well this urging doesn?t work with Java, the Java communmity is not in > the position to demand to buy "openGL2 compatible hardware", if it lacks > in the shops, especially with budget offers. > > From that point of view, "Processing" is dead for me, though intended > for education ( of kid, pupils, students ), who cares if the 3D graphics > doesn?t run on most computers ( owned by the kids, pupils, students,..)? > Do you want the teacher ask the parents "oh buy another new computer or > change the operating system, as the computer with which your child is > coming to the classroom, doesn?t support OpenGL2, so its a garbage and > worthless. Without another computer with OpenGL support the pupil can?t > participate in our computer course" ?! > > Yes I want to start a flame.... in the mind of Java3D / JavaFX > developers :-). > OpenGL is dead.. ist doesn?t just smell funny. > > Sincerely > Rolf Hemmerling -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From chien.yang at oracle.com Tue Oct 20 18:29:28 2015 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 20 Oct 2015 11:29:28 -0700 Subject: Feature request: DirectX Support for Java3D / JavaFX on Windows & "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX in a way, that OpenGL1-only computers are not excluded from any function" In-Reply-To: <56263DB4.40602@bestsolution.at> References: <5620E571.6040100@gmx.net> <56263DB4.40602@bestsolution.at> Message-ID: <56268808.3070407@oracle.com> And by default Java 3D uses D3D on Windows too. - Chien On 10/20/15, 6:12 AM, Tom Schindl wrote: > Hi, > > I've to admit that I could not follow you completely but JavaFX on > Windows is based on DirectX (OpenGL is only provided for Linux/OS-X > where it is the defacto standard and far from dead). > > Tom > > On 16.10.15 13:54, Rolf Hemmerling wrote: >> Hello Java3D / JavaFX core developers! >> >> Feature request: >> 1. DirectX Support for Java3D / JavaFX on Windows >> 2. "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX >> in a way, that OpenGL1-only computers are not excluded from any >> function, and OpenGL2 computers benefit from better look of the visual >> view" ( but have no "exclusive" commands which don?t compile or generate >> runtime errors with OpenGL1 systems ). >> 3. Let the end user ( not the Java application developer) select between >> DirectX and OpenGL - similar to the choice available with the 3D engine >> "Unity3d". >> >> Reason: >> 1. The Past: >> 10-15 years ago, standard desktop PCs were used for gaming on Windows >> too, so with state-of-the-art graphics cards ( with 64-256 MB RAM ) the >> graphics card manufacurers provided state-of-the-art graphics drivers >> (OpenGL1, DirectX). >> >> 2. Nowadays: >> 2.1 most PCs running Windows use standard graphics drivers supplied by >> Microsoft ( especially for "legacy" computers, especially after upgrade >> of the operating system, e.g. Vista -> Win7 -> Win8> Win10, especially >> for busines PCs which are not gamer PCs, e.g. notebooks with >> non-dedicated graphics cards ), and not by the graphics card >> manufacturers AMD& NVidia. >> 2.2 Microsoft's standard drivers supplied win Win7 / Win8 support still >> OpenGL1 and DirectX ( by installation of a DirectX runtime), but usually >> not OpenGL2. There is no option to upgrade a PC by installing a (newer) >> OpenGL1 or OpenGL2 driver. >> 2.3 Even with some Macintosh PCs, there is some lack of (advanced) >> OpenGL2 support I was told by the team which develop "Processing" ( see >> below ) >> >> 3. My observations& opinion: >> 3.1 >> Directx9 is standard on the Windows platform since 15 years ( works with >> all AGP graphics cards and first generations of PCIExpress graphics >> cards, and any non-dedicated graphics cards of notebooks ), while >> DirectX 10 / 11 / 12 is just upgrade available for gamer PCs. >> >> Request: So if there should be DirectX for Java3D / JavaFX on Windows, >> then it should be full support of DirectX9, and optional use of DirectX >> 10 /11 /12. >> >> 3.2 >> OpenGL1 is outdated ( does not make use of advanced hardware graphics >> functions,.. ) but supported by almost all PCs. >> OpenGL 2.0 is not available with most PCs running Windows, while running >> Ubuntu Linux on the same machine offers such support in some cases even >> on the same hardware. >> OpenGL 2.0 is even not available to some current Macintosh PCs >> >> My case: >> I installed >> http://www.processing.org/ >> http://www.github.com/processing/ >> , a Java application with special OpenGL1 libraries ( Processing 1.5.1 ) >> and special OpenGL2 libraries ( Processign 2.2.1 and newer ) >> >> 3.2.1 >> Processing 1.5.1, using OpenGL1: >> The 3D demo applications works fine on all my Windows computers >> >> 3.2.2 >> Processing 2.2.1, using OpenGL2: >> 3.2.1.1 >> The demo applications of the folder ?Camera?, ?Demos? - and maybe some >> others, but not all - crash by the Java error message >> >> ?Framebuffer objects are not supported by this hardware (or driver) Read >> http://wiki.processing.org/w/OpenGL_Issues for help? >> >> , on my >> 1. ?Athlon XP2400? desktop computer with NVIDIA GeForce 6600 graphics >> card and webcam, with Win7 . >> 2. Notebook ?Dell Vostro 1000?, with Win8.1 . >> 3. Notebook ?ASUS Eee PC T101MT?, with Win8.1 . >> >> 3.2.1.2 >> The demo applications work well on my >> 1. Notebook ?Dell Vostro 1000?, with Ubuntu Linux 14 LTE . >> See above, its the same hardware, just other operating system. >> >> ****************** >> The Processing developers gives some explanations about the use of >> OpenGL .. >> https://github.com/processing/processing/wiki/OpenGL-Issues >> and why / that OpenGL2 is not a standard for most PCs, both >> Windows-hardware and even some Macintosh-hardware. And they point to the >> fact, that OpenGL2 support for "older" PCs is not available with Linux >> too... >> ****************** >> So they just don?t support all my computers with their new Processing >> 2.2.1 version, and its successors Processing 3,.. >> >> My statement: Java3D / JavaFX is not for gamers, but also for business >> graphics, so missing "state of the art 3D power" is no reason not to >> provide full 3D support - usual Java applications are not counted by >> "frames / second". And JavaFX is for business menu applications too! >> >> 4. >> Feature request: Please let check your JavaFX / Java3D API, if it uses >> the OpenGL Framebuffer feature in a way, so that Java error message >> ?Framebuffer objects are not supported by this hardware (or driver) Read >> http://wiki.processing.org/w/OpenGL_Issues for help? >> might happen too. If so, please fix that. >> >> Find a way to support both: >> >> 4.1 OpenGl1 ( for legacy and business PCs, or PCs which were just >> "upgraded" with a new Windows where the graphics card manufacturer >> doesn?t provide specific graphics drivers and so you are stuck to >> Microsoft's standard drivers ), >> >> 4.2 and OpenGL2 with the same library - so give full power of Java3D / >> JavaFX even for OpenGL1 computers without need to adopt the software, >> but give more speed or better / prettier view to those users which have >> an OpenGL2 computer. >> >> In case of the "Processing" platform, the small team states that they >> don?t have enough manpower to do that. Ok. But please Java-Developer >> team, don?t use that as excuse for the "big" Java3D / JavaFX development. >> >> 5. Warning: >> If I should ever see a message >> "Java error message ?Framebuffer objects are not supported by this >> hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues for >> help? >> with a business or technical software which by this prevents me from >> using, on my PCs, as end-user of the software on a state-of-the-art >> operating system ( currently Win7, Win8, Win10 ) - even if my PC is >> legacy but properly running this operating system -, I would be very >> dissatisfied, and this would make anger against Java definitely probably >> not just with me. >> >> Remember that it is/was "normal" to exclude people from using software, >> in the Windows world, by claiming "oh it just works on W2k / WinXp / >> Win7, please buy a new computer or upgrade your operating system". >> Well this urging doesn?t work with Java, the Java communmity is not in >> the position to demand to buy "openGL2 compatible hardware", if it lacks >> in the shops, especially with budget offers. >> >> From that point of view, "Processing" is dead for me, though intended >> for education ( of kid, pupils, students ), who cares if the 3D graphics >> doesn?t run on most computers ( owned by the kids, pupils, students,..)? >> Do you want the teacher ask the parents "oh buy another new computer or >> change the operating system, as the computer with which your child is >> coming to the classroom, doesn?t support OpenGL2, so its a garbage and >> worthless. Without another computer with OpenGL support the pupil can?t >> participate in our computer course" ?! >> >> Yes I want to start a flame.... in the mind of Java3D / JavaFX >> developers :-). >> OpenGL is dead.. ist doesn?t just smell funny. >> >> Sincerely >> Rolf Hemmerling > From kevin.rushforth at oracle.com Tue Oct 20 20:20:55 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Oct 2015 13:20:55 -0700 Subject: Changes for October 2015 CPU release (8u65/8u66) synced into FX 8u-dev and 9-dev Message-ID: <5626A227.7070102@oracle.com> I have synced the OpenJFX changes from the just-released October 2015 CPU release (8u65/8u66) into 8u and into 9. Here is a webrev of the FX 8u66 changes for those who are interested in the changes, but don't want to wade through the 79 separate changesets I just pushed (most of which are tag or merge changesets). http://cr.openjdk.java.net/~kcr/8u66-8u-sync/webrev/ The webrev for 9 is almost identical, but here it is if anyone is interested: http://cr.openjdk.java.net/~kcr/9-cpu-1504-sync/webrev/ -- Kevin From kevin.rushforth at oracle.com Tue Oct 20 21:58:40 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 20 Oct 2015 14:58:40 -0700 Subject: Feature request: DirectX Support for Java3D / JavaFX on Windows & "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX in a way, that OpenGL1-only computers are not excluded from any function" In-Reply-To: <56268808.3070407@oracle.com> References: <5620E571.6040100@gmx.net> <56263DB4.40602@bestsolution.at> <56268808.3070407@oracle.com> Message-ID: <5626B910.8080901@oracle.com> I couldn't quite parse what was being asked for, either, but here is what we use for JavaFX on the 3 desktop platforms that we support: Windows: DirectX 9.0c (fall back to SW on very old machines) Mac: OpenGL 2.x Linux: OpenGL 2.x (fall back to SW on old machines or out of date drivers) We do not presently have an OpenGL 1.x pipeline, nor do we ever plan to do this. -- Kevin Chien Yang wrote: > And by default Java 3D uses D3D on Windows too. > > - Chien > > On 10/20/15, 6:12 AM, Tom Schindl wrote: >> Hi, >> >> I've to admit that I could not follow you completely but JavaFX on >> Windows is based on DirectX (OpenGL is only provided for Linux/OS-X >> where it is the defacto standard and far from dead). >> >> Tom >> >> On 16.10.15 13:54, Rolf Hemmerling wrote: >>> Hello Java3D / JavaFX core developers! >>> >>> Feature request: >>> 1. DirectX Support for Java3D / JavaFX on Windows >>> 2. "Take care that OpenGL1 and OpenGL2 are supported by Java3D / JavaFX >>> in a way, that OpenGL1-only computers are not excluded from any >>> function, and OpenGL2 computers benefit from better look of the visual >>> view" ( but have no "exclusive" commands which don?t compile or >>> generate >>> runtime errors with OpenGL1 systems ). >>> 3. Let the end user ( not the Java application developer) select >>> between >>> DirectX and OpenGL - similar to the choice available with the 3D engine >>> "Unity3d". >>> >>> Reason: >>> 1. The Past: >>> 10-15 years ago, standard desktop PCs were used for gaming on Windows >>> too, so with state-of-the-art graphics cards ( with 64-256 MB RAM ) the >>> graphics card manufacurers provided state-of-the-art graphics drivers >>> (OpenGL1, DirectX). >>> >>> 2. Nowadays: >>> 2.1 most PCs running Windows use standard graphics drivers supplied by >>> Microsoft ( especially for "legacy" computers, especially after upgrade >>> of the operating system, e.g. Vista -> Win7 -> Win8> Win10, >>> especially >>> for busines PCs which are not gamer PCs, e.g. notebooks with >>> non-dedicated graphics cards ), and not by the graphics card >>> manufacturers AMD& NVidia. >>> 2.2 Microsoft's standard drivers supplied win Win7 / Win8 support still >>> OpenGL1 and DirectX ( by installation of a DirectX runtime), but >>> usually >>> not OpenGL2. There is no option to upgrade a PC by installing a (newer) >>> OpenGL1 or OpenGL2 driver. >>> 2.3 Even with some Macintosh PCs, there is some lack of (advanced) >>> OpenGL2 support I was told by the team which develop "Processing" ( see >>> below ) >>> >>> 3. My observations& opinion: >>> 3.1 >>> Directx9 is standard on the Windows platform since 15 years ( works >>> with >>> all AGP graphics cards and first generations of PCIExpress graphics >>> cards, and any non-dedicated graphics cards of notebooks ), while >>> DirectX 10 / 11 / 12 is just upgrade available for gamer PCs. >>> >>> Request: So if there should be DirectX for Java3D / JavaFX on Windows, >>> then it should be full support of DirectX9, and optional use of DirectX >>> 10 /11 /12. >>> >>> 3.2 >>> OpenGL1 is outdated ( does not make use of advanced hardware graphics >>> functions,.. ) but supported by almost all PCs. >>> OpenGL 2.0 is not available with most PCs running Windows, while >>> running >>> Ubuntu Linux on the same machine offers such support in some cases even >>> on the same hardware. >>> OpenGL 2.0 is even not available to some current Macintosh PCs >>> >>> My case: >>> I installed >>> http://www.processing.org/ >>> http://www.github.com/processing/ >>> , a Java application with special OpenGL1 libraries ( Processing >>> 1.5.1 ) >>> and special OpenGL2 libraries ( Processign 2.2.1 and newer ) >>> >>> 3.2.1 >>> Processing 1.5.1, using OpenGL1: >>> The 3D demo applications works fine on all my Windows computers >>> >>> 3.2.2 >>> Processing 2.2.1, using OpenGL2: >>> 3.2.1.1 >>> The demo applications of the folder ?Camera?, ?Demos? - and maybe some >>> others, but not all - crash by the Java error message >>> >>> ?Framebuffer objects are not supported by this hardware (or driver) >>> Read >>> http://wiki.processing.org/w/OpenGL_Issues for help? >>> >>> , on my >>> 1. ?Athlon XP2400? desktop computer with NVIDIA GeForce 6600 graphics >>> card and webcam, with Win7 . >>> 2. Notebook ?Dell Vostro 1000?, with Win8.1 . >>> 3. Notebook ?ASUS Eee PC T101MT?, with Win8.1 . >>> >>> 3.2.1.2 >>> The demo applications work well on my >>> 1. Notebook ?Dell Vostro 1000?, with Ubuntu Linux 14 LTE . >>> See above, its the same hardware, just other operating system. >>> >>> ****************** >>> The Processing developers gives some explanations about the use of >>> OpenGL .. >>> https://github.com/processing/processing/wiki/OpenGL-Issues >>> and why / that OpenGL2 is not a standard for most PCs, both >>> Windows-hardware and even some Macintosh-hardware. And they point to >>> the >>> fact, that OpenGL2 support for "older" PCs is not available with Linux >>> too... >>> ****************** >>> So they just don?t support all my computers with their new Processing >>> 2.2.1 version, and its successors Processing 3,.. >>> >>> My statement: Java3D / JavaFX is not for gamers, but also for business >>> graphics, so missing "state of the art 3D power" is no reason not to >>> provide full 3D support - usual Java applications are not counted by >>> "frames / second". And JavaFX is for business menu applications too! >>> >>> 4. >>> Feature request: Please let check your JavaFX / Java3D API, if it uses >>> the OpenGL Framebuffer feature in a way, so that Java error message >>> ?Framebuffer objects are not supported by this hardware (or driver) >>> Read >>> http://wiki.processing.org/w/OpenGL_Issues for help? >>> might happen too. If so, please fix that. >>> >>> Find a way to support both: >>> >>> 4.1 OpenGl1 ( for legacy and business PCs, or PCs which were just >>> "upgraded" with a new Windows where the graphics card manufacturer >>> doesn?t provide specific graphics drivers and so you are stuck to >>> Microsoft's standard drivers ), >>> >>> 4.2 and OpenGL2 with the same library - so give full power of Java3D / >>> JavaFX even for OpenGL1 computers without need to adopt the software, >>> but give more speed or better / prettier view to those users which have >>> an OpenGL2 computer. >>> >>> In case of the "Processing" platform, the small team states that they >>> don?t have enough manpower to do that. Ok. But please Java-Developer >>> team, don?t use that as excuse for the "big" Java3D / JavaFX >>> development. >>> >>> 5. Warning: >>> If I should ever see a message >>> "Java error message ?Framebuffer objects are not supported by this >>> hardware (or driver) Read http://wiki.processing.org/w/OpenGL_Issues >>> for >>> help? >>> with a business or technical software which by this prevents me from >>> using, on my PCs, as end-user of the software on a state-of-the-art >>> operating system ( currently Win7, Win8, Win10 ) - even if my PC is >>> legacy but properly running this operating system -, I would be very >>> dissatisfied, and this would make anger against Java definitely >>> probably >>> not just with me. >>> >>> Remember that it is/was "normal" to exclude people from using software, >>> in the Windows world, by claiming "oh it just works on W2k / WinXp / >>> Win7, please buy a new computer or upgrade your operating system". >>> Well this urging doesn?t work with Java, the Java communmity is not in >>> the position to demand to buy "openGL2 compatible hardware", if it >>> lacks >>> in the shops, especially with budget offers. >>> >>> From that point of view, "Processing" is dead for me, though intended >>> for education ( of kid, pupils, students ), who cares if the 3D >>> graphics >>> doesn?t run on most computers ( owned by the kids, pupils, >>> students,..)? >>> Do you want the teacher ask the parents "oh buy another new >>> computer or >>> change the operating system, as the computer with which your child is >>> coming to the classroom, doesn?t support OpenGL2, so its a garbage and >>> worthless. Without another computer with OpenGL support the pupil can?t >>> participate in our computer course" ?! >>> >>> Yes I want to start a flame.... in the mind of Java3D / JavaFX >>> developers :-). >>> OpenGL is dead.. ist doesn?t just smell funny. >>> >>> Sincerely >>> Rolf Hemmerling >> From arunprasad.rajkumar at oracle.com Wed Oct 21 11:18:09 2015 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 21 Oct 2015 16:48:09 +0530 Subject: [9, 8u] review request: 8090292 Test transitions/created-while-suspended.html fails Message-ID: <56277471.6050301@oracle.com> Hi Kevin, Alexander, Please review the fix related to DumpRenderTree. JIRA: https://bugs.openjdk.java.net/browse/JDK-8090292 Webrev: http://cr.openjdk.java.net/~rchamyal/arunprasad/8090292/webrev.00/ Regards, Arun From vadim.pakhnushev at oracle.com Fri Oct 23 14:30:18 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 23 Oct 2015 17:30:18 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <562A447A.7020700@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From morris.meyer at oracle.com Fri Oct 23 19:54:27 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Fri, 23 Oct 2015 15:54:27 -0400 Subject: [9] Review request for 8134366: Modena sample shouldn't access internal JavaFX resources Message-ID: <562A9073.9000601@oracle.com> Kevin and Jonathan, Please review my changes to Modena that allow it to work with the Jake-JavaFX build. Thanks much, --morris meyer BUG - https://bugs.openjdk.java.net/browse/JDK-8134366 WEBREV - http://cr.openjdk.java.net/~morris/JDK-8134366.03 From neugens.limasoftware at gmail.com Mon Oct 26 03:06:57 2015 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 26 Oct 2015 04:06:57 +0100 Subject: Lunch, dinner, anyone? Message-ID: Hi all, Is there going to be a lunch/dinner/breakfast/beer/something like last year at JavaOne? I didn't see any email on the mailing list (but I've been a bit off lately so I probably just missed this). Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From jonathan.giles at oracle.com Mon Oct 26 03:47:55 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sun, 25 Oct 2015 20:47:55 -0700 Subject: Lunch, dinner, anyone? In-Reply-To: References: Message-ID: <562DA26B.6070702@oracle.com> I have organised a lunch as per usual. Email me off-list for the details. -- Jonathan On 25/10/2015 8:06 p.m., Mario Torre wrote: > Hi all, > > Is there going to be a lunch/dinner/breakfast/beer/something like last > year at JavaOne? I didn't see any email on the mailing list (but I've > been a bit off lately so I probably just missed this). > > Cheers, > Mario From kevin.rushforth at oracle.com Mon Oct 26 13:54:31 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 26 Oct 2015 06:54:31 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: <562A447A.7020700@oracle.com> References: <562A447A.7020700@oracle.com> Message-ID: <562E3097.60102@oracle.com> Due to JavaOne I won't be online to send the "unlock" message at 1pm PDT today, so please consider it unlocked at that time. Also, testing might be a little light today because of JavaOne, which should be fine since only 1 change -- the fix for 8089424 -- has gone in since last week's build (the syncing in of the changes for the October CPU release was integrated into the build for last week). -- Kevin Vadim Pakhnushev wrote: > Reminder, Monday is our weekly sanity testing. > > You can find your testing assignment at: > https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing > > Also please remember that the repo will be locked from 1am PDT until > 1pm PDT. > > Happy testing! > > Thanks, > Vadim From felix.bembrick at gmail.com Wed Oct 28 06:24:38 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 28 Oct 2015 17:24:38 +1100 Subject: Windows Hi-DPI Message-ID: <94CE475E-320E-4B81-82F7-5BDBFEEA3386@gmail.com> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. Is this because Hi-DPI is not yet supported in JavaFX on Windows? Thanks, Fix From brianfromoregon at gmail.com Thu Oct 29 21:58:07 2015 From: brianfromoregon at gmail.com (Brian Harris) Date: Thu, 29 Oct 2015 14:58:07 -0700 Subject: Fx questions Message-ID: Hi fx devs, a few questions. - for unit testing on Linux servers, is monocle a good bet? I got it working by adding monocle jar to ext classpath - when embedding html5 pages into fx apps, should we expect it to render/behave similar to popular browsers like chrome? I'm wondering if we can expect this to just work or if things may be a bit wonky. - do you have a public roadmap for fx? - what is your recommendation for lifecycle management, ie creating controllers with injected dependencies. I saw afterburner looked nice, we have spring working too. - what is status of scenebuilder? Is it supported, and still worked on? Thanks, Brian From hastebrot at gmail.com Thu Oct 29 22:21:27 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Thu, 29 Oct 2015 23:21:27 +0100 Subject: Fx questions In-Reply-To: References: Message-ID: Hi Brian! > for unit testing on Linux servers, is monocle a good bet? In case you simulate user input (mouse, keyboard, touch) you need to use the Glass robot instead of AWT robot when using Monocle. I observed some different behaviour and timing problems in my tests with Glass robot. >when embedding html5 pages into fx apps, should we expect it to render/behave similar to popular browsers like chrome? AFAIK JavaFX just uses the Webkit rendering engine, so rendering should be more or less exactly like Chrome (they use their fork Blink, but there are not that much differences, yet). For JavaScript execution the Nashorn JS engine is used. >do you have a public roadmap for fx? I guess there is some information on the OpenJFX project page. >what is status of scenebuilder? Is it supported, and still worked on? I saw some commits in the SceneBuilder repository in the last few days. Binaries are provided by Gluon. Regards, Benjamin On Thu, Oct 29, 2015 at 10:58 PM, Brian Harris wrote: > Hi fx devs, a few questions. > > - for unit testing on Linux servers, is monocle a good bet? I got it > working by adding monocle jar to ext classpath > > - when embedding html5 pages into fx apps, should we expect it to > render/behave similar to popular browsers like chrome? I'm wondering if we > can expect this to just work or if things may be a bit wonky. > > - do you have a public roadmap for fx? > > - what is your recommendation for lifecycle management, ie creating > controllers with injected dependencies. I saw afterburner looked nice, we > have spring working too. > > - what is status of scenebuilder? Is it supported, and still worked on? > > Thanks, > Brian > From kevin.rushforth at oracle.com Thu Oct 29 22:27:56 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 29 Oct 2015 15:27:56 -0700 Subject: Fx questions In-Reply-To: References: Message-ID: <56329D6C.9090108@oracle.com> One correction. We do not use Nashorn as the JS engine for WebView. There is an RFE to switch to Nashorn, but it is untargeted. See https://bugs.openjdk.java.net/browse/JDK-8091505 Also, the roadmap is a bit out of date. We'll update it in the next few days with the information we presented at JavaOne. -- Kevin Benjamin Gudehus wrote: > Hi Brian! > > >> for unit testing on Linux servers, is monocle a good bet? >> > > In case you simulate user input (mouse, keyboard, touch) you need to use > the Glass robot instead of AWT robot when using Monocle. I observed some > different behaviour and timing problems in my tests with Glass robot. > > >> when embedding html5 pages into fx apps, should we expect it to >> > render/behave similar to popular browsers like chrome? > > AFAIK JavaFX just uses the Webkit rendering engine, so rendering should be > more or less exactly like Chrome (they use their fork Blink, but there are > not that much differences, yet). For JavaScript execution the Nashorn JS > engine is used. > > >> do you have a public roadmap for fx? >> > > I guess there is some information on the OpenJFX project page. > > >> what is status of scenebuilder? Is it supported, and still worked on? >> > > I saw some commits in the SceneBuilder repository in the last few days. > Binaries are provided by Gluon. > > Regards, > Benjamin > > > > > On Thu, Oct 29, 2015 at 10:58 PM, Brian Harris > wrote: > > >> Hi fx devs, a few questions. >> >> - for unit testing on Linux servers, is monocle a good bet? I got it >> working by adding monocle jar to ext classpath >> >> - when embedding html5 pages into fx apps, should we expect it to >> render/behave similar to popular browsers like chrome? I'm wondering if we >> can expect this to just work or if things may be a bit wonky. >> >> - do you have a public roadmap for fx? >> >> - what is your recommendation for lifecycle management, ie creating >> controllers with injected dependencies. I saw afterburner looked nice, we >> have spring working too. >> >> - what is status of scenebuilder? Is it supported, and still worked on? >> >> Thanks, >> Brian >> >> From steve at weblite.ca Fri Oct 30 01:02:14 2015 From: steve at weblite.ca (Steve Hannah) Date: Thu, 29 Oct 2015 18:02:14 -0700 Subject: Fx questions In-Reply-To: <56329D6C.9090108@oracle.com> References: <56329D6C.9090108@oracle.com> Message-ID: There are some missing javascript APIs in the JavaFX web view. Here is a blog post I wrote a while back on some of my experiments with it. http://sjhannah.com/blog/?p=404 Steve On Thu, Oct 29, 2015 at 3:27 PM, Kevin Rushforth wrote: > One correction. We do not use Nashorn as the JS engine for WebView. There > is an RFE to switch to Nashorn, but it is untargeted. See > https://bugs.openjdk.java.net/browse/JDK-8091505 > > Also, the roadmap is a bit out of date. We'll update it in the next few > days with the information we presented at JavaOne. > > -- Kevin > > > > Benjamin Gudehus wrote: > >> Hi Brian! >> >> >> >>> for unit testing on Linux servers, is monocle a good bet? >>> >>> >> >> In case you simulate user input (mouse, keyboard, touch) you need to use >> the Glass robot instead of AWT robot when using Monocle. I observed some >> different behaviour and timing problems in my tests with Glass robot. >> >> >> >>> when embedding html5 pages into fx apps, should we expect it to >>> >>> >> render/behave similar to popular browsers like chrome? >> >> AFAIK JavaFX just uses the Webkit rendering engine, so rendering should be >> more or less exactly like Chrome (they use their fork Blink, but there are >> not that much differences, yet). For JavaScript execution the Nashorn JS >> engine is used. >> >> >> >>> do you have a public roadmap for fx? >>> >>> >> >> I guess there is some information on the OpenJFX project page. >> >> >> >>> what is status of scenebuilder? Is it supported, and still worked on? >>> >>> >> >> I saw some commits in the SceneBuilder repository in the last few days. >> Binaries are provided by Gluon. >> >> Regards, >> Benjamin >> >> >> >> >> On Thu, Oct 29, 2015 at 10:58 PM, Brian Harris > > >> wrote: >> >> >> >>> Hi fx devs, a few questions. >>> >>> - for unit testing on Linux servers, is monocle a good bet? I got it >>> working by adding monocle jar to ext classpath >>> >>> - when embedding html5 pages into fx apps, should we expect it to >>> render/behave similar to popular browsers like chrome? I'm wondering if >>> we >>> can expect this to just work or if things may be a bit wonky. >>> >>> - do you have a public roadmap for fx? >>> >>> - what is your recommendation for lifecycle management, ie creating >>> controllers with injected dependencies. I saw afterburner looked nice, we >>> have spring working too. >>> >>> - what is status of scenebuilder? Is it supported, and still worked on? >>> >>> Thanks, >>> Brian >>> >>> >>> >> -- Steve Hannah Web Lite Solutions Corp. From chris.nahr at gmail.com Fri Oct 30 06:33:57 2015 From: chris.nahr at gmail.com (Chris Nahr) Date: Fri, 30 Oct 2015 07:33:57 +0100 Subject: Windows Hi-DPI In-Reply-To: References: Message-ID: <56330F55.4050407@gmail.com> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. Cheers, Chris On 2015-10-28 17:24:38, Felix Bembrick wrote: > I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. > > Is this because Hi-DPI is not yet supported in JavaFX on Windows? > > Thanks, > > Fix From mp at jugs.org Fri Oct 30 08:14:09 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 30 Oct 2015 09:14:09 +0100 Subject: Fx questions In-Reply-To: References: Message-ID: <563326D1.3000309@jugs.org> Am 29.10.15 um 22:58 schrieb Brian Harris: > - when embedding html5 pages into fx apps, should we expect it to > render/behave similar to popular browsers like chrome? I'm wondering if we > can expect this to just work or if things may be a bit wonky. In theory it is just Webkit and as such it should behave like any popular browser and in many cases it does. However, I have stumbled over several pages where this is not the case and sometimes it even depends on the system you are running your application on. It may work on Windows but fail on a Mac Retina. Your best bet is to just give it a try with the pages that are important for you and see how it behaves. Here are a few pages where I have problems with. https://www.google.com/maps - (enters "Lite-Mode" because of unsupported features.) https://www.youtube.com - (I am not able to watch any video there. Same on vimeo.) https://www.windyty.com - (No wind trails on MacBook Pro Retina.) (Tested with JDK 8u66-b17) From felix.bembrick at gmail.com Fri Oct 30 08:19:33 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 30 Oct 2015 19:19:33 +1100 Subject: Windows Hi-DPI In-Reply-To: <56330F55.4050407@gmail.com> References: <56330F55.4050407@gmail.com> Message-ID: <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> I am using Java 8u66 and performance is really poor. I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. Any ideas? Felix > On 30 Oct 2015, at 17:33, Chris Nahr wrote: > > Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. > > However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. > > Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. > > Cheers, Chris > > >> On 2015-10-28 17:24:38, Felix Bembrick wrote: >> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >> >> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >> >> Thanks, >> >> Fix > From chris.nahr at gmail.com Fri Oct 30 08:44:19 2015 From: chris.nahr at gmail.com (Chris Nahr) Date: Fri, 30 Oct 2015 09:44:19 +0100 Subject: Windows Hi-DPI In-Reply-To: <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> Message-ID: <56332DE3.1060008@gmail.com> If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? --Chris On 2015-10-30 09:19, Felix Bembrick wrote: > I am using Java 8u66 and performance is really poor. > > I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. > > It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? > > It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. > > All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. > > Any ideas? > > Felix > >> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >> >> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >> >> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >> >> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >> >> Cheers, Chris >> >> >>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>> >>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>> >>> Thanks, >>> >>> Fix >> From felix.bembrick at gmail.com Fri Oct 30 08:47:00 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 30 Oct 2015 19:47:00 +1100 Subject: Windows Hi-DPI In-Reply-To: <56332DE3.1060008@gmail.com> References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> <56332DE3.1060008@gmail.com> Message-ID: That's curious. SLI is designed specifically with gamers in mind! I'll investigating running without SLI and report back. Felix > On 30 Oct 2015, at 19:44, Chris Nahr wrote: > > If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? > > --Chris > >> On 2015-10-30 09:19, Felix Bembrick wrote: >> I am using Java 8u66 and performance is really poor. >> >> I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. >> >> It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? >> >> It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. >> >> All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. >> >> Any ideas? >> >> Felix >> >>> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >>> >>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >>> >>> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >>> >>> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >>> >>> Cheers, Chris >>> >>> >>>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>>> >>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>> >>>> Thanks, >>>> >>>> Fix >>> From john2011uk at gmail.com Fri Oct 30 09:37:21 2015 From: john2011uk at gmail.com (John Maton) Date: Fri, 30 Oct 2015 10:37:21 +0100 Subject: Fx questions In-Reply-To: <563326D1.3000309@jugs.org> References: <563326D1.3000309@jugs.org> Message-ID: JDK 8u72 (1.8.0_72-ea) makes a big difference here. Using 8u66 I was not able to see any HTML5 videos on youtube, they all reverted to Flash. 8u72 makes it all work, last time I checked I was unable to find a video on youtube which did not work. You can download 8u72 at https://jdk8.java.net/download.html Best regards, John Maton On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus wrote: > Am 29.10.15 um 22:58 schrieb Brian Harris: > >> - when embedding html5 pages into fx apps, should we expect it to >> render/behave similar to popular browsers like chrome? I'm wondering if we >> can expect this to just work or if things may be a bit wonky. >> > In theory it is just Webkit and as such it should behave like any popular > browser > and in many cases it does. However, I have stumbled over several pages > where > this is not the case and sometimes it even depends on the system you are > running your application on. It may work on Windows but fail on a Mac > Retina. > > Your best bet is to just give it a try with the pages that are important > for you > and see how it behaves. > > Here are a few pages where I have problems with. > > https://www.google.com/maps - (enters "Lite-Mode" because of unsupported > features.) > > https://www.youtube.com - (I am not able to watch any video there. Same > on vimeo.) > > https://www.windyty.com - (No wind trails on MacBook Pro Retina.) > > (Tested with JDK 8u66-b17) > From mp at jugs.org Fri Oct 30 10:21:27 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 30 Oct 2015 11:21:27 +0100 Subject: Fx questions In-Reply-To: References: <563326D1.3000309@jugs.org> Message-ID: <563344A7.4090609@jugs.org> This is good to know but I just gave it a try on my MacBookPro Retina and it failed. I opened the youtube start page and there was an add at the top (from Porsche :-)) which indeed played a video. Cool! But when I then clicked on the link to close the add java crashed completely. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000000014946489e, pid=4440, tid=87311 # # JRE version: Java(TM) SE Runtime Environment (8.0_72-b05) (build 1.8.0_72-ea-b05) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b05 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libjfxmedia_avf.dylib+0x789e] _ZN18AVFKernelComponent18ProcessBufferListsERjRK15AudioBufferListRS1_j+0x22 # Obviously I'm having sticky fingers or so because I always catch all bugs which are lurking arround. Frustrating. Am 30.10.15 um 10:37 schrieb John Maton: > JDK 8u72 (1.8.0_72-ea) makes a big difference here. > Using 8u66 I was not able to see any HTML5 videos on youtube, they all > reverted to Flash. > 8u72 makes it all work, last time I checked I was unable to find a > video on youtube which did not work. > You can download 8u72 at https://jdk8.java.net/download.html > Best regards, > John Maton > > On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus > wrote: > > Am 29.10.15 um 22:58 schrieb Brian Harris: > > - when embedding html5 pages into fx apps, should we expect it to > render/behave similar to popular browsers like chrome? I'm > wondering if we > can expect this to just work or if things may be a bit wonky. > > In theory it is just Webkit and as such it should behave like any > popular browser > and in many cases it does. However, I have stumbled over several > pages where > this is not the case and sometimes it even depends on the system > you are > running your application on. It may work on Windows but fail on a > Mac Retina. > > Your best bet is to just give it a try with the pages that are > important for you > and see how it behaves. > > Here are a few pages where I have problems with. > > https://www.google.com/maps - (enters "Lite-Mode" because of > unsupported features.) > > https://www.youtube.com - (I am not able to watch any video there. > Same on vimeo.) > > https://www.windyty.com - (No wind trails on MacBook Pro Retina.) > > (Tested with JDK 8u66-b17) > > From john2011uk at gmail.com Fri Oct 30 10:26:58 2015 From: john2011uk at gmail.com (John Maton) Date: Fri, 30 Oct 2015 11:26:58 +0100 Subject: Fx questions In-Reply-To: <563344A7.4090609@jugs.org> References: <563326D1.3000309@jugs.org> <563344A7.4090609@jugs.org> Message-ID: Michael, I am travelling and don't have access to my Apple Mac, I can try when I get back (5.11). I have a friend on Ubuntu and it worked for him. However I have just noticed I am running 8.0_72-b02 so I will try on 8.0_72-b05 later today and let you know if that changes anything Regards John Maton On Fri, Oct 30, 2015 at 11:21 AM, Dr. Michael Paus wrote: > This is good to know but I just gave it a try on my MacBookPro Retina > and it failed. > > I opened the youtube start page and there was an add at the top > (from Porsche :-)) which indeed played a video. Cool! > > But when I then clicked on the link to close the add java crashed > completely. > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x000000014946489e, pid=4440, tid=87311 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_72-b05) (build > 1.8.0_72-ea-b05) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b05 mixed mode > bsd-amd64 compressed oops) > # Problematic frame: > # C [libjfxmedia_avf.dylib+0x789e] > _ZN18AVFKernelComponent18ProcessBufferListsERjRK15AudioBufferListRS1_j+0x22 > # > > Obviously I'm having sticky fingers or so because I always catch all bugs > which are lurking arround. > Frustrating. > > > > Am 30.10.15 um 10:37 schrieb John Maton: > > JDK 8u72 (1.8.0_72-ea) makes a big difference here. > Using 8u66 I was not able to see any HTML5 videos on youtube, they all > reverted to Flash. > 8u72 makes it all work, last time I checked I was unable to find a video > on youtube which did not work. > You can download 8u72 at https://jdk8.java.net/download.html > Best regards, > John Maton > > On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus wrote: > >> Am 29.10.15 um 22:58 schrieb Brian Harris: >> >>> - when embedding html5 pages into fx apps, should we expect it to >>> render/behave similar to popular browsers like chrome? I'm wondering if >>> we >>> can expect this to just work or if things may be a bit wonky. >>> >> In theory it is just Webkit and as such it should behave like any popular >> browser >> and in many cases it does. However, I have stumbled over several pages >> where >> this is not the case and sometimes it even depends on the system you are >> running your application on. It may work on Windows but fail on a Mac >> Retina. >> >> Your best bet is to just give it a try with the pages that are important >> for you >> and see how it behaves. >> >> Here are a few pages where I have problems with. >> >> https://www.google.com/maps - (enters "Lite-Mode" because of unsupported >> features.) >> >> https://www.youtube.com - (I am not able to watch any video there. Same >> on vimeo.) >> >> https://www.windyty.com - (No wind trails on MacBook Pro Retina.) >> >> (Tested with JDK 8u66-b17) >> > > > From felix.bembrick at gmail.com Fri Oct 30 10:55:19 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 30 Oct 2015 21:55:19 +1100 Subject: Windows Hi-DPI In-Reply-To: References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> <56332DE3.1060008@gmail.com> Message-ID: The NVIDIA Control Panel allowed me to disable SLI completely and I even rebooted. I also upgraded to Java 8u72. Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a chain. All other 3D apps, games etc. perform blindingly fast as I would expect. So, if it's not an SLI or driver problem, what is going on here (or not going on)? Felix > On 30 Oct 2015, at 19:47, Felix Bembrick wrote: > > That's curious. SLI is designed specifically with gamers in mind! > > I'll investigating running without SLI and report back. > > Felix > >> On 30 Oct 2015, at 19:44, Chris Nahr wrote: >> >> If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? >> >> --Chris >> >>> On 2015-10-30 09:19, Felix Bembrick wrote: >>> I am using Java 8u66 and performance is really poor. >>> >>> I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. >>> >>> It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? >>> >>> It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. >>> >>> All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. >>> >>> Any ideas? >>> >>> Felix >>> >>>> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >>>> >>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >>>> >>>> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >>>> >>>> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >>>> >>>> Cheers, Chris >>>> >>>> >>>>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>>>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>>>> >>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>>> >>>>> Thanks, >>>>> >>>>> Fix >>>> From robert.fisher.ext at zeiss.com Fri Oct 30 11:07:22 2015 From: robert.fisher.ext at zeiss.com (Fisher, Robert) Date: Fri, 30 Oct 2015 11:07:22 +0000 Subject: Bug when combining ListView and SortedList? Message-ID: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> Hi, I am wondering if this behaviour of ListView's MultipleSelectionModel is correct: ListView listView = new ListView<>(); ObservableList items = FXCollections.observableArrayList(); SortedList sortedItems = new SortedList<>(items); sortedItems.setComparator(String::compareTo); listView.setItems(sortedItems); items.add("2"); listView.getSelectionModel().selectFirst(); items.addAll("1", "3"); System.out.println(listView.getSelectionModel().getSelectedItem()); System.out.println(listView.getSelectionModel().getSelectedItems()); This yields the following console output on JDK 8u66: 2 [1] The "selected item" and "selected items" are out of sync. Interestingly if you attach a ListChangeListener to the selected items list, it only fires once (when selectFirst is called). Is this a bug? Cheers, Rob From john2011uk at gmail.com Fri Oct 30 11:54:11 2015 From: john2011uk at gmail.com (John Maton) Date: Fri, 30 Oct 2015 12:54:11 +0100 Subject: Fx questions In-Reply-To: References: <563326D1.3000309@jugs.org> <563344A7.4090609@jugs.org> Message-ID: Michael - I tried 8.0_72-b05 running on Windows 7 and all the videos I tried on the www.youtube.com home page ran HTML5 and worked fine. This is a big step up from 8.0_66 but I can't get to an Apple Mac at the moment. John Maton On Fri, Oct 30, 2015 at 11:26 AM, John Maton wrote: > Michael, > I am travelling and don't have access to my Apple Mac, I can try when I > get back (5.11). > I have a friend on Ubuntu and it worked for him. > However I have just noticed I am running 8.0_72-b02 > so I will try on 8.0_72-b05 later today and let you know if that changes > anything > Regards > John Maton > > On Fri, Oct 30, 2015 at 11:21 AM, Dr. Michael Paus wrote: > >> This is good to know but I just gave it a try on my MacBookPro Retina >> and it failed. >> >> I opened the youtube start page and there was an add at the top >> (from Porsche :-)) which indeed played a video. Cool! >> >> But when I then clicked on the link to close the add java crashed >> completely. >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x000000014946489e, pid=4440, tid=87311 >> # >> # JRE version: Java(TM) SE Runtime Environment (8.0_72-b05) (build >> 1.8.0_72-ea-b05) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b05 mixed mode >> bsd-amd64 compressed oops) >> # Problematic frame: >> # C [libjfxmedia_avf.dylib+0x789e] >> _ZN18AVFKernelComponent18ProcessBufferListsERjRK15AudioBufferListRS1_j+0x22 >> # >> >> Obviously I'm having sticky fingers or so because I always catch all bugs >> which are lurking arround. >> Frustrating. >> >> >> >> Am 30.10.15 um 10:37 schrieb John Maton: >> >> JDK 8u72 (1.8.0_72-ea) makes a big difference here. >> Using 8u66 I was not able to see any HTML5 videos on youtube, they all >> reverted to Flash. >> 8u72 makes it all work, last time I checked I was unable to find a video >> on youtube which did not work. >> You can download 8u72 at https://jdk8.java.net/download.html >> Best regards, >> John Maton >> >> On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus wrote: >> >>> Am 29.10.15 um 22:58 schrieb Brian Harris: >>> >>>> - when embedding html5 pages into fx apps, should we expect it to >>>> render/behave similar to popular browsers like chrome? I'm wondering if >>>> we >>>> can expect this to just work or if things may be a bit wonky. >>>> >>> In theory it is just Webkit and as such it should behave like any >>> popular browser >>> and in many cases it does. However, I have stumbled over several pages >>> where >>> this is not the case and sometimes it even depends on the system you are >>> running your application on. It may work on Windows but fail on a Mac >>> Retina. >>> >>> Your best bet is to just give it a try with the pages that are important >>> for you >>> and see how it behaves. >>> >>> Here are a few pages where I have problems with. >>> >>> https://www.google.com/maps - (enters "Lite-Mode" because of >>> unsupported features.) >>> >>> https://www.youtube.com - (I am not able to watch any video there. Same >>> on vimeo.) >>> >>> https://www.windyty.com - (No wind trails on MacBook Pro Retina.) >>> >>> (Tested with JDK 8u66-b17) >>> >> >> >> > From swpalmer at gmail.com Fri Oct 30 13:37:41 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 30 Oct 2015 09:37:41 -0400 Subject: Bug when combining ListView and SortedList? In-Reply-To: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> References: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> Message-ID: That looks like a bug to me. Please report it. On Fri, Oct 30, 2015 at 7:07 AM, Fisher, Robert wrote: > Hi, > > I am wondering if this behaviour of ListView's MultipleSelectionModel is > correct: > > > ListView listView = new ListView<>(); > ObservableList items = FXCollections.observableArrayList(); > SortedList sortedItems = new SortedList<>(items); > sortedItems.setComparator(String::compareTo); > listView.setItems(sortedItems); > > items.add("2"); > listView.getSelectionModel().selectFirst(); > items.addAll("1", "3"); > > System.out.println(listView.getSelectionModel().getSelectedItem()); > System.out.println(listView.getSelectionModel().getSelectedItems()); > > This yields the following console output on JDK 8u66: > > 2 > [1] > > The "selected item" and "selected items" are out of sync. Interestingly if > you attach a ListChangeListener to the selected items list, it only fires > once (when selectFirst is called). > > Is this a bug? > > Cheers, > Rob > From robert.fisher.ext at zeiss.com Fri Oct 30 13:38:57 2015 From: robert.fisher.ext at zeiss.com (Fisher, Robert) Date: Fri, 30 Oct 2015 13:38:57 +0000 Subject: Bug when combining ListView and SortedList? In-Reply-To: References: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> Message-ID: <025E25CA98F8AE46BE306AB33F6A38D501276A01@ADEFUE01SMS003.cznet.zeiss.org> Done. From: Scott Palmer [mailto:swpalmer at gmail.com] Sent: Freitag, 30. Oktober 2015 14:38 To: Fisher, Robert Cc: openjfx-dev at openjdk.java.net Subject: Re: Bug when combining ListView and SortedList? That looks like a bug to me. Please report it. On Fri, Oct 30, 2015 at 7:07 AM, Fisher, Robert > wrote: Hi, I am wondering if this behaviour of ListView's MultipleSelectionModel is correct: ListView listView = new ListView<>(); ObservableList items = FXCollections.observableArrayList(); SortedList sortedItems = new SortedList<>(items); sortedItems.setComparator(String::compareTo); listView.setItems(sortedItems); items.add("2"); listView.getSelectionModel().selectFirst(); items.addAll("1", "3"); System.out.println(listView.getSelectionModel().getSelectedItem()); System.out.println(listView.getSelectionModel().getSelectedItems()); This yields the following console output on JDK 8u66: 2 [1] The "selected item" and "selected items" are out of sync. Interestingly if you attach a ListChangeListener to the selected items list, it only fires once (when selectFirst is called). Is this a bug? Cheers, Rob From bibanescu at montran.com Fri Oct 30 14:03:15 2015 From: bibanescu at montran.com (Bogdan Ibanescu) Date: Fri, 30 Oct 2015 16:03:15 +0200 (EET) Subject: Windows Hi-DPI In-Reply-To: References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> <56332DE3.1060008@gmail.com> Message-ID: <770240276.2932334.1446213795552.JavaMail.zimbra@montran.com> Having 200 cores won't help you with anything unless you explicitly customize your code to make use of them. ----- Original Message ----- From: "Felix Bembrick" To: "Chris Nahr" Cc: openjfx-dev at openjdk.java.net Sent: Friday, October 30, 2015 11:55:19 AM Subject: Re: Windows Hi-DPI The NVIDIA Control Panel allowed me to disable SLI completely and I even rebooted. I also upgraded to Java 8u72. Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a chain. All other 3D apps, games etc. perform blindingly fast as I would expect. So, if it's not an SLI or driver problem, what is going on here (or not going on)? Felix > On 30 Oct 2015, at 19:47, Felix Bembrick wrote: > > That's curious. SLI is designed specifically with gamers in mind! > > I'll investigating running without SLI and report back. > > Felix > >> On 30 Oct 2015, at 19:44, Chris Nahr wrote: >> >> If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? >> >> --Chris >> >>> On 2015-10-30 09:19, Felix Bembrick wrote: >>> I am using Java 8u66 and performance is really poor. >>> >>> I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. >>> >>> It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? >>> >>> It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. >>> >>> All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. >>> >>> Any ideas? >>> >>> Felix >>> >>>> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >>>> >>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >>>> >>>> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >>>> >>>> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >>>> >>>> Cheers, Chris >>>> >>>> >>>>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>>>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>>>> >>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>>> >>>>> Thanks, >>>>> >>>>> Fix >>>> -- Best Regards, -- Bogdan Marius Ibanescu -- Montran Corporation - Branch of Cluj-Napoca From vadim.pakhnushev at oracle.com Fri Oct 30 14:32:35 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 30 Oct 2015 17:32:35 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <56337F83.5080006@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From alexander.kouznetsov at oracle.com Fri Oct 30 15:46:31 2015 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Fri, 30 Oct 2015 08:46:31 -0700 Subject: Fx questions In-Reply-To: <563344A7.4090609@jugs.org> References: <563326D1.3000309@jugs.org> <563344A7.4090609@jugs.org> Message-ID: <563390D7.4010402@oracle.com> Hi Michael, Could you please file a bug on this? Best regards, Alexander Kouznetsov (408) 276-0387 On 30 ??? 2015 3:21, Dr. Michael Paus wrote: > This is good to know but I just gave it a try on my MacBookPro Retina > and it failed. > > I opened the youtube start page and there was an add at the top > (from Porsche :-)) which indeed played a video. Cool! > > But when I then clicked on the link to close the add java crashed > completely. > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x000000014946489e, pid=4440, tid=87311 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_72-b05) (build > 1.8.0_72-ea-b05) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b05 mixed mode > bsd-amd64 compressed oops) > # Problematic frame: > # C [libjfxmedia_avf.dylib+0x789e] > _ZN18AVFKernelComponent18ProcessBufferListsERjRK15AudioBufferListRS1_j+0x22 > # > > Obviously I'm having sticky fingers or so because I always catch all > bugs which are lurking arround. > Frustrating. > > > > Am 30.10.15 um 10:37 schrieb John Maton: >> JDK 8u72 (1.8.0_72-ea) makes a big difference here. >> Using 8u66 I was not able to see any HTML5 videos on youtube, they >> all reverted to Flash. >> 8u72 makes it all work, last time I checked I was unable to find a >> video on youtube which did not work. >> You can download 8u72 at https://jdk8.java.net/download.html >> Best regards, >> John Maton >> >> On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus > > wrote: >> >> Am 29.10.15 um 22:58 schrieb Brian Harris: >> >> - when embedding html5 pages into fx apps, should we expect >> it to >> render/behave similar to popular browsers like chrome? I'm >> wondering if we >> can expect this to just work or if things may be a bit wonky. >> >> In theory it is just Webkit and as such it should behave like any >> popular browser >> and in many cases it does. However, I have stumbled over several >> pages where >> this is not the case and sometimes it even depends on the system >> you are >> running your application on. It may work on Windows but fail on a >> Mac Retina. >> >> Your best bet is to just give it a try with the pages that are >> important for you >> and see how it behaves. >> >> Here are a few pages where I have problems with. >> >> https://www.google.com/maps - (enters "Lite-Mode" because of >> unsupported features.) >> >> https://www.youtube.com - (I am not able to watch any video there. >> Same on vimeo.) >> >> https://www.windyty.com - (No wind trails on MacBook Pro Retina.) >> >> (Tested with JDK 8u66-b17) >> >> > From mp at jugs.org Fri Oct 30 16:37:37 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 30 Oct 2015 17:37:37 +0100 Subject: Fx questions In-Reply-To: <563390D7.4010402@oracle.com> References: <563326D1.3000309@jugs.org> <563344A7.4090609@jugs.org> <563390D7.4010402@oracle.com> Message-ID: <56339CD1.6010401@jugs.org> I have done so. (Review ID: 9068159) - JVM crashes when selecting video on youtube in WebView Am 30.10.15 um 16:46 schrieb Alexander Kouznetsov: > Hi Michael, > > Could you please file a bug on this? > > Best regards, > Alexander Kouznetsov > (408) 276-0387 > > On 30 ??? 2015 3:21, Dr. Michael Paus wrote: >> This is good to know but I just gave it a try on my MacBookPro Retina >> and it failed. >> >> I opened the youtube start page and there was an add at the top >> (from Porsche :-)) which indeed played a video. Cool! >> >> But when I then clicked on the link to close the add java crashed >> completely. >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x000000014946489e, pid=4440, tid=87311 >> # >> # JRE version: Java(TM) SE Runtime Environment (8.0_72-b05) (build >> 1.8.0_72-ea-b05) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b05 mixed mode >> bsd-amd64 compressed oops) >> # Problematic frame: >> # C [libjfxmedia_avf.dylib+0x789e] >> _ZN18AVFKernelComponent18ProcessBufferListsERjRK15AudioBufferListRS1_j+0x22 >> # >> >> Obviously I'm having sticky fingers or so because I always catch all >> bugs which are lurking arround. >> Frustrating. >> >> >> >> Am 30.10.15 um 10:37 schrieb John Maton: >>> JDK 8u72 (1.8.0_72-ea) makes a big difference here. >>> Using 8u66 I was not able to see any HTML5 videos on youtube, they >>> all reverted to Flash. >>> 8u72 makes it all work, last time I checked I was unable to find a >>> video on youtube which did not work. >>> You can download 8u72 at https://jdk8.java.net/download.html >>> Best regards, >>> John Maton >>> >>> On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus >> > wrote: >>> >>> Am 29.10.15 um 22:58 schrieb Brian Harris: >>> >>> - when embedding html5 pages into fx apps, should we expect >>> it to >>> render/behave similar to popular browsers like chrome? I'm >>> wondering if we >>> can expect this to just work or if things may be a bit wonky. >>> >>> In theory it is just Webkit and as such it should behave like any >>> popular browser >>> and in many cases it does. However, I have stumbled over several >>> pages where >>> this is not the case and sometimes it even depends on the system >>> you are >>> running your application on. It may work on Windows but fail on a >>> Mac Retina. >>> >>> Your best bet is to just give it a try with the pages that are >>> important for you >>> and see how it behaves. >>> >>> Here are a few pages where I have problems with. >>> >>> https://www.google.com/maps - (enters "Lite-Mode" because of >>> unsupported features.) >>> >>> https://www.youtube.com - (I am not able to watch any video there. >>> Same on vimeo.) >>> >>> https://www.windyty.com - (No wind trails on MacBook Pro Retina.) >>> >>> (Tested with JDK 8u66-b17) >>> >>> >> > From felix.bembrick at gmail.com Fri Oct 30 16:37:35 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 31 Oct 2015 03:37:35 +1100 Subject: Windows Hi-DPI In-Reply-To: <770240276.2932334.1446213795552.JavaMail.zimbra@montran.com> References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> <56332DE3.1060008@gmail.com> <770240276.2932334.1446213795552.JavaMail.zimbra@montran.com> Message-ID: Yes, but unless you are saying that having more cores, more VRAM, faster VRAM and a much faster clock speed are actually going to slow down the performance of JavaFX then I don't know what point you are trying to make. > On 31 Oct 2015, at 01:03, Bogdan Ibanescu wrote: > > Having 200 cores won't help you with anything unless you explicitly customize your code to make use of them. > > ----- Original Message ----- > From: "Felix Bembrick" > To: "Chris Nahr" > Cc: openjfx-dev at openjdk.java.net > Sent: Friday, October 30, 2015 11:55:19 AM > Subject: Re: Windows Hi-DPI > > The NVIDIA Control Panel allowed me to disable SLI completely and I even rebooted. I also upgraded to Java 8u72. > > Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a chain. > > All other 3D apps, games etc. perform blindingly fast as I would expect. > > So, if it's not an SLI or driver problem, what is going on here (or not going on)? > > Felix > >> On 30 Oct 2015, at 19:47, Felix Bembrick wrote: >> >> That's curious. SLI is designed specifically with gamers in mind! >> >> I'll investigating running without SLI and report back. >> >> Felix >> >>> On 30 Oct 2015, at 19:44, Chris Nahr wrote: >>> >>> If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? >>> >>> --Chris >>> >>>> On 2015-10-30 09:19, Felix Bembrick wrote: >>>> I am using Java 8u66 and performance is really poor. >>>> >>>> I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. >>>> >>>> It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? >>>> >>>> It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. >>>> >>>> All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. >>>> >>>> Any ideas? >>>> >>>> Felix >>>> >>>>> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >>>>> >>>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >>>>> >>>>> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >>>>> >>>>> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >>>>> >>>>> Cheers, Chris >>>>> >>>>> >>>>>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>>>>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>>>>> >>>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fix >>>>> > > -- > Best Regards, > -- Bogdan Marius Ibanescu > -- Montran Corporation - Branch of Cluj-Napoca > From bibanescu at montran.com Fri Oct 30 16:56:43 2015 From: bibanescu at montran.com (Bogdan Ibanescu) Date: Fri, 30 Oct 2015 18:56:43 +0200 (EET) Subject: Windows Hi-DPI In-Reply-To: References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> <56332DE3.1060008@gmail.com> <770240276.2932334.1446213795552.JavaMail.zimbra@montran.com> Message-ID: <1060821211.2949365.1446224203755.JavaMail.zimbra@montran.com> The point I'm trying to make is that if you're running a single threaded application, it'll use 1 core. What you need to understand is that javafx does not magically figure out how organize rendering procedures across the systems' resources. The reason for which whatever you're trying to test seems to be about as fast on your computer as it is on your wife's' is because it's most likely not multi-threaded, or plainly badly implemented. Cross-fire and SLI and all that other crap is useless if you're only using 1% of your resources. All windows does when you select the GPU is the driver end-point. Activating it makes it run slightly faster because of the differences in hardware... but the lack of performance is the poor code in your software. ----- Original Message ----- From: "Felix Bembrick" To: "Bogdan Ibanescu" Cc: "Chris Nahr" , openjfx-dev at openjdk.java.net Sent: Friday, October 30, 2015 5:37:35 PM Subject: Re: Windows Hi-DPI Yes, but unless you are saying that having more cores, more VRAM, faster VRAM and a much faster clock speed are actually going to slow down the performance of JavaFX then I don't know what point you are trying to make. > On 31 Oct 2015, at 01:03, Bogdan Ibanescu wrote: > > Having 200 cores won't help you with anything unless you explicitly customize your code to make use of them. > > ----- Original Message ----- > From: "Felix Bembrick" > To: "Chris Nahr" > Cc: openjfx-dev at openjdk.java.net > Sent: Friday, October 30, 2015 11:55:19 AM > Subject: Re: Windows Hi-DPI > > The NVIDIA Control Panel allowed me to disable SLI completely and I even rebooted. I also upgraded to Java 8u72. > > Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a chain. > > All other 3D apps, games etc. perform blindingly fast as I would expect. > > So, if it's not an SLI or driver problem, what is going on here (or not going on)? > > Felix > >> On 30 Oct 2015, at 19:47, Felix Bembrick wrote: >> >> That's curious. SLI is designed specifically with gamers in mind! >> >> I'll investigating running without SLI and report back. >> >> Felix >> >>> On 30 Oct 2015, at 19:44, Chris Nahr wrote: >>> >>> If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? >>> >>> --Chris >>> >>>> On 2015-10-30 09:19, Felix Bembrick wrote: >>>> I am using Java 8u66 and performance is really poor. >>>> >>>> I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. >>>> >>>> It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? >>>> >>>> It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. >>>> >>>> All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. >>>> >>>> Any ideas? >>>> >>>> Felix >>>> >>>>> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >>>>> >>>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >>>>> >>>>> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >>>>> >>>>> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >>>>> >>>>> Cheers, Chris >>>>> >>>>> >>>>>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>>>>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>>>>> >>>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fix >>>>> > > -- > Best Regards, > -- Bogdan Marius Ibanescu > -- Montran Corporation - Branch of Cluj-Napoca > -- Best Regards, -- Bogdan Marius Ibanescu -- Montran Corporation - Branch of Cluj-Napoca From mp at jugs.org Fri Oct 30 17:32:41 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 30 Oct 2015 18:32:41 +0100 Subject: Windows Hi-DPI In-Reply-To: <1060821211.2949365.1446224203755.JavaMail.zimbra@montran.com> References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> <56332DE3.1060008@gmail.com> <770240276.2932334.1446213795552.JavaMail.zimbra@montran.com> <1060821211.2949365.1446224203755.JavaMail.zimbra@montran.com> Message-ID: <5633A9B9.5040408@jugs.org> I'd really like to know how you would add the remaining 99% of resources to the system once your scene graph is set up and you have started an animation which then turns out to be running slowly. JavaFX just uses 1 rendering thread and there is nothing you can do about that. Even with 99 additional cores you could do nothing to make that faster unless you would be using the new Marlin rasterizer. Even then only JavaFX itself could make use of that because it does not have any public API that you could mess with. Am 30.10.15 um 17:56 schrieb Bogdan Ibanescu: > The point I'm trying to make is that if you're running a single threaded application, it'll use 1 core. > > What you need to understand is that javafx does not magically figure out how organize rendering procedures across the systems' resources. > > The reason for which whatever you're trying to test seems to be about as fast on your computer as it is on your wife's' is because it's most likely not multi-threaded, or plainly badly implemented. > Cross-fire and SLI and all that other crap is useless if you're only using 1% of your resources. All windows does when you select the GPU is the driver end-point. Activating it makes it run slightly faster because of the differences in hardware... but the lack of performance is the poor code in your software. > > ----- Original Message ----- > From: "Felix Bembrick" > To: "Bogdan Ibanescu" > Cc: "Chris Nahr" , openjfx-dev at openjdk.java.net > Sent: Friday, October 30, 2015 5:37:35 PM > Subject: Re: Windows Hi-DPI > > Yes, but unless you are saying that having more cores, more VRAM, faster VRAM and a much faster clock speed are actually going to slow down the performance of JavaFX then I don't know what point you are trying to make. > >> On 31 Oct 2015, at 01:03, Bogdan Ibanescu wrote: >> >> Having 200 cores won't help you with anything unless you explicitly customize your code to make use of them. >> >> ----- Original Message ----- >> From: "Felix Bembrick" >> To: "Chris Nahr" >> Cc: openjfx-dev at openjdk.java.net >> Sent: Friday, October 30, 2015 11:55:19 AM >> Subject: Re: Windows Hi-DPI >> >> The NVIDIA Control Panel allowed me to disable SLI completely and I even rebooted. I also upgraded to Java 8u72. >> >> Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a chain. >> >> All other 3D apps, games etc. perform blindingly fast as I would expect. >> >> So, if it's not an SLI or driver problem, what is going on here (or not going on)? >> >> Felix >> >>> On 30 Oct 2015, at 19:47, Felix Bembrick wrote: >>> >>> That's curious. SLI is designed specifically with gamers in mind! >>> >>> I'll investigating running without SLI and report back. >>> >>> Felix >>> >>>> On 30 Oct 2015, at 19:44, Chris Nahr wrote: >>>> >>>> If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? >>>> >>>> --Chris >>>> >>>>> On 2015-10-30 09:19, Felix Bembrick wrote: >>>>> I am using Java 8u66 and performance is really poor. >>>>> >>>>> I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. >>>>> >>>>> It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? >>>>> >>>>> It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. >>>>> >>>>> All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. >>>>> >>>>> Any ideas? >>>>> >>>>> Felix >>>>> >>>>>> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >>>>>> >>>>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >>>>>> >>>>>> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >>>>>> >>>>>> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >>>>>> >>>>>> Cheers, Chris >>>>>> >>>>>> >>>>>>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>>>>>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>>>>>> >>>>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Fix >> -- >> Best Regards, >> -- Bogdan Marius Ibanescu >> -- Montran Corporation - Branch of Cluj-Napoca >> From james.graham at oracle.com Fri Oct 30 19:49:57 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 30 Oct 2015 12:49:57 -0700 Subject: Windows Hi-DPI In-Reply-To: <94CE475E-320E-4B81-82F7-5BDBFEEA3386@gmail.com> References: <94CE475E-320E-4B81-82F7-5BDBFEEA3386@gmail.com> Message-ID: <5633C9E5.8060503@oracle.com> It should be supported. Which version of Windows were you using before? We've supported HiDPI on Windows since JDK8u60 on all supported versions of Windows... ...jim On 10/27/15 11:24 PM, Felix Bembrick wrote: > I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. > > Is this because Hi-DPI is not yet supported in JavaFX on Windows? > > Thanks, > > Fix > From felix.bembrick at gmail.com Fri Oct 30 19:59:34 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 31 Oct 2015 06:59:34 +1100 Subject: Windows Hi-DPI In-Reply-To: <5633C9E5.8060503@oracle.com> References: <94CE475E-320E-4B81-82F7-5BDBFEEA3386@gmail.com> <5633C9E5.8060503@oracle.com> Message-ID: <02A84A2E-AF14-4037-9B71-783DEEE86FF0@gmail.com> Hi Jim, I had Windows 10 on my previous machine and my wife's low-end PC is also running Win10 and the same version of Java. But I have what is supposed to be the fastest graphics card of all (GeForce GTX Titan X) and she has a very basic card. The only real difference is that she has a 22" monitor with a resolution of 1920 X 1024 (?) and I have 2 4K monitors. Hi-DPI is supported in the sense that everything renders at the correct size etc (unlike Swing) but it performs so slowly that there must be something fundamentally wrong, especially since JavaFX seems to be the only technology that's affected. > On 31 Oct 2015, at 06:49, Jim Graham wrote: > > It should be supported. Which version of Windows were you using before? We've supported HiDPI on Windows since JDK8u60 on all supported versions of Windows... > > ...jim > >> On 10/27/15 11:24 PM, Felix Bembrick wrote: >> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >> >> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >> >> Thanks, >> >> Fix >> From james.graham at oracle.com Fri Oct 30 20:07:42 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 30 Oct 2015 13:07:42 -0700 Subject: Windows Hi-DPI In-Reply-To: <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> Message-ID: <5633CE0E.9020601@oracle.com> I doubt it would be simply a "number of pixels" issue. I don't have a 4K monitor, but I've run it on some HiDPI monitors that keep up just fine with much more modest hardware. There are a couple of possible things that may get in the way: - Our max texture size is 4096x4096 which should be large enough for a 4K monitor backbuffer, but perhaps something in your application requires a texture to be allocated larger than the monitor size. Try setting -Dprism.maxTextureSize=8192 and see if that helps at all. - Driver issues. Perhaps we are failing to enable hardware acceleration on your system. Try running with "-Dprism.verbose=true" and see what it says about the pipeline being used and the driver/hardware details it prints out. - Other driver issues. We may be doing something unique that triggers problems under Windows 10 that we don't see under earlier versions of Windows and earlier drivers. As someone said, some drivers cause the GPU to constantly fault and reboot under Windows 10 (the machine doesn't reboot, the GPU just restarts and continues). Notably everyone who is using a brand new SurfaceBook with the nVidia GPU reports that the GPU is constantly freezing and restarting, especially when running the new browser. If it does that to us once per frame then we are going to spend all of our time recreating our world... ...jim On 10/30/15 1:19 AM, Felix Bembrick wrote: > I am using Java 8u66 and performance is really poor. > > I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. > > It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? > > It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. > > All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. > > Any ideas? > > Felix > >> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >> >> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >> >> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >> >> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >> >> Cheers, Chris >> >> >>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>> >>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>> >>> Thanks, >>> >>> Fix >> From james.graham at oracle.com Fri Oct 30 20:21:29 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 30 Oct 2015 13:21:29 -0700 Subject: Windows Hi-DPI In-Reply-To: <02A84A2E-AF14-4037-9B71-783DEEE86FF0@gmail.com> References: <94CE475E-320E-4B81-82F7-5BDBFEEA3386@gmail.com> <5633C9E5.8060503@oracle.com> <02A84A2E-AF14-4037-9B71-783DEEE86FF0@gmail.com> Message-ID: <5633D149.2040809@oracle.com> Other things to try: -Dprism.verbose=true (output should show the following options are working) -Dglass.win.uiScale=1.0 (disables HiDPI) -Dprism.order=sw (disables HW acceleration) -Dprism.maxTextureSize=8192 (mentioned before - increases max texture dims) -Dprism.maxvram=2G (increases maximum texture pool to 2GB) -Dprism.targetvram=2G (combined with maxvram, increases initial pool to 2GB) ...jim On 10/30/15 12:59 PM, Felix Bembrick wrote: > Hi Jim, > > I had Windows 10 on my previous machine and my wife's low-end PC is also running Win10 and the same version of Java. > > But I have what is supposed to be the fastest graphics card of all (GeForce GTX Titan X) and she has a very basic card. > > The only real difference is that she has a 22" monitor with a resolution of 1920 X 1024 (?) and I have 2 4K monitors. > > Hi-DPI is supported in the sense that everything renders at the correct size etc (unlike Swing) but it performs so slowly that there must be something fundamentally wrong, especially since JavaFX seems to be the only technology that's affected. > >> On 31 Oct 2015, at 06:49, Jim Graham wrote: >> >> It should be supported. Which version of Windows were you using before? We've supported HiDPI on Windows since JDK8u60 on all supported versions of Windows... >> >> ...jim >> >>> On 10/27/15 11:24 PM, Felix Bembrick wrote: >>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>> >>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>> >>> Thanks, >>> >>> Fix >>> From alexander.kouznetsov at oracle.com Fri Oct 30 22:57:27 2015 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Fri, 30 Oct 2015 15:57:27 -0700 Subject: Windows Hi-DPI In-Reply-To: References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> <56332DE3.1060008@gmail.com> Message-ID: <5633F5D7.3020109@oracle.com> Have you tried running it with -Dprism.verbose=true flag? It should provide some debug output. Best regards, Alexander Kouznetsov (408) 276-0387 On 30 ??? 2015 3:55, Felix Bembrick wrote: > The NVIDIA Control Panel allowed me to disable SLI completely and I even rebooted. I also upgraded to Java 8u72. > > Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a chain. > > All other 3D apps, games etc. perform blindingly fast as I would expect. > > So, if it's not an SLI or driver problem, what is going on here (or not going on)? > > Felix > >> On 30 Oct 2015, at 19:47, Felix Bembrick wrote: >> >> That's curious. SLI is designed specifically with gamers in mind! >> >> I'll investigating running without SLI and report back. >> >> Felix >> >>> On 30 Oct 2015, at 19:44, Chris Nahr wrote: >>> >>> If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? >>> >>> --Chris >>> >>>> On 2015-10-30 09:19, Felix Bembrick wrote: >>>> I am using Java 8u66 and performance is really poor. >>>> >>>> I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. >>>> >>>> It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? >>>> >>>> It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. >>>> >>>> All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. >>>> >>>> Any ideas? >>>> >>>> Felix >>>> >>>>> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >>>>> >>>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >>>>> >>>>> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >>>>> >>>>> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >>>>> >>>>> Cheers, Chris >>>>> >>>>> >>>>>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>>>>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>>>>> >>>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fix From felix.bembrick at gmail.com Fri Oct 30 23:05:17 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 31 Oct 2015 10:05:17 +1100 Subject: Windows Hi-DPI In-Reply-To: <1060821211.2949365.1446224203755.JavaMail.zimbra@montran.com> References: <56330F55.4050407@gmail.com> <22F894CE-E095-4A41-A71C-326FA9EEC4C5@gmail.com> <56332DE3.1060008@gmail.com> <770240276.2932334.1446213795552.JavaMail.zimbra@montran.com> <1060821211.2949365.1446224203755.JavaMail.zimbra@montran.com> Message-ID: Thanks Bogdan, but that "poor code" works extremely well everywhere else. > On 31 Oct 2015, at 03:56, Bogdan Ibanescu wrote: > > The point I'm trying to make is that if you're running a single threaded application, it'll use 1 core. > > What you need to understand is that javafx does not magically figure out how organize rendering procedures across the systems' resources. > > The reason for which whatever you're trying to test seems to be about as fast on your computer as it is on your wife's' is because it's most likely not multi-threaded, or plainly badly implemented. > Cross-fire and SLI and all that other crap is useless if you're only using 1% of your resources. All windows does when you select the GPU is the driver end-point. Activating it makes it run slightly faster because of the differences in hardware... but the lack of performance is the poor code in your software. > > ----- Original Message ----- > From: "Felix Bembrick" > To: "Bogdan Ibanescu" > Cc: "Chris Nahr" , openjfx-dev at openjdk.java.net > Sent: Friday, October 30, 2015 5:37:35 PM > Subject: Re: Windows Hi-DPI > > Yes, but unless you are saying that having more cores, more VRAM, faster VRAM and a much faster clock speed are actually going to slow down the performance of JavaFX then I don't know what point you are trying to make. > >> On 31 Oct 2015, at 01:03, Bogdan Ibanescu wrote: >> >> Having 200 cores won't help you with anything unless you explicitly customize your code to make use of them. >> >> ----- Original Message ----- >> From: "Felix Bembrick" >> To: "Chris Nahr" >> Cc: openjfx-dev at openjdk.java.net >> Sent: Friday, October 30, 2015 11:55:19 AM >> Subject: Re: Windows Hi-DPI >> >> The NVIDIA Control Panel allowed me to disable SLI completely and I even rebooted. I also upgraded to Java 8u72. >> >> Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a chain. >> >> All other 3D apps, games etc. perform blindingly fast as I would expect. >> >> So, if it's not an SLI or driver problem, what is going on here (or not going on)? >> >> Felix >> >>> On 30 Oct 2015, at 19:47, Felix Bembrick wrote: >>> >>> That's curious. SLI is designed specifically with gamers in mind! >>> >>> I'll investigating running without SLI and report back. >>> >>> Felix >>> >>>> On 30 Oct 2015, at 19:44, Chris Nahr wrote: >>>> >>>> If it's slower on an SLI machine than on an ordinary one then yes, I suspect JavaFX just can't handle SLI properly. Among gamers I've often heard that it's a notoriously problematic configuration. Can you switch your card to non-SLI mode and retest performance? >>>> >>>> --Chris >>>> >>>>> On 2015-10-30 09:19, Felix Bembrick wrote: >>>>> I am using Java 8u66 and performance is really poor. >>>>> >>>>> I suspected a driver issue but I have the latest driver for my Titan X card (4 in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in the top 1% fastest computers ever to run the tests. >>>>> >>>>> It looks to me that JavaFX just can't deliver acceptable performance on 4K monitors, even with the most powerful graphics cards on the planet. Or maybe it doesn't support SLI? >>>>> >>>>> It could be Windows 10 related but I don't think so. And I am definitely getting hardware acceleration according to the output so I suspect JavaFX has trouble moving so many pixels around on these hi-res monitors. >>>>> >>>>> All other 3D apps and games run blindingly fast but JavaFX actually runs slower on this beast than on my wife's little i5 powered Dell machine with a low range graphics card, also running Windows 10. >>>>> >>>>> Any ideas? >>>>> >>>>> Felix >>>>> >>>>>> On 30 Oct 2015, at 17:33, Chris Nahr wrote: >>>>>> >>>>>> Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case with the Intel 4600 integrated GPU. >>>>>> >>>>>> However, this causes frequent Intel display driver crashes and restarts because the Windows 10 drivers are still so immature. Same happens in WPF applications, so it's not specific to JavaFX. I've grabbed my driver directly from the Intel website. Possibly your system runs an older driver that causes JavaFX not to use HA. >>>>>> >>>>>> Given how unstable it currently is on Windows 10, that might not be a bad idea. But of course you could try manually updating and see what happens to JavaFX performance. >>>>>> >>>>>> Cheers, Chris >>>>>> >>>>>> >>>>>>> On 2015-10-28 17:24:38, Felix Bembrick wrote: >>>>>>> I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has two 4K monitors and while everything looks great and the right "size", the performance is very sluggish to say the least. >>>>>>> >>>>>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Fix >> >> -- >> Best Regards, >> -- Bogdan Marius Ibanescu >> -- Montran Corporation - Branch of Cluj-Napoca > > -- > Best Regards, > -- Bogdan Marius Ibanescu > -- Montran Corporation - Branch of Cluj-Napoca > From felix.bembrick at gmail.com Sat Oct 31 00:40:05 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 31 Oct 2015 11:40:05 +1100 Subject: Windows Hi-DPI In-Reply-To: <5633D149.2040809@oracle.com> References: <94CE475E-320E-4B81-82F7-5BDBFEEA3386@gmail.com> <5633C9E5.8060503@oracle.com> <02A84A2E-AF14-4037-9B71-783DEEE86FF0@gmail.com> <5633D149.2040809@oracle.com> Message-ID: Hi Jim, I have experimented with all those options with the following results: 1. Turning on verbose proves hardware acceleration is being used. 2. Increasing texture size and fiddling with the amount of VRAM has no effect on performance. 3. Turning off Hi DPI changes the appearance of the app (i.e. controls are too small etc.) but has no effect on performance. 4. Disabling hardware acceleration makes it another order of magnitude slower than before. So none of the options improved performance at all. All we know for sure is that it's using D3D and that it is running so much slower than I expected and so much so that it is unusable. Here's some of the initial output which hopefully shows something about the issue: *Prism pipeline init order: d3dUsing native-based Pisces rasterizerUsing dirty region optimizationsNot using texture mask for primitivesNot forcing power of 2 sizes for texturesUsing hardware CLAMP_TO_ZERO modeOpting in for HiDPI pixel scalingPrism pipeline name = com.sun.prism.d3d.D3DPipelineLoading D3D native library ... succeeded.D3DPipelineManager: Created D3D9Ex deviceDirect3D initialization succeeded(X) Got class = class com.sun.prism.d3d.D3DPipelineInitialized prism pipeline: com.sun.prism.d3d.D3DPipelineMaximum supported texture size: 16384Maximum texture size clamped to 8192OS Information: Windows version 10.0 build 10240D3D Driver Information: NVIDIA GeForce GTX TITAN X \\.\DISPLAY1 Driver nvd3dum.dll, version 10.18.13.5850 Pixel Shader version 3.0 Device : ven_10DE, dev_17C2, subsys_113210DE Max Multisamples supported: 4 vsync: true vpipe: trueLoading Prism common native library ...* * succeeded.PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_28PPSRenderer: scenario.effect - createShader: LinearConvolve_8PPSRenderer: scenario.effect - createShader: LinearConvolve_64PPSRenderer: scenario.effect - createShader: Blend_ADDPPSRenderer: scenario.effect - createShader: LinearConvolveShadow_16PPSRenderer: scenario.effect - createShader: LinearConvolve_12* - On 31 October 2015 at 07:21, Jim Graham wrote: > Other things to try: > > -Dprism.verbose=true (output should show the following options > are working) > > -Dglass.win.uiScale=1.0 (disables HiDPI) > -Dprism.order=sw (disables HW acceleration) > -Dprism.maxTextureSize=8192 (mentioned before - increases max texture > dims) > > -Dprism.maxvram=2G (increases maximum texture pool to 2GB) > -Dprism.targetvram=2G (combined with maxvram, increases initial > pool to 2GB) > > ...jim > > > On 10/30/15 12:59 PM, Felix Bembrick wrote: > >> Hi Jim, >> >> I had Windows 10 on my previous machine and my wife's low-end PC is also >> running Win10 and the same version of Java. >> >> But I have what is supposed to be the fastest graphics card of all >> (GeForce GTX Titan X) and she has a very basic card. >> >> The only real difference is that she has a 22" monitor with a resolution >> of 1920 X 1024 (?) and I have 2 4K monitors. >> >> Hi-DPI is supported in the sense that everything renders at the correct >> size etc (unlike Swing) but it performs so slowly that there must be >> something fundamentally wrong, especially since JavaFX seems to be the only >> technology that's affected. >> >> On 31 Oct 2015, at 06:49, Jim Graham wrote: >>> >>> It should be supported. Which version of Windows were you using >>> before? We've supported HiDPI on Windows since JDK8u60 on all supported >>> versions of Windows... >>> >>> ...jim >>> >>> On 10/27/15 11:24 PM, Felix Bembrick wrote: >>>> I just installed JavaFX on my new Windows 10 machine which is extremely >>>> powerful but has two 4K monitors and while everything looks great and the >>>> right "size", the performance is very sluggish to say the least. >>>> >>>> Is this because Hi-DPI is not yet supported in JavaFX on Windows? >>>> >>>> Thanks, >>>> >>>> Fix >>>> >>>> From felix.bembrick at gmail.com Sat Oct 31 08:23:45 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 31 Oct 2015 19:23:45 +1100 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> <5620261F.7060206@oracle.com> Message-ID: Hi Johan, Now that your workload has hopefully lessened a bit after J1, do you think you could find some time to address this question of mine from earlier? Thanks, Felix > On 18 Oct 2015, at 19:01, Felix Bembrick wrote: > > Hi Johan, > > If you have been getting acceptable but not stunning performance on Android and all this time hardware acceleration was not being utilised then it sounds like there is some serious room for some dramatic performance increases. > > Not being that familiar with the finer points of how JavaFX is implemented on Android, just how much work is involved in accessing that hardware acceleration? Any timeline? > > I expect that implementing this significant change could be a make-or-break factor in determining whether JavaFX is truly viable and successful on Android. > > Good luck Johan! > > Cheers, > > Felix > >> On 17 Oct 2015, at 19:49, Johan Vos wrote: >> >> As a follow-up on the second part: after about 2 years working on JavaFX on >> Android, I discovered we are not even using Hardware Acceleration. We >> create a SurfaceView and render on that, but it turns out SurfaceView is >> never Hardware Accelerated. The positive thing is that this means there is >> even more room for optimization :) >> >> - Johan >> >>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos wrote: >>> >>> Hi, >>> >>> Thanks for the suggestions. There are 2 different things: >>> >>> 1. It seems indeed there is not much being cached, so there are definitely >>> improvements possible. It also require e.g. VirtualFlow to use the >>> Node.setCache(true) in order to cache. The combination of this with the >>> prism.scrollcacheopt reduces the rendering calls. I think the only penalty >>> is memory, but so far, we didn't run into issues with too high GC activity. >>> >>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times >>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns). >>> I'll have to look into some EGL options. >>> >>> - Johan >>> >>> >>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham >>> wrote: >>> >>>> Chien pointed out a system property that is currently disabling the >>>> scrolling optimization. For its implementation look at CacheFilter.java, >>>> in particular the invalidateByTranslation() method and all that it kicks >>>> off. >>>> >>>> Another thing to look at is that we added alpha batching to the code >>>> which should be batching all of the output of the produceAlphas calls into >>>> a texture and then drawing all of the quads together - provided that they >>>> are all being filled with simple colors (they can have alpha, but they >>>> can't be gradients, etc.). This should be managed by the >>>> BaseContext.updateMaskTexture() method which controls the single batch >>>> texture. >>>> >>>> Again, are there similar number of invocations of the glDrawElements on >>>> the 2 platforms? >>>> >>>> ...jim >>>> >>>>> On 10/15/15 12:30 PM, Johan Vos wrote: >>>>> >>>>> Thanks Jim. >>>>> I tried with different optimization flags, but it doesn't make a big >>>>> difference. Tracing it down to system calls, somehow the gl >>>>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads >>>>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) >>>>> per invocation. The number of invocations is comparable between iOS and >>>>> Android. >>>>> >>>>> If you can give me a direction on where to search for the disabled >>>>> scrolling optimization, I'll try to re-enable that and see how it >>>>> improves performance. It might be a huge and quick win... >>>>> >>>>> Thanks again, >>>>> >>>>> - Johan >>>>> >>>>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham >>>> > wrote: >>>>> >>>>> Perhaps optimization flags with the native compiler? Also, was it >>>>> called a similar number of times on both? >>>>> >>>>> Ideally we'd just be using copyArea for the scrolling, but at one >>>>> point we disabled the scrolling optimizations on retina MBP because >>>>> they didn't work with a scale factor and I don't think we reenabled >>>>> them yet. That would kill scrolling performance on mobile as a >>>>> result of having to rerender the scene on each scroll regardless of >>>>> how long produceAlphas takes... >>>>> >>>>> ...jim >>>>> >>>>> >>>>> On 10/15/15 4:27 AM, Johan Vos wrote: >>>>> >>>>> After spending lots of time optimizing JavaFX on iOS, I am now >>>>> at the point >>>>> where scrolling is 10 times faster on iOS than on Android. >>>>> The scrolling in the iOS version of the Gluon JavaOne mobile >>>>> schedule >>>>> builder is pretty good imho. On Android, it is much slower. I >>>>> profiled and >>>>> compared both, and it turns out that on Android, we spend lots >>>>> of time in >>>>> the native implementation of >>>>> NativePiscesRasterizer.produceFillAlphas >>>>> (implemented in native-prism/NativePiscesRasterizer.c) >>>>> >>>>> On average, calling this native function on an iPhone 6 takes >>>>> 40,000ns >>>>> whereas on a Nexus 6, this takes about 800,000ns. >>>>> >>>>> If anyone has a suggestion on how to improve or avoid this, I'm >>>>> all ears. >>>>> >>>>> Thanks, >>>>> >>>>> - Johan >>>