Review Request: Accordion/ScrollPane : Scrollbars appear in wrong place for Accordion close/stretch/re-open
Hello, Please review the fix for: https://javafx-jira.kenai.com/browse/RT-32692#comment-367554 available here: http://cr.openjdk.java.net/~msladecek/rt-32692/webrev.00/ http://cr.openjdk.java.net/%7Emsladecek/rt-32692/webrev.00/ Thanks, -Martin
hg: openjfx/8/graphics/rt: RT-13813: Full screen overlay warning needs to be MT safe
Changeset: fbdf0e6d81f6 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-11-08 12:10 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fbdf0e6d81f6 RT-13813: Full screen overlay warning needs to be MT safe Reviewed-by: art, snorthov ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/OverlayWarning.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewPainter.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/ViewScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java ! modules/graphics/src/main/java/com/sun/prism/PresentableState.java ! modules/graphics/src/main/java/javafx/scene/Parent.java
Re: Scene Builder performance regression between 1.1 and 2.0
On my Ubuntu 13.10 x64, I don't see this menu issue. I suspect a driver issue. Jerome On 11/7/13 6:33 PM, Philipp Dörfler wrote: I also noticed a performance regression (Linux x64). SceneBuilder 1.1 was already kind of slow, but 2.0 feels even less snappy. The menus feel particularly sluggish and I can even see parts of the GPU's memory content right before the menu items are being drawn over it. Am 07.11.2013 12:49 schrieb Artem Ananiev artem.anan...@oracle.com: On 11/7/2013 10:11 AM, Felix Bembrick wrote: Scene Builder 2.0 has very serious performance issues (on my machines at least). When running 1.1 2.0 side-by-side, 1.1 is very responsive and behaves very well. On the contrary, 2.0 is extremely sluggish with a few seconds between clicking on a control and the selection handles appearing and trying to resize the properties pane is so slow that it is not usable. It may be caused by exceptions or logging output to stdout/err... Thanks, Artem I see this version of Scene Builder was built with JDK8 b112. Is anyone else experiencing this? Have I just hit on some subtle performance issue with JavaFX 8 and the GPU drivers on this machine (which is Windows 7 64-bit BTW).? Felix
hg: openjfx/8/graphics/rt: RT-34077: [Graphics, Swing] JFXPanel with WebView in JDK
Changeset: 0bdc357282a7 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-11-08 14:15 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0bdc357282a7 RT-34077: [Graphics, Swing] JFXPanel with WebView in JDK Reviewed-by: anthony, ant ! modules/swing/src/main/java/javafx/embed/swing/JFXPanel.java
Build fail: unresolved external symbol mainCRTStartup
Hi, I've just cloned a new workspace from ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx and tried to build it. The following error encountered: link /LIBPATH:..\lib /NOLOGO /MAP /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /MANIFEST /MANIFESTFILE:obj\DerivedSourcesJava.intermediate.manifest /OUT:..\lib\DerivedSourcesJava.exe @C:\Users\lp154592\AppData\Local\Temp\nm9A16.tmp LINK : error LNK2001: unresolved external symbol mainCRTStartup ..\lib\DerivedSourcesJava.exe : fatal error LNK1120: 1 unresolved externals My box is Windows 7 64-bit with MSVS 10 installed; Gradle 1.4 is used for building. Any suggestions? Thanks, Leonid
Re: did anyone encountered this?
Let's consider flipping the switch so people don't see the problem or *possibly* switching to gradle 1.8. This is something I see all the time and I'm betting others do too. I have filed https://javafx-jira.kenai.com/browse/RT-34171 to track the issue. Steve On 2013-11-08 8:03 AM, Kevin Rushforth wrote: As a follow-up to this, yes it has been fixed in gradle 1.8: http://issues.gradle.org/browse/GRADLE-2831 We won't be switching our builds to gradle 1.8 for FX 8, but if developers want to give it a try on their own systems, that would be fine. -- Kevin Kevin Rushforth wrote: I see this from time to time. This is a bug in the version of ant that is used by gradle for dependencies. It has been reported that gradle 1.8 may have a newer version of ant that fixes this bug. In the mean time, a less intrusive workaround is: gradle -PUSE_DEPEND=false ... If enough people are getting bitten by this, should we consider making USE_DEPEND=false the default? -- Kevin Artem Ananiev wrote: Yes, I've seen this many times. I didn't spend much time trying to understand what is the problem, though. The workaround is simple: just delete 3DViewer build folder. Thanks, Artem On 11/6/2013 5:35 PM, Assaf Yavnai wrote: :apps:experiments:3DViewer:compileJava FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':apps:experiments:3DViewer:compileJava'. java.lang.ClassFormatError: Invalid Constant Pool entry Type 18 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 39.292 secs assaf@assaf-Latitude-E6410:~/ws/udev-refactoring/rt$ java -versionjava version 1.8.0-ea Java(TM) SE Runtime Environment (build 1.8.0-ea-b113) Java HotSpot(TM) Server VM (build 25.0-b55, mixed mode) Thanks, Assaf
Review Request: RT-34107 [Mac] Cannot set app name for menu items in app menu of system menubar
Hello, OpenJFX Community. Please review the fix for the issue: https://javafx-jira.kenai.com/browse/RT-34107 The details are available in the bug comments. Thank you. With best regards. Petr.
Re: Build fail: unresolved external symbol mainCRTStartup
Hi Leonid, I have the same configuration as you I think. I'm just making sure I can build. First, do you have 32-bit JDK8? Are you running under a cygwin shell? What is your gradle command line? Steve On 2013-11-08 9:08 AM, Leonid Popov wrote: Hi, I've just cloned a new workspace from ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx and tried to build it. The following error encountered: link /LIBPATH:..\lib /NOLOGO /MAP /INCREMENTAL:NO /SUBSYSTEM:CONSOLE /MANIFEST /MANIFESTFILE:obj\DerivedSourcesJava.intermediate.manifest /OUT:..\lib\DerivedSourcesJava.exe @C:\Users\lp154592\AppData\Local\Temp\nm9A16.tmp LINK : error LNK2001: unresolved external symbol mainCRTStartup ..\lib\DerivedSourcesJava.exe : fatal error LNK1120: 1 unresolved externals My box is Windows 7 64-bit with MSVS 10 installed; Gradle 1.4 is used for building. Any suggestions? Thanks, Leonid
hg: openjfx/8/graphics/rt: RT-34023: border-image-slice as percentage is relative to the region size instead of image size
Changeset: 346492183eeb Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-11-08 09:48 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/346492183eeb RT-34023: border-image-slice as percentage is relative to the region size instead of image size Reviewed-by: Jim Graham ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java
hg: openjfx/8/graphics/rt: RT-34169: jfxswt.jar is missing from in JDK 8-b115
Changeset: febed4cbc4c2 Author:kcr Date: 2013-11-08 11:28 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/febed4cbc4c2 RT-34169: jfxswt.jar is missing from in JDK 8-b115 ! build.gradle
hg: openjfx/8/graphics/rt: RT-34152: Password Field: ctrl + delete/backspace deletes the whole word
Changeset: 0a123183bb8a Author:leifs Date: 2013-11-08 12:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0a123183bb8a RT-34152: Password Field: ctrl + delete/backspace deletes the whole word Reviewed-by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java
hg: openjfx/8/graphics/rt: RT-34178: NPE in TextFieldSkin of PasswordField
Changeset: ee1ca7057294 Author:leifs Date: 2013-11-08 12:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ee1ca7057294 RT-34178: NPE in TextFieldSkin of PasswordField ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! modules/controls/src/test/java/com/sun/javafx/scene/control/skin/TextInputControlSkinTest.java
Re: JavaFX on iOS and Android: The real problem and challenge
Yes, I agree, we need professional JVM ports for iOS, Android and Windows 8. @Oracle: Could you set up the according project sites for these 3 platforms on openjdk.java.net and document what exactly has to be done to port OpenJDK (at least some kind of JavaFX compact profile e.g. without the AWT stack) to these platforms? Also the Mercurial repository and the build should be prepared. I think if there were an easy starting point it would lower the barrier to work on these ports. -Florian Am Donnerstag, 24. Oktober 2013, 08.41:32 schrieb Tobias Bley: Hello to the community, I read the last discussion about „JavaFX native look and feel“ and have to get out of my mind the following: In my opinion the MAIN point is not „how to bring the native look and feel to iOS/Android“, the real MAIN issue is: we need a professional JVM(!) which works performant and reliable on iOS, Android and Windows 8! Only if we have such a JVM, developers and companies are motivated to develop real commercial apps with JavaFX and contribute stuff back to OpenJFX! RoboVM is a good „prototype“. Niklas is currently one of the most important people for the JavaFX community. He and his company has build the first and one and only real solution to deploy Java and JavaFX code to the iOS platform! His work is really great! But: He is only one(!) person! This kind of complex task I would expect from big companies like Oracle, IBM, SAP or Twitter. But from this direction we don’t hear anything about it. It is not enough that people like Niklas (Trillian AB) or Matthias and me (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all experimental stuff! Yes, currently we can start JavaFX apps on a real iPhone and iPad. And yes, we have managed to start JavaFX on a real Android device using the Dalvik VM. BUT: this is not a long term solution and only experimental! RoboVM on iOS uses the android class library instead of the real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM and the Android class library as well! So both solutions use the real Java platform (=OpenJDK)! In my opinion there are only two solutions: 1) Oracle releases their JVM for iOS and Android. 2) The „community“ starts a new company who develops a professional, performant and reliable solution for „JavaFX on iOS and Android“ which contains of a JVM and the 6 degrees Felix described in his blog post, mainly native integration (API) and look and feel (skins, native controls). Cheers, Tobi Am 23.10.2013 um 22:30 schrieb Richard Bair richard.b...@oracle.com: Yes, definitely. On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com wrote: This is starting to sound like it may also partially address the issue in the desktop space of supplying a native surface (the heavyweight) to draw in that is part of the scene graph. It may not be the ideal solution, but could be useful for specific use cases, like a video preview overlay. Would that make any sense? Scott On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair richard.b...@oracle.com wrote: To do this we need to either solve the auto-layer problem in the NG nodes / Glass / Quantum, or we need to ask the app developer to use SubScene and put all the native stuff in a single SubScene, and all lightweight content above and below it. For the short term, we could use the SubScene approach (Just be careful and don't draw lightweight on top of heavyweights unless you layer an entire sub scene above them) which is probably a perfectly workable solution in the short term. Then somebody just needs to write a set of skins (which can be done in an external project) that map various UI controls directly to native controls. This approach would allow people to have completely native controls while using the FX API, or they can use the lightweight controls (with Modena or with an iOS 7 skin or iOS 6 skin etc). I'm thinking about how to implement the auto-layer, and I'm not sure of the best approach. It seems like you need to hook into the sync-time to determine which nodes can be batched into the same layer, reusing previous layers where possible. If there is a way to then setup the NG peer side so that it thinks it was setup in sub scenes etc, although it really wasn't, then that would leave prism out of the problem (which makes this an easier thing to pull off). hmmm. SubScene itself has a peer. So what I'm thinking is, suppose I have a package: com.sun.javafx.ext.ios.controls and in this package you have all the skins. There is also someplace in here a map of skin - sub scene peer, indicating which of the nodes is in which sub scene peer (layer). Then when the sync takes place, a skin node looks back at siblings etc to determine if it can be placed in the same layer as something before it. If so, then it
Re: JavaFX on iOS and Android: The real problem and challenge
On 11/8/13 10:30 PM, Florian Brunner wrote: @Oracle: Could you set up the according project sites for these 3 platforms on openjdk.java.net Please see http://openjdk.java.net/projects/ for how Projects work. cheers, dalibor topic -- Oracle http://www.oracle.com Dalibor Topic | Principal Product Manager Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961 tel:+491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment
Re: JavaFX on iOS and Android: The real problem and challenge
I thought those JVM's were considered to be steps in progression toward production JVM's? Though the push was toward full utility, I thought the wagon train would circle back around to do optimization passes and so forth? Remember we started from absolutely nothing and a question as to its possibility? Now we know conclusively that it's possible - and I thought the work could be extended upon? If Oracle is to be the true steward of Java, I think they need to do more than what I call Gesturing. If one intends to end hunger in Africa, you get on a plane and go there and physically work on the problem until it's solved, not put your (albeit grand gesture) of 1 million dollars in the collection plate and forget about it. Of course, it's easy for people like me to sit back and judge - but I didn't go and purchase Sun and announce to the world my stewardship of one of the most important technologies in existence. Either do it all the way or stay the **^ out of the way - as far as I'm concerned. Of course this is not to condemn the heroic efforts of people here who live and breathe their contribution to Java. I just think a partial commitment (no matter how grand), is in the end detrimental. Sorry... On Thu, Oct 24, 2013 at 1:41 AM, Tobias Bley t...@ultramixer.com wrote: Hello to the community, I read the last discussion about „JavaFX native look and feel“ and have to get out of my mind the following: In my opinion the MAIN point is not „how to bring the native look and feel to iOS/Android“, the real MAIN issue is: we need a professional JVM(!) which works performant and reliable on iOS, Android and Windows 8! Only if we have such a JVM, developers and companies are motivated to develop real commercial apps with JavaFX and contribute stuff back to OpenJFX! RoboVM is a good „prototype“. Niklas is currently one of the most important people for the JavaFX community. He and his company has build the first and one and only real solution to deploy Java and JavaFX code to the iOS platform! His work is really great! But: He is only one(!) person! This kind of complex task I would expect from big companies like Oracle, IBM, SAP or Twitter. But from this direction we don’t hear anything about it. It is not enough that people like Niklas (Trillian AB) or Matthias and me (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all experimental stuff! Yes, currently we can start JavaFX apps on a real iPhone and iPad. And yes, we have managed to start JavaFX on a real Android device using the Dalvik VM. BUT: this is not a long term solution and only experimental! RoboVM on iOS uses the android class library instead of the real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM and the Android class library as well! So both solutions use the real Java platform (=OpenJDK)! In my opinion there are only two solutions: 1) Oracle releases their JVM for iOS and Android. 2) The „community“ starts a new company who develops a professional, performant and reliable solution for „JavaFX on iOS and Android“ which contains of a JVM and the 6 degrees Felix described in his blog post, mainly native integration (API) and look and feel (skins, native controls). Cheers, Tobi Am 23.10.2013 um 22:30 schrieb Richard Bair richard.b...@oracle.com: Yes, definitely. On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com wrote: This is starting to sound like it may also partially address the issue in the desktop space of supplying a native surface (the heavyweight) to draw in that is part of the scene graph. It may not be the ideal solution, but could be useful for specific use cases, like a video preview overlay. Would that make any sense? Scott On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair richard.b...@oracle.com wrote: To do this we need to either solve the auto-layer problem in the NG nodes / Glass / Quantum, or we need to ask the app developer to use SubScene and put all the native stuff in a single SubScene, and all lightweight content above and below it. For the short term, we could use the SubScene approach (Just be careful and don't draw lightweight on top of heavyweights unless you layer an entire sub scene above them) which is probably a perfectly workable solution in the short term. Then somebody just needs to write a set of skins (which can be done in an external project) that map various UI controls directly to native controls. This approach would allow people to have completely native controls while using the FX API, or they can use the lightweight controls (with Modena or with an iOS 7 skin or iOS 6 skin etc). I'm thinking about how to implement the auto-layer, and I'm not sure of the best approach. It seems like you need to hook into the sync-time to determine which nodes can be batched into the same layer, reusing previous layers where possible. If there is a way to then setup the NG peer side so that
Re: JavaFX on iOS and Android: The real problem and challenge
Hi Dalibor, Thanks for the link. I've read now the process described at http://openjdk.java.net/projects/#new-project I'm fine to start the discussion (Step 0), but I think it would help if we could find here some initial contributors/ leaders. I, myself, won't be able to activly work on the ports. For one thing I'm not really familiar with native programming and for another I'm already spending a lot of my spare time at the other end of the JavaFX ecosystem: I'm developing a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first) (see: http://wiki.drombler.org/DromblerFX ). -Florian Am Freitag, 8. November 2013, 22.53:26 schrieb Dalibor Topic: On 11/8/13 10:30 PM, Florian Brunner wrote: @Oracle: Could you set up the according project sites for these 3 platforms on openjdk.java.net Please see http://openjdk.java.net/projects/ for how Projects work. cheers, dalibor topic
Re: JavaFX on iOS and Android: The real problem and challenge
Totally, I think the normal process for this is to create a new OpenJDK project, is it not? Can you take a look at the OpenJDK bylaws and report back on the process? I think it would be awesome to do a port. Note that there are a few OpenJDK ports already which have ARM support, you might want to look there as a starting point? Richard On Nov 8, 2013, at 1:29 PM, Florian Brunner fbrun...@gmx.ch wrote: Yes, I agree, we need professional JVM ports for iOS, Android and Windows 8. @Oracle: Could you set up the according project sites for these 3 platforms on openjdk.java.net and document what exactly has to be done to port OpenJDK (at least some kind of JavaFX compact profile e.g. without the AWT stack) to these platforms? Also the Mercurial repository and the build should be prepared. I think if there were an easy starting point it would lower the barrier to work on these ports. -Florian Am Donnerstag, 24. Oktober 2013, 08.41:32 schrieb Tobias Bley: Hello to the community, I read the last discussion about „JavaFX native look and feel“ and have to get out of my mind the following: In my opinion the MAIN point is not „how to bring the native look and feel to iOS/Android“, the real MAIN issue is: we need a professional JVM(!) which works performant and reliable on iOS, Android and Windows 8! Only if we have such a JVM, developers and companies are motivated to develop real commercial apps with JavaFX and contribute stuff back to OpenJFX! RoboVM is a good „prototype“. Niklas is currently one of the most important people for the JavaFX community. He and his company has build the first and one and only real solution to deploy Java and JavaFX code to the iOS platform! His work is really great! But: He is only one(!) person! This kind of complex task I would expect from big companies like Oracle, IBM, SAP or Twitter. But from this direction we don’t hear anything about it. It is not enough that people like Niklas (Trillian AB) or Matthias and me (UltraMixer) are trying to bring JavaFX to iOS and Android. It’s all experimental stuff! Yes, currently we can start JavaFX apps on a real iPhone and iPad. And yes, we have managed to start JavaFX on a real Android device using the Dalvik VM. BUT: this is not a long term solution and only experimental! RoboVM on iOS uses the android class library instead of the real Java = OpenJDK. Our „JavaFX on Android“ solution uses Google Dalvik VM and the Android class library as well! So both solutions use the real Java platform (=OpenJDK)! In my opinion there are only two solutions: 1) Oracle releases their JVM for iOS and Android. 2) The „community“ starts a new company who develops a professional, performant and reliable solution for „JavaFX on iOS and Android“ which contains of a JVM and the 6 degrees Felix described in his blog post, mainly native integration (API) and look and feel (skins, native controls). Cheers, Tobi Am 23.10.2013 um 22:30 schrieb Richard Bair richard.b...@oracle.com: Yes, definitely. On Oct 23, 2013, at 11:52 AM, Scott Palmer swpal...@gmail.com wrote: This is starting to sound like it may also partially address the issue in the desktop space of supplying a native surface (the heavyweight) to draw in that is part of the scene graph. It may not be the ideal solution, but could be useful for specific use cases, like a video preview overlay. Would that make any sense? Scott On Tue, Oct 22, 2013 at 7:59 PM, Richard Bair richard.b...@oracle.com wrote: To do this we need to either solve the auto-layer problem in the NG nodes / Glass / Quantum, or we need to ask the app developer to use SubScene and put all the native stuff in a single SubScene, and all lightweight content above and below it. For the short term, we could use the SubScene approach (Just be careful and don't draw lightweight on top of heavyweights unless you layer an entire sub scene above them) which is probably a perfectly workable solution in the short term. Then somebody just needs to write a set of skins (which can be done in an external project) that map various UI controls directly to native controls. This approach would allow people to have completely native controls while using the FX API, or they can use the lightweight controls (with Modena or with an iOS 7 skin or iOS 6 skin etc). I'm thinking about how to implement the auto-layer, and I'm not sure of the best approach. It seems like you need to hook into the sync-time to determine which nodes can be batched into the same layer, reusing previous layers where possible. If there is a way to then setup the NG peer side so that it thinks it was setup in sub scenes etc, although it really wasn't, then that would leave prism out of the problem (which makes this an easier thing to pull off). hmmm. SubScene itself has a peer. So what I'm thinking is, suppose I have a package:
Re: review request RT-34090: NGRegion border painting seems odd
Hi Felipe, The changes look good... ...jim On 11/6/13 3:06 PM, Felipe Heidrich wrote: Hi Jim, Please review https://javafx-jira.kenai.com/browse/RT-34090 http://cr.openjdk.java.net/~fheidric/RT34090/webrev/ Thanks Felipe
Re: review request: RT-32837: Ensemble8 left arrow has line artifact
Hi Felipe, That looks fine - was there a reason to have the variable to store the predetermined border size? ...jim On 11/4/13 4:55 PM, Felipe Heidrich wrote: Hi Jim Please review https://javafx-jira.kenai.com/browse/RT-32837 You will find the webrev at the end: http://cr.openjdk.java.net/~fheidric/RT32837-2/webrev/ Thank you Felipe
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 26a678a14199 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-11-08 15:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/26a678a14199 RT-34090: NGRegion border painting seems odd Reviewed-by: Jim Graham ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java Changeset: 9989721f31a2 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-11-08 15:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9989721f31a2 RT-32837: Ensemble8 left arrow has line artifact Reviewed-by: Jim Graham ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java
