From james.graham at oracle.com Thu Dec 1 00:02:00 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 30 Nov 2016 16:02:00 -0800 Subject: Follow-on bugs In-Reply-To: References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> Message-ID: <42bbe873-fe55-64dd-50dd-daf40741f061@oracle.com> If this eliminates the regressions in TestNonAA, then I'm for reworking this as an in-place patch for MarlinFX. We can't use the existing Dasher bug for this because Marlin isn't the default renderer, but we can mention the DMarlinFX bug as a workaround for the Dasher bug... ...jim On 11/30/16 2:41 PM, Laurent Bourg?s wrote: > Jim, > > I found the bug in RendererNoAA caused by a 'bad' regexp match: > 0x7fffffff was modified to 0x7Dffffff ! > > so there is no more regression in TestNonAARasterization ! > > Laurent > > > FYI, here is the diff of the correction (over the previous big patches): > > < +++ > new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRenderer.java > 2016-11-30 22:48:51.710420442 +0100 > --- >> +++ > new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRenderer.java > 2016-11-30 23:35:42.879588649 +0100 > 2276,2277c2276,2277 > < + private static final int ALL_BUT_LSB = 0xfffffffe; > < + private static final int ERR_STEP_MAX = 0x7Dffffff; // = 2^31 - 1 > --- >> + private static final int ALL_BUT_LSB = 0xFFFFFFFe; >> + private static final int ERR_STEP_MAX = 0x7FFFFFFF; // = 2^31 - 1 > 2675,2676c2675,2676 > < + // = fixed_floor(x1_fixed + 0x7Dffffff) > < + // and error = fixed_fract(x1_fixed + 0x7Dffffff) > --- >> + // = fixed_floor(x1_fixed + 0x7FFFFFFF) >> + // and error = fixed_fract(x1_fixed + 0x7FFFFFFF) > 2681c2681 > < + + 0x7DffffffL; > --- >> + + 0x7FFFFFFFL; > > < +++ > new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRendererNoAA.java > 2016-11-30 22:48:52.662420517 +0100 > --- >> +++ > new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRendererNoAA.java > 2016-11-30 23:35:43.835587936 +0100 > 4147,4148c4147,4148 > < + private static final int ALL_BUT_LSB = 0xfffffffe; > < + private static final int ERR_STEP_MAX = 0x7Dffffff; // = 2^31 - 1 > --- >> + private static final int ALL_BUT_LSB = 0xFFFFFFFe; >> + private static final int ERR_STEP_MAX = 0x7FFFFFFF; // = 2^31 - 1 > 4537,4538c4537,4538 > < + // = fixed_floor(x1_fixed + 0x7Dffffff) > < + // and error = fixed_fract(x1_fixed + 0x7Dffffff) > --- >> + // = fixed_floor(x1_fixed + 0x7FFFFFFF) >> + // and error = fixed_fract(x1_fixed + 0x7FFFFFFF) > 4543c4543 > < + + 0x7DffffffL; > --- >> + + 0x7FFFFFFFL; > > > > 2016-11-30 23:12 GMT+01:00 Laurent Bourg?s : > >> Jim, >> >> As announced yesterday night, I made a new 'Double' (alias D) pipeline for >> marlinFX with 2 webrevs: >> - cmp that compares the D pipeline vs the float pipeline: >> http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-cmp/ >> - raw that makes no comparison to be easily applicable as a patch: >> http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-raw/ >> >> As explained, I duplicated the complete pipeline (including >> MarlinRasterizer) so both can be used for comparisons. >> To enable the D pipeline, just add -Dprism.marlin.double=true else the >> float pipeline will be used ! >> >> I left the conv.sh script that makes the 90% of the class conversions. >> >> >> It is very preliminary as I doubt we will keep two pipelines (for >> maintenance reasons) and here my test results: >> - DemoFX (stars / sierpinski) / GuiMark performance are so close that I >> can not really see any real difference on my linux with intel 7-4800 ; >> maybe other cpu may have more impact with double vs float but the >> floating-point computations are representing a minor part of the shape >> rendering (dasher, stroker, curve interpolation in Renderer) >> >> Quality: >> - Dasher issue with large shapes: all issues are fixed with marlinFX-D >> (rect, circle) >> - TestNonAARasterization: the errors seem are more important (poly, quad, >> cubic) so there may be either a bug in the test (Path2D comparisons) or an >> important issue in the D pipeline as also polygons are affected >> >> I wanted to present you this work to get your early feedback and mention >> the issues with TestNonAARasterization that will require some work to >> understand clearly what's happening ! >> >> Cheers, >> Laurent >> >> As I wanted to use double precision for long, I ported main marlinFX >>> classes using a tricky sed scripts... fixed the 'D' pipeline and it seems >>> already working well. >>> >>> The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark >>> (webview) seems the same as the hot spot is in scanline processing + >>> coverage / mask processing, not in the dasher or stroker parts. >>> >>> This first prototype is promising and it only took me few hours... >>> >>> However, subdiving large curves is still an interesting option to >>> preserve quality / accuracy even with double precision as mentioned in my >>> previous email. >>> >> From victor.drozdov at oracle.com Thu Dec 1 20:34:40 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Thu, 1 Dec 2016 23:34:40 +0300 Subject: [9] Review request: JDK-8088064: Enhance Launcher to Support Long File Names Message-ID: <4b06bec6-78cf-a2af-62a3-4f4442684153@oracle.com> Chris, Please review the changes about enhancing support of long file names. JIRA: https://bugs.openjdk.java.net/browse/JDK-8088064 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8088064/webrev.00/ --Victor From james.graham at oracle.com Thu Dec 1 20:36:29 2016 From: james.graham at oracle.com (Jim Graham) Date: Thu, 1 Dec 2016 12:36:29 -0800 Subject: Follow-on bugs In-Reply-To: References: <9f01424b-115b-0a0f-5b04-8ecc2b7e56bc@oracle.com> <5a1e508b-b537-6cba-3c01-2f7e303321c8@oracle.com> <3bf52e55-2e49-72db-7f7e-ed8e817b28d0@jugs.org> Message-ID: <2fd1f036-0231-afda-effd-c39d4ca535d9@oracle.com> Before we come to any conclusions on performance, though, we might want to run this on something like a Microsoft Surface that uses a mobile processor (m3 in the low end) that might not perform as well with doubles. Does anyone have a low-end Surface they could try these patches on and see how they affect performance? ...jim On 11/30/16 2:12 PM, Laurent Bourg?s wrote: > Jim, > > As announced yesterday night, I made a new 'Double' (alias D) pipeline for > marlinFX with 2 webrevs: > - cmp that compares the D pipeline vs the float pipeline: > http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-cmp/ > - raw that makes no comparison to be easily applicable as a patch: > http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-raw/ > > As explained, I duplicated the complete pipeline (including > MarlinRasterizer) so both can be used for comparisons. > To enable the D pipeline, just add -Dprism.marlin.double=true else the > float pipeline will be used ! > > I left the conv.sh script that makes the 90% of the class conversions. > > > It is very preliminary as I doubt we will keep two pipelines (for > maintenance reasons) and here my test results: > - DemoFX (stars / sierpinski) / GuiMark performance are so close that I can > not really see any real difference on my linux with intel 7-4800 ; maybe > other cpu may have more impact with double vs float but the floating-point > computations are representing a minor part of the shape rendering (dasher, > stroker, curve interpolation in Renderer) > > Quality: > - Dasher issue with large shapes: all issues are fixed with marlinFX-D > (rect, circle) > - TestNonAARasterization: the errors seem are more important (poly, quad, > cubic) so there may be either a bug in the test (Path2D comparisons) or an > important issue in the D pipeline as also polygons are affected > > I wanted to present you this work to get your early feedback and mention > the issues with TestNonAARasterization that will require some work to > understand clearly what's happening ! > > Cheers, > Laurent > > As I wanted to use double precision for long, I ported main marlinFX >> classes using a tricky sed scripts... fixed the 'D' pipeline and it seems >> already working well. >> >> The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark >> (webview) seems the same as the hot spot is in scanline processing + >> coverage / mask processing, not in the dasher or stroker parts. >> >> This first prototype is promising and it only took me few hours... >> >> However, subdiving large curves is still an interesting option to preserve >> quality / accuracy even with double precision as mentioned in my previous >> email. >> From chris.bensen at oracle.com Fri Dec 2 01:28:37 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 1 Dec 2016 17:28:37 -0800 Subject: [9] Review request: JDK-8170609: Show Error When Mac AppStore Certificate Expired Message-ID: Victor, Please review the changes to show an error when the MacApp Store certificate has expired. JIRA: https://bugs.openjdk.java.net/browse/JDK-8170609 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8170609/webrev.00/ Chris From victor.drozdov at oracle.com Mon Dec 5 18:22:40 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Mon, 5 Dec 2016 21:22:40 +0300 Subject: [9] Review request: JDK-8165794: javapackager throws "No application jars found" when "-srcfiles" is omitted in CLI Message-ID: Chris, Please review the changes about "No application jars found" exception. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165794 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8165794/webrev.00/ --Victor From kevin.rushforth at oracle.com Mon Dec 5 19:41:29 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 05 Dec 2016 11:41:29 -0800 Subject: HEADS-UP: building JavaFX 9-dev with jdk-9+148 and later Message-ID: <5845C2E9.8070906@oracle.com> To: OpenJFX developers who build FX 9-dev The latest batch of jigsaw changes [1] were pushed into jdk9/dev as JDK-8169069 [2] last Thursday, and will be integrated into jdk-9+148 later this week. In order to build FX with this version of the JDK we need to make a change to our module-info.java files to conform to the new syntax for "requires transitive" and for listing multiple service providers. This work is tracked by JDK-8170485 [3]. These changes are not backward compatible, so they will prevent FX 9-dev from compiling on earlier jdk-9 builds. As such we will need to bump the minimum version to 148 at the same time we make these changes. An additional complication is that the latest jigsaw changes also tighten the encapsulation rules such that setAccessible no longer breaks encapsulation without explicit permission [4]. This change affects gradle/groovy such that additional java command-line options are needed in order for gradle to run. The requirement is to set the "_JAVA_OPTIONS" environment variable to include the list of "--add-opens" arguments as specified in JDK-8170485. I will also add a "README-java-options" file with the needed list. I will send out the formal review for JDK-8170485 later today or tomorrow, but if you are interested in seeing the preliminary webrev, the URL is listed in a comment in the JBS issue. If there are no problems, I plan to push the fix for JDK-8170485 into FX 9-dev on Tuesday, Dec 13. At that time you will need to upgrade your boot JDK to jdk-9+148 and set the appropriate _JAVA_OPTIONS as indicated in "README-java-options". -- Kevin [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010249.html [2] https://bugs.openjdk.java.net/browse/JDK-8169069 [3] https://bugs.openjdk.java.net/browse/JDK-8170485 [4] See #AwkwardStrongEncapsulation in [1] From yasuenag at gmail.com Tue Dec 6 03:35:00 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 6 Dec 2016 12:35:00 +0900 Subject: RFR: JDK-8170774: OpenJFX cannot be built on Fedora 25 Message-ID: <932f911d-226b-53e5-e03b-7c76539c4b43@gmail.com> Hi all, I tried to build OpenJFX on Fedora 25 x86_64, but it is failed as below: ------------- :fxpackager:compileLinuxLibrary/home/ysuenaga/OpenJFX/rt/modules/jdk.packager/src/main/native/library/common/PosixPlatform.cpp: In member function 'virtual bool PosixProcess::Wait()': /home/ysuenaga/OpenJFX/rt/modules/jdk.packager/src/main/native/library/common/PosixPlatform.cpp:316:10: error: 'wait' was not declared in this scope wait(); ^ ------------- Fedora 25 x86_64 gcc-6.2.1-2.fc25.x86_64 gcc-c++-6.2.1-2.fc25.x86_64 JDK 9 EA b147 wait(2) should be passed one "int *" argument [1]. I've uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8170774/webrev.00/ I'm not an author of OpenJFX project. So I need a sponsor. Thanks, Yasumasa [1] http://man7.org/linux/man-pages/man2/waitpid.2.html From kevin.rushforth at oracle.com Tue Dec 6 16:10:55 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Dec 2016 08:10:55 -0800 Subject: [9] Review request: JDK-8170485: Switch to building JavaFX with new module-info syntax Message-ID: <5846E30F.5080103@oracle.com> Chien & Dave, Please review the preliminary webrev to allow building JavaFX with jdk-9+148 and later: https://bugs.openjdk.java.net/browse/JDK-8170485 http://cr.openjdk.java.net/~kcr/8170485/webrev.00/ The details are in the JBS issue and also in the "HEADS-UP" message [1] I sent yesterday. As indicated in JBS, I will update the webrev later this week to bump the minimum build to 148 once 148 is promoted and available on java.net. No other changes are anticipated (unless you find anything while reviewing it). -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-December/020014.html From Alan.Bateman at oracle.com Tue Dec 6 21:07:18 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 6 Dec 2016 21:07:18 +0000 Subject: [9] Review request: JDK-8170485: Switch to building JavaFX with new module-info syntax In-Reply-To: <5846E30F.5080103@oracle.com> References: <5846E30F.5080103@oracle.com> Message-ID: On 06/12/2016 16:10, Kevin Rushforth wrote: > Chien & Dave, > > Please review the preliminary webrev to allow building JavaFX with > jdk-9+148 and later: > > https://bugs.openjdk.java.net/browse/JDK-8170485 > http://cr.openjdk.java.net/~kcr/8170485/webrev.00/ > The updates to the module-info.java sources look good. -Alan From mandy.chung at oracle.com Tue Dec 6 22:06:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 6 Dec 2016 14:06:53 -0800 Subject: [9] Review request: JDK-8170485: Switch to building JavaFX with new module-info syntax In-Reply-To: <5846E30F.5080103@oracle.com> References: <5846E30F.5080103@oracle.com> Message-ID: > On Dec 6, 2016, at 8:10 AM, Kevin Rushforth wrote: > > Chien & Dave, > > Please review the preliminary webrev to allow building JavaFX with jdk-9+148 and later: > > https://bugs.openjdk.java.net/browse/JDK-8170485 > http://cr.openjdk.java.net/~kcr/8170485/webrev.00/ > > The details are in the JBS issue and also in the "HEADS-UP" message [1] I sent yesterday. > > As indicated in JBS, I will update the webrev later this week to bump the minimum build to 148 once 148 is promoted and available on java.net. No other changes are anticipated (unless you find anything while reviewing it). Looks good. Mandy From james.graham at oracle.com Wed Dec 7 16:06:27 2016 From: james.graham at oracle.com (Jim Graham) Date: Wed, 7 Dec 2016 08:06:27 -0800 Subject: [9] Review request: JDK-8088857 Menu slow to respond after resizing a window multiple times with animation running Message-ID: <009f4572-4afa-39ed-c930-0c71c613bb02@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8088857 webrev: http://cr.openjdk.java.net/~flar/JDK-8088857/webrev.rt.00/ Fix is as we discussed. I'll investigate applying it to 8u-dev soon... ...jim From victor.drozdov at oracle.com Wed Dec 7 18:07:51 2016 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Wed, 7 Dec 2016 21:07:51 +0300 Subject: [9] Review request: JDK-8170743: jdk9 b147, Java Version Mismatch in ant-javafx.jar Message-ID: <6558b61d-5d89-fa3a-1ffc-905ebc807f97@oracle.com> Chris, Please review the changes about comparing java versions (P1). JIRA: https://bugs.openjdk.java.net/browse/JDK-8170743 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8170743/webrev.00/ --Victor From Rony.Flatscher at wu.ac.at Wed Dec 7 18:06:09 2016 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 7 Dec 2016 19:06:09 +0100 Subject: Hmm, another attempt to get information on deploying javax.script (via FXMLLoader) and SceneBuilder and javax.script languages ... In-Reply-To: <8ff0cbb4-e200-9c8e-54a3-cc045ca8ed36@wu.ac.at> References: <22d47b0c-67f3-361e-1d15-c8c50d1b4c75@wu.ac.at> <8ff0cbb4-e200-9c8e-54a3-cc045ca8ed36@wu.ac.at> Message-ID: On 28.11.2016 14:18, Rony G. Flatscher wrote: > Dalibor, > > thank you very much for this link, just posted a comparable question there. > > Poking around the questions (many unanswered) posted there, my hopes are not very high to get an > answer (maybe I am too pessimistic here)... > > Again, thank you! > > ---rony As feared/anticipated, there have been no real answers on the pointed out Oracle community. Short of any alternatives, I think that this group is probably the most appropriate to discuss javax.script (part of Java!!) implementation issues and ideas with JavaFX. If nothing else, *the* JavaFX developers hang out here! Therefore I will try to post a few little things that would tremendeously improve JavaFX (FXMLoader and WebEngine) for any script engine, though the implementation complexity would be *quite* simple. ---rony > On 28.11.2016 13:43, dalibor topic wrote: >> >> On 28.11.2016 12:55, Rony G. Flatscher wrote: >>> So I am wondering whether there is another mailing group (other than this one) where questions like >>> this can be asked >> There is a JavaFX forum at >> https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later within the Oracle >> Community. >> >> cheers, >> dalibor topic From Rony.Flatscher at wu.ac.at Wed Dec 7 19:04:01 2016 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Wed, 7 Dec 2016 20:04:01 +0100 Subject: RFE/Suggestions to improve JavaFX deployment of javax.script (part of Java) engines and script code Message-ID: <10ddcb41-0c6c-991e-e31a-69e8ac0902c1@wu.ac.at> For scripting languages that possess javax.script (part of Java since Java 1.6/6!) implementations the JavaFX infrastructure is of a great attractivity. JavaFX would allow script programmers for creating platform independent GUIs to take fully advantage for their own purposes, i.e. "surfing on Java" to get at a modern, maintained, up-to-date GUIs in an open manner! Of course, scripting support in form of Nashorn/ECMAScript/Javascript is on board of modern Java distributions, however there are many more javax.script scripting languages available. (In my case I am very interested in ooRexx, the opensource version of IBM's Open Object Rexx, which is a very easy to learn, yet powerful OO language, and am the author of the JSR-223 implementation of ooRexx, which will be included in the next distribution of BSF4ooRexx which is a bridge between ooRexx and Java.) While evaluating the possibilities (for non-informatic students) of taking advantage of the JavaFX infrastructure, I have been experimenting and exploring the JavaFX infrastructure. Being acquainted with the details of javax.script/JSR223 it has been very interesting to learn how javax.script is being deployed on JavaFX. Basically, using SceneBuilder and then manually editing the FXML file it becomes possible to run any scripting programs from (I assume FXMLLoader), given that there is a processing instruction like e.g. or which causes FXMLLoader to load the denoted scripting language by name. As a result all script code, be it defined in fx:script elements with a source attribute pointing to the file containing the script code or any code supplied in attributes like "onAction" will be executed with this denoted scripting engine. This is it. Nothing else is currently available. Not even employing javax.script programming languages in the context of a WebView/WebEngine, although HTML defines a "type" attribute for the "script" element! E.g, it is not possible to employ more than one script language for the same document, although this is plain easy! Or, it is not possible to have script controllers defined (only Java controllers) in SceneBuilder. Or it is not possible to use javafxpackager to create a jar-file with pure javax.script code and JavaFX resources, as there is no support to denote a script to be used as the "main class". --- As this is the JavaFX developer list, I would like to propose in this e-mail very few and (really! :) ) easy to implement enhancements that immediately would increase the usability and the attractiveness of JavaFX for script writers. If there is an official tracker infrastructure where I could post at least the simple enhancements, please advise! --- 1. Suggestion # 1: wherever script code can be denoted, allow a "type" attribute with the mime type value of the javax.script engine to be used to execute the script code. Whenever such a "type" attribute is found, one can load the respective javax.script engine by merely using javafx.script.ScriptManager.getEngineByMimeType(mimeType) and then have it execute the script code. FXML candidates are the fx:script element itself as well as all attributes (like "onAction") that allow to denote script code. But also in HTML 5 (WebView/WebEngine) the script element and its "type" attribute (cf. ). * Examples in FXML-documents: * Example in any fx-elements that have attributes that allow code: