hg: openjfx/8/graphics/rt: RT-32032 Android: VM hangs when application finishes.
Changeset: 521cced8d920 Author:tb115823 tomas.branda...@oracle.com Date: 2013-08-06 08:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/521cced8d920 RT-32032 Android: VM hangs when application finishes. Detach correctly all threads. Send notification to FXActivity that VM has shutdown. ! modules/graphics/src/android/java/com/oracle/dalvik/FXActivity.java ! modules/graphics/src/android/java/com/oracle/dalvik/NativePipeReader.java ! modules/graphics/src/android/java/com/oracle/dalvik/VMLauncher.java ! modules/graphics/src/main/native-glass/lens/android/android.c ! modules/graphics/src/main/native-glass/lens/android/android.h ! modules/graphics/src/main/native-glass/lens/input/android/androidInput.c ! modules/graphics/src/main/native-glass/lens/input/android/androidInput.h ! modules/graphics/src/main/native-glass/lens/input/android/androidLens.c
Re: Build failures
On Thu, Aug 1, 2013 at 8:11 PM, Richard Bair richard.b...@oracle.comwrote: By the way, can I suggest moving away from the forest hg extension - it's no longer supported can't be made to work reliably on Mac. Which page did you see this one? I see this on the Building OpenJFX wiki page: (Note: Historically you also had to clone the jfx repository in the forest that you cared about. However we have modified our approach, such that we no longer promote the use of a forest, and instead are putting all of our sources in a single repository, presently named rt). We actually don't use the forest extension on OpenJFX at all anymore, if we're still referring to it on a page I'll fix it. It's in the README. Also, are you using the OpenJFX master, or OpenJFX Controls or OpenJFX graphics repo? Graphics / Controls are the daily team repos, master being only sync'd up weekly. I'm using master - I couldn't see any other way to get bootstrapped. Is there some other process I should be following for a first build? I'm attempting to get OpenJFX built running against the tip of Nashorn. OK the first question I have is to make sure I understand correctly. Do you mean that you're trying to build the latest OpenJFX + the latest Nashorn, combine them into a single JDK build, and then write an app that uses both? Is Nashorn developed in a different repo, like OpenJFX is, or is it now built as part of the normal JDK 8? Nashorn is folded into JDK 8 regiular, but the head of development is ahead of OpenJDK mainline. Assuming it is, it still isn't working. After a certain amount of yak-shaving (Gradle being useless, and having to hack around the forest extension gunk) the build is failing (details below). Why did you need forest? Maybe if we start here with where the yak shaving exercise started then maybe I can see where you may have left the beaten path. The README told me I needed it - I worked out the equivalent hg commands (the ones given in the README as an alternative to forest are slightly wrong). /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/ext/jfxrt.jar Which build of Java 8 is this? This is with Oracle Java 8 EA latest beta. Using an OpenJDK build instead causes a different set of errors. :fxpackager:compileLauncher In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6, from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, from /Users/boxcat/projects/openjdk/master/rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:12:20: error: stdarg.h: No such file or directory I'm building with 10.8 rather than 10.7. Kevin do you know what the hudson machines are setup to build with? Hm. This machine is actually a 10.8 box. Looking at main.m line 26 we see this import: #import Cocoa/Cocoa.h It seems that something must be misconfigured on your system if importing Cocoa.h leads to a compile error. I'm not an expert on Mac native programming, maybe Felipe or David Dehaven can chime in? I suspect some XCode oddness here - let me investigate further. Thanks, Ben
hg: openjfx/8/graphics/rt: RT-32123: Clip properly synced after parent visibility change.
Changeset: bd6f656cd8a9 Author:Pavel Safrata pavel.safr...@oracle.com Date: 2013-08-06 10:43 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bd6f656cd8a9 RT-32123: Clip properly synced after parent visibility change. Contributed-by: Tom Schindl tom.schi...@bestsolution.at Added unit test. ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/stub/java/javafx/scene/NodeTest.java
Brick Breaker ball jitter
I seem to remember some time ago that work was done on reducing the jitter in the ball's motion in the Brick Breaker demo in Ensemble8. Did this ever make it into the main line? I ask because I have just installed JDK 8 b101 and the ball still shows very significant jitter in its motion on this Windows 7 x64 machine. Thanks, -jct
hg: openjfx/8/graphics/rt: RT-32039: Yandex Maps are broken after sync with WebKit trunk
Changeset: 91a8ecbea96e Author:Vasiliy Baranov vasiliy.bara...@oracle.com Date: 2013-08-06 15:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/91a8ecbea96e RT-32039: Yandex Maps are broken after sync with WebKit trunk ! modules/web/src/main/native/Source/WebCore/DerivedSourcesJava.pri ! modules/web/src/main/native/Source/WebCore/page/java/ChromeClientJava.cpp ! modules/web/src/main/native/Source/WebCore/page/java/ChromeClientJava.h ! modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.cpp ! modules/web/src/main/native/Source/WebCore/storage/java/StorageAreaJava.h
Re: A different way to handle pulse timing
On 8/5/2013 10:26 PM, Richard Bair wrote: In the past we have seen situations where there are so many tasks on the user event thread, that user response (even on desktop) was not acceptable. Some of these items are getting better as we improve design (ie less redundant layout operations causes by a single change/event). Right, but I don't see how that could still happen in this proposal? The problem before was the pulse events were handled outside of the event queue (as I recall) so that they got higher priority. We got rid of the higher priority and starvation ceased. This proposal would not reintroduce priorities, so I don't see how you could end up with input event starvation again? rendering is staged on the event queue (layout, adding the render job to the render thread). It has been this way for quite a while now. As far as I remember,( other than paths with live resize), we have never had a mechanism that provided for event priority (at least not on the Linux side where I tend to live). This is how I thought it used to be done: we had (still have) a separate glass thread which fires off once ever 16ms or so. We used to take this pulse and handle it at the next available opportunity, which was explicit prioritization. If the pulse handling took longer than 16ms, by the time the pulse ended we'd have another pulse ready to be handled and would starve the queue. Today, we get this event and add it to the event queue, so we are never starving the event queue. In this proposal, we also would be putting the next pulse on the end of the queue, so it is impossible to starve input events. Putting the next pulse on the end of the queue is surprisingly difficult task, at least on Windows. If we use standard APIs provided by the platform, PostMessage() and SendMessage(), events are always put to the head of the queue. If we use timer events, they are of the lowest priority, so we'll have paint starvation instead of input events starvation. Thanks, Artem Thanks Richard
Re: A different way to handle pulse timing
On 8/5/2013 9:09 PM, Richard Bair wrote: In the past we have seen situations where there are so many tasks on the user event thread, that user response (even on desktop) was not acceptable. Some of these items are getting better as we improve design (ie less redundant layout operations causes by a single change/event). Right, but I don't see how that could still happen in this proposal? The problem before was the pulse events were handled outside of the event queue (as I recall) so that they got higher priority. We got rid of the higher priority and starvation ceased. This proposal would not reintroduce priorities, so I don't see how you could end up with input event starvation again? Here is that bug: RT-20656: Pending requests from Application.invokeLater can cause input event starvation It is indeed fixed, but the fix was to make sure we always have a window to dispatch input events (sometimes, very small, but still). Higher priority for user/application runnables is still there. Thanks, Artem BTW - it is very easy to write a bad app which will demonstrate the problem. As a thought example - if on a button click, you calculate PI to the nth digit before updating your text field - and you do it in the event callback - you are stalling the user event thread. Add in enough computes and you get an very unresponsive app. Instead of computes, you can just call sleep to see the problem too :-) But this is the case today as well. Richard
Re: TD game (hijacking Re: Performant Controls (hijacking Re: Developing controls based on Canvas?))
I'm pretty burnt myself but it remains in the back of my mind and I will be devoting some effort to it. I think this is a good email to spark me to go and work on it. Before August is out will work on it. Thanks! jose From: Daniel Zwolenski zon...@gmail.com To: Richard Bair richard.b...@oracle.com Cc: openjfx-dev@openjdk.java.net List openjfx-dev@openjdk.java.net Sent: Tuesday, August 6, 2013 1:32 AM Subject: Re: TD game (hijacking Re: Performant Controls (hijacking Re: Developing controls based on Canvas?)) I'm out for that one for the foreseeable future. I've burnt up any and all free time on getting the desktop and iOS workflows working with Maven. I'm big time behind on client work. Tell you what though, if you can get someone at Oracle to take over the deployment tools and iOS stuff, I'd very happily switch over to building games and gliffy-like demo apps :) On Tue, Aug 6, 2013 at 3:02 PM, Richard Bair richard.b...@oracle.comwrote: It really wasn't ever supposed to be my TD game, I keep trying to get you (and others interested in the community) to develop it. I'm up to my eyeballs in work already, as I'm sure you can relate :-) Richard On Aug 5, 2013, at 9:24 PM, Daniel Zwolenski zon...@gmail.com wrote: You should be able to check out they work in your TD game and continue development on that then. On Tue, Aug 6, 2013 at 2:16 PM, Richard Bair richard.b...@oracle.comwrote: To add to the confusion, Canvas currently has some drastic z-order bugs, and some clipping issues, so using it combined with Nodes is currently a no-go. I believe those have all been fixed in the last couple of weeks. Richard
hg: openjfx/8/graphics/rt: Fix to RT-30270: FX 8 3D: dirtyopts doesn't work for 3D rendering
Changeset: 891fda941088 Author:Chien Yang chien.y...@orcale.com Date: 2013-08-06 07:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/891fda941088 Fix to RT-30270: FX 8 3D: dirtyopts doesn't work for 3D rendering Reviewed by Kevin + apps/toys/FX8-3DFeatures/src/fx83dfeatures/LightMotion.java ! modules/graphics/src/main/java/javafx/scene/LightBase.java
Re: A different way to handle pulse timing
On 8/6/2013 6:07 PM, Scott Palmer wrote: On 2013-08-06, at 9:10 AM, Artem Ananiev artem.anan...@oracle.com wrote: On 8/5/2013 10:26 PM, Richard Bair wrote: In this proposal, we also would be putting the next pulse on the end of the queue, so it is impossible to starve input events. Putting the next pulse on the end of the queue is surprisingly difficult task, at least on Windows. If we use standard APIs provided by the platform, PostMessage() and SendMessage(), events are always put to the head of the queue. If we use timer events, they are of the lowest priority, so we'll have paint starvation instead of input events starvation. If the OS message queue is fundamentally broken (i.e. it does not behave like a queue), can all this be done on a proper queue that you have control over? I wouldn't say it's broken :) It's implemented this way by design. BTW, as far as I know, Mac OS X is similar to Windows wrt event handling: all the selectors (correspond to PostMessage() and SendMessage()) are processed before input events. I.e. in the OS-specific message loop, just move the messages to a more reasonably behaved queue. Posting a request to process a pulse would simply queue the operation on the well behaved queue and not use the OS PostMessage or SendMessage mechanism at all. I admit to not knowing enough about Windows message processing to know if that even makes sense. What you describe is close to how JavaFX is implemented on embedded platforms. See Lens code in Glass for details. We do this, because on that platforms there is virtually no native event queue, so we have our own. However, on platforms like Windows or Mac OS X, we have to use native event queues, otherwise JavaFX apps won't be good citizens there. This is what we have in AWT/Swing, where a native event queue is separate from Java event queue. I can't say the exact number of minor (e.g. sluggish window resizing), major (dragndrop not working), and even fatal (JVM crashes) issues we fixed in AWT, that were caused by this architecture with 2 queues, but believe me this number is huge. (Windows seriously doesn't have a mechanism to put something on the tail end of the message queue? Wow, don't they understand how a queue is supposed to work?) Why do you think it must be a queue? :) It can be a queue, but it can be something more complex as well. And yes, there is no easy way to put an event to the tail of the queue on Windows. What we can do is to put events to the queue with PostMessage/SendMessage, but dequeue them in different order. We prototyped that in the past, but didn't find it acceptable. Thanks, Artem Scott
Re: CFV: New OpenJFX Committer:Daniel Blaukopf
Vote: yes. Artem On 8/6/2013 7:15 PM, David Hill wrote: I hereby nominate Daniel Blaukopf to OpenJFX Committer. Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the embedded device space. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf Votes are due by Aug 21, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, David [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
hg: openjfx/8/graphics/rt: 3 new changesets
Changeset: 1661f722d536 Author:Vasiliy Baranov vasiliy.bara...@oracle.com Date: 2013-08-06 19:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1661f722d536 Fix Mac build broken by the recent fix for RT-32039 ! modules/web/src/main/native/Source/WebCore/mapfile-macosx ! modules/web/src/main/native/Source/WebCore/mapfile-vers Changeset: 59419bdda806 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-08-06 08:27 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/59419bdda806 RT-27541: Add RTL support to TextFlow ! modules/graphics/src/main/java/javafx/scene/text/TextFlow.java Changeset: 0a2b4115d537 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-08-06 08:31 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0a2b4115d537 Removing out-of-date comment in checkOrientation + dosmetic changes (trailing whitespace) ! modules/graphics/src/main/java/javafx/scene/text/Text.java
Re: A different way to handle pulse timing
On 8/6/13 Aug 6, 10:07 AM, Scott Palmer wrote: On 2013-08-06, at 9:10 AM, Artem Ananiev artem.anan...@oracle.com wrote: On 8/5/2013 10:26 PM, Richard Bair wrote: In this proposal, we also would be putting the next pulse on the end of the queue, so it is impossible to starve input events. Putting the next pulse on the end of the queue is surprisingly difficult task, at least on Windows. If we use standard APIs provided by the platform, PostMessage() and SendMessage(), events are always put to the head of the queue. If we use timer events, they are of the lowest priority, so we'll have paint starvation instead of input events starvation. If the OS message queue is fundamentally broken (i.e. it does not behave like a queue), can all this be done on a proper queue that you have control over? I.e. in the OS-specific message loop, just move the messages to a more reasonably behaved queue. Posting a request to process a pulse would simply queue the operation on the well behaved queue and not use the OS PostMessage or SendMessage mechanism at all. I admit to not knowing enough about Windows message processing to know if that even makes sense. (Windows seriously doesn't have a mechanism to put something on the tail end of the message queue? Wow, don't they understand how a queue is supposed to work?) This is what Glass/Lens does - the user event thread is all in Java. But then - we also don't have to deal with any pesky native window managers :-) Lens input events are taken from as close as we have to a native event loop (on an input thread) and posted to the java based user event thread, just like any other Application.InvokeLater (first in, first out queue). This also saves Lens a bit of JNI handling as most user (non input events) never leave java this way. Dave Scott -- David Hill david.h...@oracle.com Java Embedded Development Sometimes the questions are complicated and the answers are simple. -- Dr. Seuss (1904 - 1991)
Re: CFV: New OpenJFX Committer: Seeon Birger
Vote: yes David Hill wrote: I hereby nominate Seeon Birger to OpenJFX Committer. Seeon is a member of the Embedded Device team, which means he works across various aspects of the platform, but in particular, Lens and Virtual Keyboard. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=seeon.birger Votes are due by Aug 21, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Dave [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
Re: CFV: New OpenJFX Committer:Daniel Blaukopf
Vote: yes David Hill wrote: I hereby nominate Daniel Blaukopf to OpenJFX Committer. Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the embedded device space. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf Votes are due by Aug 21, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, David [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
Re: Brick Breaker ball jitter
Hi John, Sorry, the Brick Breaker fix is not yet in Ensemble8. The fix is in the standalone version of Brick Breaker. The Jira issue for the port is RT-30864. Thanks, Debbie Message: 4 Date: Tue, 6 Aug 2013 20:41:45 +1000 From: John C. Turnbull ozem...@ozemail.com.au Subject: Brick Breaker ball jitter To: openjfx-dev@openjdk.java.net Message-ID: 008601ce9291$8c016d20$a4044760$@ozemail.com.au Content-Type: text/plain; charset=us-ascii I seem to remember some time ago that work was done on reducing the jitter in the ball's motion in the Brick Breaker demo in Ensemble8. Did this ever make it into the main line? I ask because I have just installed JDK 8 b101 and the ball still shows very significant jitter in its motion on this Windows 7 x64 machine. Thanks, -jct
Re: CFV: New OpenJFX Committer:Daniel Blaukopf
Vote: yes. Jasper On Aug 6, 2013, at 8:15 AM, David Hill david.h...@oracle.com wrote: I hereby nominate Daniel Blaukopf to OpenJFX Committer. Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the embedded device space. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf Votes are due by Aug 21, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, David [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
Re: CFV: New OpenJFX Committer:Daniel Blaukopf
Vote: yes On Aug 6, 2013, at 8:15 AM, David Hill david.h...@oracle.com wrote: I hereby nominate Daniel Blaukopf to OpenJFX Committer. Daniel is a member of the Embedded Device team, which means he works across various aspects of the platform. He is also the architect for the embedded device space. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=daniel.blaukopf Votes are due by Aug 21, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, David [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
Re: CFV: New OpenJFX Committer: Seeon Birger
Vote: yes On Aug 6, 2013, at 8:16 AM, David Hill david.h...@oracle.com wrote: I hereby nominate Seeon Birger to OpenJFX Committer. Seeon is a member of the Embedded Device team, which means he works across various aspects of the platform, but in particular, Lens and Virtual Keyboard. His recent work can be seen here: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=seeon.birger Votes are due by Aug 21, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Dave [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
hg: openjfx/8/graphics/rt: 40 new changesets
Changeset: 5a2bdb89b8a1 Author:hudson Date: 2013-08-01 08:57 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5a2bdb89b8a1 Added tag 8.0-b101 for changeset fe19fc3820f3 ! .hgtags Changeset: 1881571d12e6 Author:mv157916 Date: 2013-08-02 00:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1881571d12e6 RT-32076: Update the JDK build number to b101 in rt/build.properties file in the JavaFX 8 Master forest. ! build.properties Changeset: 02439ac5011b Author:jgiles Date: 2013-07-30 12:32 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/02439ac5011b RT-31577: Clearing the selection in TableView doesn't call ChangeListener on SelectionModel selectedItemProperty ! modules/controls/src/main/java/javafx/scene/control/TableView.java ! modules/controls/src/main/java/javafx/scene/control/TreeTableView.java ! modules/controls/src/test/java/javafx/scene/control/ListViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewKeyInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 908485f56f7f Author:jgiles Date: 2013-07-30 15:22 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/908485f56f7f RT-30253: [TreeView] graphics is not rendered immediately when prebuilt cell factory is used. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/cell/CheckBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ComboBoxTreeCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java Changeset: be80dfafbd68 Author:jgiles Date: 2013-07-30 15:38 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/be80dfafbd68 RT-30754: ComboBox doesn't align properly with baseline ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java Changeset: f0fb93f22f9b Author:jgiles Date: 2013-07-31 09:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f0fb93f22f9b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 60e14d6f298e Author:jgiles Date: 2013-07-31 10:56 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/60e14d6f298e RT-31570: Make some VirtualFlow method protected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 0b89acf5c119 Author:jgiles Date: 2013-07-31 11:26 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0b89acf5c119 RT-31901: Regression: scrollbar issue with TitledPane ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 32a15e40d649 Author:jgiles Date: 2013-07-31 12:23 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/32a15e40d649 RT-31997: ChoiceBox and ComboBox popup menu appear shifted vertically (by ~5px) ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! modules/graphics/src/main/java/com/sun/javafx/Utils.java Changeset: 4f3014d423e9 Author:jgiles Date: 2013-07-31 14:10 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4f3014d423e9 Partial fix for RT-31918: ComboBox doesn't render scroll bars The exception listed in the jira issue no longer occurs. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 6ac8a1f0708d Author:jgiles Date: 2013-07-31 14:36 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6ac8a1f0708d RT-30400: ProgressBar cell factory renders progress bars in empty cells ! modules/controls/src/main/java/javafx/scene/control/cell/ProgressBarTableCell.java ! modules/controls/src/main/java/javafx/scene/control/cell/ProgressBarTreeTableCell.java ! modules/controls/src/test/java/javafx/scene/control/cell/ProgressBarTableCellTest.java ! modules/controls/src/test/java/javafx/scene/control/cell/ProgressBarTreeTableCellTest.java Changeset: 1468c900ae93 Author:jgiles Date: 2013-07-31 14:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1468c900ae93 RT-30394: TreeTableView focus model returns wrong focused index ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/test/java/javafx/scene/control/ListViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java !
hg: openjfx/8/graphics/rt: Fix to RT-32129: Light's scope optimization
Changeset: 2fa94a5ed08f Author:Chien Yang chien.y...@orcale.com Date: 2013-08-06 13:36 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2fa94a5ed08f Fix to RT-32129: Light's scope optimization Reviewed by Kevin and Thor ! modules/graphics/src/main/java/com/sun/javafx/scene/DirtyBits.java ! modules/graphics/src/main/java/javafx/scene/LightBase.java
Swing and JavaFX thread merge
Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance, -- Pedro Duque Vieira
RE: Performant Controls (hijacking Re: Developing controls based on Canvas?)
. . . imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general strategy? I'd use some like yworks yfiles for this, it seems pretty similar = http://www.yworks.com/en/products_yfiles_practicalinfo_gallery.html (this page is a very nice example of a showcase by the way :-) Sebastian Rheinnecker from yworks created a prototype of their tool in JavaFX. He has posted on this list before, so you can find his email in the archives if you want to ask questions about it. The yworks stuff is a very nice graphing system that scales to very large graphs and is implemented in lots of different technologies, so perhaps a good contact point if they are willing to discuss implementation details. There is also the primarily JavaFX based Dex Data Explorer which also seems pretty similar (albeit using a polyglot programming approach) = http://www.javainc.com/projects/dex/ -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Monday, August 05, 2013 5:39 PM To: Jonathan Giles Cc: openjfx-dev@openjdk.java.net List Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) Sneaking in here, as you've given an opening with if implemented wisely, there is very little that a scenegraph-based approach can't do. The question I've been asking for a while is what does implemented wisely look like in JFX. This has come up in the performance conversations, the game conversations, the CAD conversations, and many other places. No one seems to have an answer, but you're building extremely complex stuff on a regular basis - what's your tips? When you say you only have 20 visible nodes out of 1000's in general are the other nodes: a) in the scenegraph and set to not visible b) in memory but not in the scenegraph - added/removed when scrolled into view and out of view c) not in memory, created, added and then removed, destroyed when scrolled into view and out of view d) something else? I know Table uses a rubber stamp approach, where it re-uses cell views where possible, but let's say every row in my 100,000 row Table was uniquely rendered using a different cell. What would happen under the covers? How do you work out the scroll range as well? Each cell can be a unique height right? How do you know the extents of the vertical scrolling without instantiating and rendering everything? Is this what you do? What if a cell is changing size (has a collapsable pane in it, etc) - what happens to the vertical scroll range? Do any of the controls have zooming on them? Have you had to deal with this and have you got a strategy for handling this with respect to scroll bounds, working out which nodes are in view, scaling fonts, etc? Could you hazard a guess at what you would do if you had to implement zooming on a Table for example? Maybe the Table is lucky with its restrictive grid like layout but imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general strategy? On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles jonathan.gi...@oracle.comwrote: I think it would pay to take a step back and understand why you think a 'traditional' scenegraph-based (or retained mode) control is not sufficient for your needs? Unfortunately you've not detailed your use case, so it is hard to give any specific advice. Are you able to give any details about what it is you're trying to build and why you think the normal approach to building controls is not sufficient? We've built some fairly complex controls using this approach, and if implemented wisely, there is very little that a scenegraph-based approach can't do. Specifically, do you think your control will render all of the 'thousands of nodes' at once, or will many of these nodes be off screen or otherwise not visible at any one time? For things like the TableView we only render the nodes that are visible. This means that regardless of whether there are 100 or 1,000,000 rows of data, we only have visual nodes for the 20 visible rows, for example. Keeping your scenegraph as minimal as possible is always a very wise idea, if performance is a concern. As you note, the other problem is that you will run into issues if you want to mix canvas rendering with the scenegraph-based controls like Button. The best you're likely to achieve (having not tried it personally) is to position the control on top of the canvas, rather than attempting to render the control inside the canvas (and having to then deal with event handling,
hg: openjfx/8/controls/rt: 4 new changesets
Changeset: 925eeb161438 Author:jgiles Date: 2013-08-07 09:05 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/925eeb161438 RT-32139: Can't change ComboBox value in change listener ! modules/controls/src/main/java/javafx/scene/control/SingleSelectionModel.java ! modules/controls/src/test/java/javafx/scene/control/ComboBoxTest.java Changeset: 84847b5a5dbc Author:jgiles Date: 2013-08-07 09:50 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/84847b5a5dbc RT-32119: ListView doesn't unselect correct items when Shift + left mouse btn is used (Same bug also existed for TableView, TreeView and TreeTableView, so it has been fixed there too) ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! modules/controls/src/test/java/javafx/scene/control/ListViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewMouseInputTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeViewMouseInputTest.java Changeset: 210aa0f86593 Author:jgiles Date: 2013-08-07 13:24 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/210aa0f86593 RT-27156: Animated TitledPane does not synch animation with its content RT-30566: Opening/Closing Animation of TitledPane in nested Accordions with some Controls not working as expected ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TitledPaneSkin.java Changeset: f63ed218267f Author:jgiles Date: 2013-08-07 13:32 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f63ed218267f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt
