hg: openjfx/8u-dev/rt: 3 new changesets
Changeset: 4b558607b25b Author:Martin Sladecek Date: 2014-04-30 08:19 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4b558607b25b RT-33688 [PieChart] label line length equal to 0 results in label disappearing. Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/NumberAxis.java ! modules/controls/src/main/java/javafx/scene/chart/PieChart.java Changeset: 3c4fb09288b6 Author:Martin Sladecek Date: 2014-04-30 08:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3c4fb09288b6 RT-36720 [Charts] LineChart connects non-successive data points Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/AreaChart.java ! modules/controls/src/main/java/javafx/scene/chart/BarChart.java ! modules/controls/src/main/java/javafx/scene/chart/BubbleChart.java ! modules/controls/src/main/java/javafx/scene/chart/CategoryAxis.java ! modules/controls/src/main/java/javafx/scene/chart/LineChart.java ! modules/controls/src/main/java/javafx/scene/chart/ScatterChart.java Changeset: b524bb50da08 Author:Martin Sladecek Date: 2014-04-30 08:24 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b524bb50da08 Reverted accidentally commited changed to NumberAxis (from 4b558607b25b) ! modules/controls/src/main/java/javafx/scene/chart/NumberAxis.java
hg: openjfx/8u-dev/rt: 3 new changesets
Changeset: 26306d581529 Author:Felipe Heidrich Date: 2014-04-29 17:09 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/26306d581529 [Accessibility] Fix hanging when traversing out of textfield/area (infinity loop in MoveEndpointByUnit). ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java Changeset: 822a99443a4e Author:jgiles Date: 2014-04-30 11:01 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/822a99443a4e RT-36908: [TabPane] If first tab is disabled, its content is still shown at startup ! modules/controls/src/main/java/javafx/scene/control/TabPane.java ! modules/controls/src/test/java/javafx/scene/control/TabPaneTest.java Changeset: 5c12dcee4f69 Author:jgiles Date: 2014-04-30 12:13 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/5c12dcee4f69 RT-35981: HelloTabPane: white rectangle in the tab header I also took this opportunity to continue to further clean up TabPaneSkin and add in mouse wheel scrolling for tab panes with overflowing tabs. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java
hg: openjfx/8u-dev/rt: [Accessibility] RT-36903 - fix EDITABLE attribute for Windows; remove a11y re-parenting of listView (as it only causes Mac to fail to read the list); add fix for Mac (using FOCU
Changeset: f1da54afa580 Author:Felipe Heidrich Date: 2014-04-29 16:10 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f1da54afa580 [Accessibility] RT-36903 - fix EDITABLE attribute for Windows; remove a11y re-parenting of listView (as it only causes Mac to fail to read the list); add fix for Mac (using FOCUS_ITEM) to read the list the first time it shows. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java
[8u20] Review Request for RT-36724 JavaFX Packager Renaming
Chris, Kevin, Steve, Please review the javafxpackager renaming changes, in the Jira Jira: https://javafx-jira.kenai.com/browse/RT-36724 WebRev: http://cr.openjdk.java.net/~shemnon/RT-36724/webrev.00/ The areas I most want reviewed are the bash script and the windows launcher, and I also want to make sure it is not going to cause build problems. All of the java changes relate to package relocation and leaving in legacy stubs for the current Ant, Maven, and Gradle plugins. —Danno
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: 588fad80e13c Author:Felipe Heidrich Date: 2014-04-29 11:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/588fad80e13c [Accessibility] RT-36903 - Fix Mac, VO no longer reports 'system dialog' for pop windows. ! modules/graphics/src/main/native-glass/mac/GlassWindow.m Changeset: 3596a176eeed Author:snorthov Date: 2014-04-29 14:24 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3596a176eeed INTELLIJ ONLY: fix project files for rt-closed ! .idea/deploy.iml ! .idea/rt-closed.iml
hg: openjfx/8u-dev/rt: RT-36823: Screen.getPrimary().getDpi() and Toolkit.getDefaultToolkit().getScreenResolution() returns different values
Changeset: ab1603afab46 Author:Anthony Petrov Date: 2014-04-29 22:01 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ab1603afab46 RT-36823: Screen.getPrimary().getDpi() and Toolkit.getDefaultToolkit().getScreenResolution() returns different values Summary: Use Core Graphics API to calculate DPI on Mac Reviewed-by: fheidric, serb ! modules/graphics/src/main/native-glass/mac/GlassScreen.m
hg: openjfx/8u-dev/rt: [Accessibility] RT-36903 - Fix Mac double reading the title for a ComboBox
Changeset: 1d14bbee0c61 Author:Felipe Heidrich Date: 2014-04-29 10:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1d14bbee0c61 [Accessibility] RT-36903 - Fix Mac double reading the title for a ComboBox ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java
hg: openjfx/8u-dev/rt: [Accessibility] RT-36903 - removing ListView-like attributes from ComboBox + Adding EDITABLE attribute so that Mac can use Popup and ComboBox role adequately.
Changeset: 0fea45431933 Author:Felipe Heidrich Date: 2014-04-29 10:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0fea45431933 [Accessibility] RT-36903 - removing ListView-like attributes from ComboBox + Adding EDITABLE attribute so that Mac can use Popup and ComboBox role adequately. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/javafx/scene/control/ComboBox.java ! modules/controls/src/main/java/javafx/scene/control/ComboBoxBase.java ! modules/graphics/src/main/java/com/sun/glass/ui/win/WinAccessible.java
hg: openjfx/8u-dev/rt: [TextFlow] remove unused imports
Changeset: 6dbdf8164fed Author:Felipe Heidrich Date: 2014-04-29 09:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6dbdf8164fed [TextFlow] remove unused imports ! modules/graphics/src/main/java/javafx/scene/text/TextFlow.java
hg: openjfx/8u-dev/rt: [Accessibility] remove unused imports
Changeset: 4886e47258f9 Author:Felipe Heidrich Date: 2014-04-29 09:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4886e47258f9 [Accessibility] remove unused imports ! modules/controls/src/main/java/javafx/scene/control/Accordion.java ! modules/controls/src/main/java/javafx/scene/control/TextArea.java ! modules/controls/src/main/java/javafx/scene/control/TextField.java
Re: Why can Scene's only be constructed on the UI thread?
The snapshot methods already do a thread check and throw an exception if they are called on a thread other than an app thread. -- Kevin Mike Hearn wrote: For a Node to have a peer to dispose, it must have been attached to a live Scene, right, which must be done on the app thread. Requiring nodes to be removed from a live Stage/Scene on the app thread doesn't seem like a big deal. To snapshot you could just throw an exception if someone tries to snapshot a node that isn't a part of a live scene. Also no big deal. Then if a Scene's peer is only constructed when it's attached to a live Stage, there's nothing to do there. So it seems like it shouldn't be too hard? On Tue, Apr 29, 2014 at 8:39 AM, Martin Sladecek wrote: The patch tries to solve the issue by deferring the construction of Scene in PopupWindow, but the issues I ran into just show that it's not enough. In order to fix RT-17716, we need Scene construction outside of the thread. Looking at the Scene code, it seems that there are not that many places where app thread is necessary. The Scene's peer is created only when added to a Window (which is good), but there are still calls that need to be synchronized or transferred to the app thread. Like when a Node is removed from a Scene, it's peer is immediately disposed. And also snapshots require peers (i.e. Scene in a Window), but I guess we can live with that. I'm also not sure about accessibility, maybe the code would need some adjustments as well. -Martin On 04/28/2014 08:18 PM, Kevin Rushforth wrote: Some of this was looked at while trying to solve RT-17716 < https://javafx-jira.kenai.com/browse/RT-17716> (see Martin's patch). I think it would be worth considering relaxing the restriction on constructing Scene and Window (maybe Stage, but I don't think there is a benefit for that one), but it seems that Martin ran into some issues with his specific patch. -- Kevin Richard Bair wrote: Hi, Actually I don’t know of any reason why Window and Scene cannot be created and initialized on any thread. Each of these has a peer, and the *peer* we can’t update except on the right thread (or with care, these are OS specific restrictions or issues). But I don’t see any reason why the Java side cannot be initialized on any background thread. And in fact, that was always my intent for exactly these reasons, having experienced all this pain in Swing before firsthand. Its just work that needs to be done, contributions welcome :-) Richard On Apr 26, 2014, at 12:48 PM, Tony Anecito wrote: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
For a Node to have a peer to dispose, it must have been attached to a live Scene, right, which must be done on the app thread. Requiring nodes to be removed from a live Stage/Scene on the app thread doesn't seem like a big deal. To snapshot you could just throw an exception if someone tries to snapshot a node that isn't a part of a live scene. Also no big deal. Then if a Scene's peer is only constructed when it's attached to a live Stage, there's nothing to do there. So it seems like it shouldn't be too hard? On Tue, Apr 29, 2014 at 8:39 AM, Martin Sladecek wrote: > The patch tries to solve the issue by deferring the construction of Scene > in PopupWindow, but the issues I ran into just show that it's not enough. > In order to fix RT-17716, we need Scene construction outside of the thread. > > Looking at the Scene code, it seems that there are not that many places > where app thread is necessary. The Scene's peer is created only when added > to a Window (which is good), but there are still calls that need to be > synchronized or transferred to the app thread. Like when a Node is removed > from a Scene, it's peer is immediately disposed. And also snapshots require > peers (i.e. Scene in a Window), but I guess we can live with that. > I'm also not sure about accessibility, maybe the code would need some > adjustments as well. > > -Martin > > > On 04/28/2014 08:18 PM, Kevin Rushforth wrote: > >> Some of this was looked at while trying to solve RT-17716 < >> https://javafx-jira.kenai.com/browse/RT-17716> (see Martin's patch). >> >> I think it would be worth considering relaxing the restriction on >> constructing Scene and Window (maybe Stage, but I don't think there is a >> benefit for that one), but it seems that Martin ran into some issues with >> his specific patch. >> >> -- Kevin >> >> >> Richard Bair wrote: >> >>> Hi, >>> >>> Actually I don’t know of any reason why Window and Scene cannot be >>> created and initialized on any thread. Each of these has a peer, and the >>> *peer* we can’t update except on the right thread (or with care, these are >>> OS specific restrictions or issues). But I don’t see any reason why the >>> Java side cannot be initialized on any background thread. And in fact, that >>> was always my intent for exactly these reasons, having experienced all this >>> pain in Swing before firsthand. >>> >>> Its just work that needs to be done, contributions welcome :-) >>> >>> Richard >>> >>> On Apr 26, 2014, at 12:48 PM, Tony Anecito wrote: >>> >>> Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn wrote: At e(fx)clipse we have an FXML to Java translator who removes all the > reflection overhead from FXML. It does not yet support all FXML > features > but we are steadily improving it and with test cases we are able to fix > problems quite fast. Maybe this is an option for you? > > That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem. >>> >>> >
Result: New OpenJFX Committer: Elina Kleyman
Voting for Elina Kleyman to OpenJFX Committer [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Dave [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008677.html -- David Hill Java Embedded Development "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein (1957 - )
hg: openjfx/8u-dev/rt: RT-36745: [Mac] Visual artifacts when using SceneAntialiasing
Changeset: 6c514a282d62 Author:kcr Date: 2014-04-29 05:52 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6c514a282d62 RT-36745: [Mac] Visual artifacts when using SceneAntialiasing Reviewed-by: ckyang, flar ! modules/graphics/src/main/java/com/sun/prism/es2/ES2SwapChain.java ! modules/graphics/src/main/native-prism-es2/GLContext.c
Re: Cleaning up Control codebase - How to deal with StyleableProperty cast
I've found that this works: final StyleableBooleanProperty prop = (StyleableBooleanProperty)focusTraversableProperty(); But I don't know if that will work in every case. On 4/28/14, 5:33 PM, Tom Schindl wrote: Hi, I've been cleaning up the warnings inside the controls code base and one of the warnings left (beside many generic problems in the *View-classes) is the casting from *Property to *StyleableProperty. final StyleableProperty prop = (StyleableProperty)focusTraversableProperty(); now I think I found a way to get away with out an unchecked cast warning by writing final StyleableProperty prop = (StyleableProperty)(WritableValue)focusTraversableProperty(); Anyone having a better idea? Tom
[8u20] Review request for RT-36823: Screen.getPrimary().getDpi() and Toolkit.getDefaultToolkit().getScreenResolution() returns different values
Hi Sergey, Felipe, Please review a fix for https://javafx-jira.kenai.com/browse/RT-36823 Please post your review comments in JIRA. Thanks. -- best regards, Anthony
hg: openjfx/8u-dev/rt: Linux Input Tests: Adding gestures properties to UInput and build files in order to include the tests in nightly cycle
Changeset: 8612ddef00a7 Author:Elina Kleyman Date: 2014-04-29 13:19 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8612ddef00a7 Linux Input Tests: Adding gestures properties to UInput and build files in order to include the tests in nightly cycle ! build.gradle ! tests/system/src/test/java/com/sun/glass/ui/monocle/input/UInput.java
hg: openjfx/8u-dev/rt: RT-36836: Low texture update performance with D3D9Ex enabled
Changeset: d7370ecfa1f3 Author:vadim Date: 2014-04-29 14:15 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d7370ecfa1f3 RT-36836: Low texture update performance with D3D9Ex enabled Reviewed-by: kcr, ckyang ! modules/graphics/src/main/native-prism-d3d/D3DContext.cc ! modules/graphics/src/main/native-prism-d3d/D3DContext.h ! modules/graphics/src/main/native-prism-d3d/D3DResourceFactory.cc ! modules/graphics/src/main/native-prism-d3d/TextureUploader.cc ! modules/graphics/src/main/native-prism-d3d/TextureUploader.h
hg: openjfx/8u-dev/rt: 3 new changesets
Changeset: befd865346f6 Author:jgiles Date: 2014-04-29 15:52 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/befd865346f6 RT-36334: Clean up warnings in control component Contributed-by: Tom Schindl Reviewed-by: jgiles ! modules/controls/src/main/java/javafx/scene/control/Labeled.java ! modules/controls/src/main/java/javafx/scene/control/TableColumnBase.java ! modules/controls/src/main/java/javafx/scene/control/TableView.java Changeset: 93e2f9c84e26 Author:jgiles Date: 2014-04-29 21:41 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/93e2f9c84e26 [TEST ONLY] Disabling unit tests for RT-34493 as they started intermittently failing, most probably due to the RT-36855 changeset. Will reopen RT-34493 to investigate the issue further, but pushing the @Ignore now to fix up the continuous build. ! modules/controls/src/test/java/javafx/scene/control/TableViewTest.java ! modules/controls/src/test/java/javafx/scene/control/TreeTableViewTest.java Changeset: 280e25d20c14 Author:jgiles Date: 2014-04-29 21:42 +1200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/280e25d20c14 [TEST ONLY] Resolving intermittent test failures due to the RT-36827 unit test for ComboBox. ! modules/controls/src/test/java/javafx/scene/control/ComboBoxTest.java
