From arapte at openjdk.java.net Mon Jun 1 09:56:41 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 1 Jun 2020 09:56:41 GMT Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version In-Reply-To: References: Message-ID: On Fri, 29 May 2020 01:24:29 GMT, Alexander Matveev wrote: > - Updated libffi to 3.3. modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/include/ffitarget.h line 53: > 52: #define FFI_TARGET_SPECIFIC_STACK_SPACE_ALLOCATION > 53: #ifndef _MSC_VER > 54: #define FFI_TARGET_HAS_COMPLEX_TYPE In the original release of libffi 3.2.1, this line is not commented. which means it was commented in JavaFX. I cannot trace when and why was it commented. Should it be reasoned to whether enable it or not ? ------------- PR: https://git.openjdk.java.net/jfx/pull/242 From jvos at openjdk.java.net Mon Jun 1 12:56:41 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 1 Jun 2020 12:56:41 GMT Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version In-Reply-To: References: Message-ID: <2I-kiph3XqcVk0TDBJc_xe3eez4UPJMF8H20LBwTfRU=.3f6a0bc3-1155-4bcc-89c0-7db8efb728e3@github.com> On Mon, 1 Jun 2020 09:54:23 GMT, Ambarish Rapte wrote: >> - Updated libffi to 3.3. > > modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/include/ffitarget.h line 53: > >> 52: #define FFI_TARGET_SPECIFIC_STACK_SPACE_ALLOCATION >> 53: #ifndef _MSC_VER >> 54: #define FFI_TARGET_HAS_COMPLEX_TYPE > > In the original release of [libffi 3.2.1](https://github.com/libffi/libffi/releases/tag/v3.2.1), this line is not > commented. which means it was commented in JavaFX. I cannot trace when and why was it commented. Should it be reasoned > to whether enable it or not ? That's a good question. The commented line was there from the first commit (in 9, changeset 9231:241f9696e3ad, https://bugs.openjdk.java.net/browse/JDK-8043352) but I don't see a reason on why it was disabled. libffi is also built in the GraalVM project, and that line is not commented there. @sashamatveev or @kevinrushforth do you remember the reason? ------------- PR: https://git.openjdk.java.net/jfx/pull/242 From kcr at openjdk.java.net Mon Jun 1 13:23:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 1 Jun 2020 13:23:23 GMT Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version In-Reply-To: <2I-kiph3XqcVk0TDBJc_xe3eez4UPJMF8H20LBwTfRU=.3f6a0bc3-1155-4bcc-89c0-7db8efb728e3@github.com> References: <2I-kiph3XqcVk0TDBJc_xe3eez4UPJMF8H20LBwTfRU=.3f6a0bc3-1155-4bcc-89c0-7db8efb728e3@github.com> Message-ID: <933szJdHbgQWureselL4BR1MmBP205OJAZ8tTQ13AHE=.c636e87c-57f9-4d18-a7d5-14dce889f453@github.com> On Mon, 1 Jun 2020 12:54:28 GMT, Johan Vos wrote: >> modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/include/ffitarget.h line 53: >> >>> 52: #define FFI_TARGET_SPECIFIC_STACK_SPACE_ALLOCATION >>> 53: #ifndef _MSC_VER >>> 54: #define FFI_TARGET_HAS_COMPLEX_TYPE >> >> In the original release of [libffi 3.2.1](https://github.com/libffi/libffi/releases/tag/v3.2.1), this line is not >> commented. which means it was commented in JavaFX. I cannot trace when and why was it commented. Should it be reasoned >> to whether enable it or not ? > > That's a good question. The commented line was there from the first commit (in 9, changeset 9231:241f9696e3ad, > https://bugs.openjdk.java.net/browse/JDK-8043352) but I don't see a reason on why it was disabled. > libffi is also built in the GraalVM project, and that line is not commented there. > > @sashamatveev or @kevinrushforth do you remember the reason? No, I don't remember. ------------- PR: https://git.openjdk.java.net/jfx/pull/242 From kevin.rushforth at oracle.com Mon Jun 1 13:52:34 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 1 Jun 2020 06:52:34 -0700 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg Message-ID: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> I hereby nominate Jeanette Winzenburg [1] to OpenJFX Committer. Jeanette is an OpenJFX community member, who has contributed 16 changesets [2][3] to OpenJFX. Votes are due by June 15, 2020. Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#fastegal [2] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits [3] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits [4] https://openjdk.java.net/census#openjfx [5] https://openjdk.java.net/bylaws#lazy-consensus [6] https://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Mon Jun 1 13:53:08 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 1 Jun 2020 06:53:08 -0700 Subject: CFV: New OpenJFX Committer: Jose Pereda Message-ID: I hereby nominate Jose Pereda [1] to OpenJFX Committer. Jose is an OpenJFX community member, who has contributed 16 changesets [2][3] to OpenJFX. Votes are due by June 15, 2020. Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#jpereda [2] https://github.com/openjdk/jfx/search?q=author-email%3Ajpereda%40openjdk.org&s=author-date&type=Commits [3] https://github.com/openjdk/jfx/search?q=author-email%3Ajose.pereda%40gluonhq.com&s=author-date&type=Commits [4] https://openjdk.java.net/census#openjfx [5] https://openjdk.java.net/bylaws#lazy-consensus [6] https://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Mon Jun 1 13:53:46 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 1 Jun 2020 06:53:46 -0700 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg In-Reply-To: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> References: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> Message-ID: <1caae222-a0fe-ea4a-44c2-40e9f89e1bc6@oracle.com> Vote: YES -- Kevin On 6/1/2020 6:52 AM, Kevin Rushforth wrote: > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Committer. From kevin.rushforth at oracle.com Mon Jun 1 13:54:08 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 1 Jun 2020 06:54:08 -0700 Subject: CFV: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: <0ebce8ff-6a7d-66db-7732-5e85c6d44e6a@oracle.com> Vote: YES -- Kevin On 6/1/2020 6:53 AM, Kevin Rushforth wrote: > I hereby nominate Jose Pereda [1] to OpenJFX Committer. From philip.race at oracle.com Mon Jun 1 14:10:59 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Jun 2020 07:10:59 -0700 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg In-Reply-To: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> References: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> Message-ID: <5ED50C73.9040504@oracle.com> Vote: yes -phil From johan.vos at gluonhq.com Mon Jun 1 14:08:53 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 1 Jun 2020 16:08:53 +0200 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg In-Reply-To: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> References: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> Message-ID: Vote: YES On Mon, Jun 1, 2020 at 4:00 PM Kevin Rushforth wrote: > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Committer. > > Jeanette is an OpenJFX community member, who has contributed 16 > changesets [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > From philip.race at oracle.com Mon Jun 1 14:11:26 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Jun 2020 07:11:26 -0700 Subject: CFV: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: <5ED50C8E.3000601@oracle.com> Vote: yes -phil From johan.vos at gluonhq.com Mon Jun 1 14:09:05 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 1 Jun 2020 16:09:05 +0200 Subject: CFV: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: Vote: YES On Mon, Jun 1, 2020 at 4:03 PM Kevin Rushforth wrote: > I hereby nominate Jose Pereda [1] to OpenJFX Committer. > > Jose is an OpenJFX community member, who has contributed 16 changesets > [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jpereda > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Ajpereda%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Ajose.pereda%40gluonhq.com&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > From nlisker at gmail.com Mon Jun 1 14:12:00 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 1 Jun 2020 17:12:00 +0300 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg In-Reply-To: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> References: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> Message-ID: Vote: YES - Nir On Mon, Jun 1, 2020 at 4:52 PM Kevin Rushforth wrote: > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Committer. > > Jeanette is an OpenJFX community member, who has contributed 16 > changesets [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > From nlisker at gmail.com Mon Jun 1 14:12:16 2020 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 1 Jun 2020 17:12:16 +0300 Subject: CFV: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: Vote: YES - Nir On Mon, Jun 1, 2020 at 5:09 PM Johan Vos wrote: > Vote: YES > > On Mon, Jun 1, 2020 at 4:03 PM Kevin Rushforth > > wrote: > > > I hereby nominate Jose Pereda [1] to OpenJFX Committer. > > > > Jose is an OpenJFX community member, who has contributed 16 changesets > > [2][3] to OpenJFX. > > > > Votes are due by June 15, 2020. > > > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project > > Committer is described in [6]. > > > > Thanks. > > > > -- Kevin > > > > > > [1] https://openjdk.java.net/census#jpereda > > > > [2] > > > > > https://github.com/openjdk/jfx/search?q=author-email%3Ajpereda%40openjdk.org&s=author-date&type=Commits > > > > [3] > > > > > https://github.com/openjdk/jfx/search?q=author-email%3Ajose.pereda%40gluonhq.com&s=author-date&type=Commits > > > > [4] https://openjdk.java.net/census#openjfx > > > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > > > [6] https://openjdk.java.net/projects#project-committer > > > > > From github.com+4208131+bhaweshkc at openjdk.java.net Mon Jun 1 15:37:09 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 1 Jun 2020 15:37:09 GMT Subject: [Rev 01] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: <7Z4jiN5_z3SGrGWAqxqMmmIO2EHmzLg6on3gspsjwtA=.6ec5d087-518a-410f-8810-e1450f2a6e5c@github.com> > Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, > which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing > pages otherwise print all pages as usual. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: added manual test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/222/files - new: https://git.openjdk.java.net/jfx/pull/222/files/39748929..75a0362f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/222/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/222/webrev.00-01 Stats: 153 lines in 1 file changed: 153 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/222/head:pull/222 PR: https://git.openjdk.java.net/jfx/pull/222 From mpaus at openjdk.java.net Mon Jun 1 17:59:09 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Mon, 1 Jun 2020 17:59:09 GMT Subject: RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux Message-ID: It seems to be sufficient to add "intel" as an additional vendor to the list in the X11GLFactory class. Tests pass and my own application also works with the new build. ------------- Commit messages: - Fix JDK-8246204 Changes: https://git.openjdk.java.net/jfx/pull/243/files Webrev: https://webrevs.openjdk.java.net/jfx/243/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246204 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/243.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/243/head:pull/243 PR: https://git.openjdk.java.net/jfx/pull/243 From mpaus at openjdk.java.net Mon Jun 1 17:59:58 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Mon, 1 Jun 2020 17:59:58 GMT Subject: RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux In-Reply-To: References: Message-ID: On Mon, 1 Jun 2020 17:52:46 GMT, Michael Paus wrote: > It seems to be sufficient to add "intel" as an additional vendor to the list in the X11GLFactory class. Tests pass and > my own application also works with the new build. Here is the crosslink to the JBS issue: https://bugs.openjdk.java.net/browse/JDK-8246204 ------------- PR: https://git.openjdk.java.net/jfx/pull/243 From almatvee at openjdk.java.net Mon Jun 1 20:55:13 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 1 Jun 2020 20:55:13 GMT Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version In-Reply-To: <933szJdHbgQWureselL4BR1MmBP205OJAZ8tTQ13AHE=.c636e87c-57f9-4d18-a7d5-14dce889f453@github.com> References: <2I-kiph3XqcVk0TDBJc_xe3eez4UPJMF8H20LBwTfRU=.3f6a0bc3-1155-4bcc-89c0-7db8efb728e3@github.com> <933szJdHbgQWureselL4BR1MmBP205OJAZ8tTQ13AHE=.c636e87c-57f9-4d18-a7d5-14dce889f453@github.com> Message-ID: <31aU43lgDzVgtpKbp09wY1f3l9xiKeE7KTXYk-81wNU=.9d73060e-4ac1-45a5-942e-255c85e1a16f@github.com> On Mon, 1 Jun 2020 13:21:08 GMT, Kevin Rushforth wrote: >> That's a good question. The commented line was there from the first commit (in 9, changeset 9231:241f9696e3ad, >> https://bugs.openjdk.java.net/browse/JDK-8043352) but I don't see a reason on why it was disabled. >> libffi is also built in the GraalVM project, and that line is not commented there. >> >> @sashamatveev or @kevinrushforth do you remember the reason? > > No, I don't remember. No, I don't remember as well. ------------- PR: https://git.openjdk.java.net/jfx/pull/242 From ajit.ghaisas at oracle.com Tue Jun 2 04:33:59 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 2 Jun 2020 10:03:59 +0530 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg In-Reply-To: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> References: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> Message-ID: <5AD158A8-CDE3-404B-9472-5F44FB03EE24@oracle.com> Vote: YES Regards, Ajit > On 01-Jun-2020, at 7:22 PM, Kevin Rushforth wrote: > > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Committer. > > Jeanette is an OpenJFX community member, who has contributed 16 changesets [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > From ajit.ghaisas at oracle.com Tue Jun 2 04:35:07 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 2 Jun 2020 10:05:07 +0530 Subject: CFV: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: <831DA3E8-8E53-4B8B-B600-1E0A27D2D174@oracle.com> Vote: YES Regards, Ajit > On 01-Jun-2020, at 7:23 PM, Kevin Rushforth wrote: > > I hereby nominate Jose Pereda [1] to OpenJFX Committer. > > Jose is an OpenJFX community member, who has contributed 16 changesets [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jpereda > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Ajpereda%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Ajose.pereda%40gluonhq.com&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > From ambarish.rapte at oracle.com Tue Jun 2 05:14:51 2020 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 1 Jun 2020 22:14:51 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: Vote: Yes Regards, Ambarish From ambarish.rapte at oracle.com Tue Jun 2 05:15:26 2020 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 1 Jun 2020 22:15:26 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg In-Reply-To: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> References: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> Message-ID: <9997c3a7-9ff5-4f68-a2cd-280e3ec1db09@default> Vote: YES Regards, Ambarish From arapte at openjdk.java.net Tue Jun 2 05:21:01 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 2 Jun 2020 05:21:01 GMT Subject: [Rev 01] RFR: 8242523: Update the animation and clip envelope classes In-Reply-To: References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com> Message-ID: On Thu, 28 May 2020 16:44:33 GMT, Nir Lisker wrote: >> Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging >> of methods. Summery of changes: >> ### Animation >> * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks. >> * Added `isStopped`, `isRunning` and `isPaused` convenience methods. >> * Added `runHandler` method to deal with running the handler. >> * Moved methods to be grouped closer to where they are used rather than by visibility. >> * Removed the static import for `TickCalculation`. >> * Various small subjective readability changes. >> * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily >> initializing the `cuePoints` map. >> >> ### Clip Envelopes >> * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes. >> * Rearranged methods order to be consistent. >> * Replaced the `checkBounds` method with a new overload of `Utils.clamp`. >> * Renamed `pos` to `cyclePos`. >> * Extracted common methods: `changedDirection` and `ticksRateChange` >> * Added internal documentation. >> >> Also corrected a typo in `TicksCalculation` and added an explanation for an animation test. > > Nir Lisker has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 10 commits: > - Merge branch 'master' into 8242523_Update_the_Animation_and_ClipEnvelope_classes > - Synch whitespace fix > - Addressed review comments > - Removing cycleNumber for now > - Fix typo in TicksCalculation & add an explanation for an animation test > - Initial push of 8242523 > - Comment out erroneous test > - Fix IndefiniteCycleDuration test > - Fixed single loop test > - Initial commit Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/196 From jonathan at jonathangiles.net Tue Jun 2 05:27:11 2020 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Tue, 2 Jun 2020 17:27:11 +1200 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg In-Reply-To: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> References: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> Message-ID: Vote: YES -- Jonathan (Tapped on a touch device) On Tue, 2 Jun 2020, 1:53 am Kevin Rushforth, wrote: > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Committer. > > Jeanette is an OpenJFX community member, who has contributed 16 > changesets [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > From jonathan at jonathangiles.net Tue Jun 2 05:27:26 2020 From: jonathan at jonathangiles.net (Jonathan Giles) Date: Tue, 2 Jun 2020 17:27:26 +1200 Subject: CFV: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: Vote: YES -- Jonathan (Tapped on a touch device) On Tue, 2 Jun 2020, 1:53 am Kevin Rushforth, wrote: > I hereby nominate Jose Pereda [1] to OpenJFX Committer. > > Jose is an OpenJFX community member, who has contributed 16 changesets > [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jpereda > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Ajpereda%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Ajose.pereda%40gluonhq.com&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > From arapte at openjdk.java.net Tue Jun 2 06:12:57 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 2 Jun 2020 06:12:57 GMT Subject: [Rev 01] RFR: 8245282: Button/Combo Behavior: memory leak on dispose In-Reply-To: References: Message-ID: <3rpxkx_AGBBY9OOmTGHYs4kt2_dUR3xRM1ezfp1O1uk=.c26d17b8-ac2a-4211-895c-c246b85315ce@github.com> On Wed, 27 May 2020 10:26:25 GMT, Jeanette Winzenburg wrote: >> Reason for the memory leak is a listener on control's focusProperty that is not correctly removed on dispose. For >> details please see the report. >> Added a test method to ButtonSkinTest that failed before and passes after the fix. > > Jeanette Winzenburg has updated the pull request with a new target base due to a merge or a rebase. The pull request > now contains one commit: > 8245282: Button/Combo Behavior: memory leak on dispose Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/226 From nlisker at openjdk.java.net Tue Jun 2 06:43:32 2020 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 2 Jun 2020 06:43:32 GMT Subject: [Integrated] RFR: 8242523: Update the animation and clip envelope classes In-Reply-To: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com> References: <4-UJH2xS2-LQWU5BL0ZJvM01ATf9Rg-ElPVuW0T8PEo=.c776cf15-34b1-4067-88d3-6e45b7e784f4@github.com> Message-ID: <9jT7hlcORkmxCFZLnj0wo_PwXwXGck6yMX8FlreXIg0=.7a8a632e-4572-4594-9b07-2969ce7f6e6d@github.com> On Fri, 24 Apr 2020 00:58:30 GMT, Nir Lisker wrote: > Mostly refactoring in preparation of the upcoming fixes. The changes might look like a lot, but it's mostly rearranging > of methods. Summery of changes: > ### Animation > * Added `isNearZero` and `areNearEqual` methods that deal with `EPSILON` checks. > * Added `isStopped`, `isRunning` and `isPaused` convenience methods. > * Added `runHandler` method to deal with running the handler. > * Moved methods to be grouped closer to where they are used rather than by visibility. > * Removed the static import for `TickCalculation`. > * Various small subjective readability changes. > * Behavioral changes: switching `autoReverse` and `onFinished` properties from "Simple" to "Base" properties; and lazily > initializing the `cuePoints` map. > > ### Clip Envelopes > * Added `MultiLoopClipEnvelope` as an intermediate parent for infinite and finite clip envelopes. > * Rearranged methods order to be consistent. > * Replaced the `checkBounds` method with a new overload of `Utils.clamp`. > * Renamed `pos` to `cyclePos`. > * Extracted common methods: `changedDirection` and `ticksRateChange` > * Added internal documentation. > > Also corrected a typo in `TicksCalculation` and added an explanation for an animation test. This pull request has now been integrated. Changeset: a78b3fb5 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/a78b3fb5 Stats: 662 lines in 9 files changed: 182 ins; 346 del; 134 mod 8242523: Update the animation and clip envelope classes Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/196 From jvos at openjdk.java.net Tue Jun 2 11:24:39 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 2 Jun 2020 11:24:39 GMT Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version In-Reply-To: References: Message-ID: On Fri, 29 May 2020 01:24:29 GMT, Alexander Matveev wrote: > - Updated libffi to 3.3. I tested this and couldn't find issues. The uncommented line worries me a bit, though, but I can't see a reason why it should be commented again. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/242 From kcr at openjdk.java.net Tue Jun 2 12:35:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Jun 2020 12:35:33 GMT Subject: RFR: 8239095: Upgrade libFFI to the latest 3.3 version In-Reply-To: References: Message-ID: On Fri, 29 May 2020 01:24:29 GMT, Alexander Matveev wrote: > - Updated libffi to 3.3. Looks good to me. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/242 From David.Grieve at microsoft.com Tue Jun 2 13:07:56 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Tue, 2 Jun 2020 13:07:56 +0000 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg Message-ID: Vote: YES From David.Grieve at microsoft.com Tue Jun 2 13:08:43 2020 From: David.Grieve at microsoft.com (David Grieve) Date: Tue, 2 Jun 2020 13:08:43 +0000 Subject: CFV: New OpenJFX Committer: Jose Pereda Message-ID: Vote: YES From fastegal at openjdk.java.net Tue Jun 2 14:23:59 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 2 Jun 2020 14:23:59 GMT Subject: [Integrated] RFR: 8245282: Button/Combo Behavior: memory leak on dispose In-Reply-To: References: Message-ID: <_-z2ZjbjNhy8FKGunAWmHsZeCY4JgZzd2wbj5F9M48Y=.e7721f5a-da05-433f-91e0-9b7cd9fc85ae@github.com> On Wed, 20 May 2020 11:15:34 GMT, Jeanette Winzenburg wrote: > Reason for the memory leak is a listener on control's focusProperty that is not correctly removed on dispose. For > details please see the report. > Added a test method to ButtonSkinTest that failed before and passes after the fix. This pull request has now been integrated. Changeset: 853ac78a Author: Jeanette Winzenburg Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/853ac78a Stats: 45 lines in 3 files changed: 33 ins; 8 del; 4 mod 8245282: Button/Combo Behavior: memory leak on dispose Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/226 From arun.aj.joseph at oracle.com Tue Jun 2 15:39:31 2020 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Tue, 2 Jun 2020 21:09:31 +0530 Subject: CFV: New OpenJFX Committer: Jeanette Winzenburg In-Reply-To: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> References: <04e8df26-5177-9f0d-c18f-15bc03427450@oracle.com> Message-ID: <687509E5-3594-4D8A-A4C6-A30D3E420EB0@oracle.com> Vote: YES ? Arun Joseph > On 01-Jun-2020, at 7:22 PM, Kevin Rushforth wrote: > > I hereby nominate Jeanette Winzenburg [1] to OpenJFX Committer. > > Jeanette is an OpenJFX community member, who has contributed 16 changesets [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#fastegal > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Afastegal%40swingempire.de&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > From arun.aj.joseph at oracle.com Tue Jun 2 15:40:23 2020 From: arun.aj.joseph at oracle.com (Arun Joseph) Date: Tue, 2 Jun 2020 21:10:23 +0530 Subject: CFV: New OpenJFX Committer: Jose Pereda In-Reply-To: References: Message-ID: <77564305-F213-434D-9314-564462933302@oracle.com> Vote: YES ? Arun Joseph > On 01-Jun-2020, at 7:23 PM, Kevin Rushforth wrote: > > I hereby nominate Jose Pereda [1] to OpenJFX Committer. > > Jose is an OpenJFX community member, who has contributed 16 changesets [2][3] to OpenJFX. > > Votes are due by June 15, 2020. > > Only current OpenJFX Committers [4] 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 [5]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#jpereda > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Ajpereda%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Ajose.pereda%40gluonhq.com&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > From arapte at openjdk.java.net Tue Jun 2 17:08:20 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 2 Jun 2020 17:08:20 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting Message-ID: Issue: In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using `setAll()`). Cause: 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. 2. The indices from these TreeModificationEvents are not reliable. 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues combine in wrong update of the selection. Fix: 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` Verification: The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the change should not cause any other failures. Added unit tests which fail before and pass after the fix. ------------- Commit messages: - 8185635: TreeTableView selection changes on sorting Changes: https://git.openjdk.java.net/jfx/pull/244/files Webrev: https://webrevs.openjdk.java.net/jfx/244/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193800 Stats: 210 lines in 3 files changed: 123 ins; 32 del; 55 mod Patch: https://git.openjdk.java.net/jfx/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/244/head:pull/244 PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Tue Jun 2 17:26:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Jun 2020 17:26:21 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: On Tue, 2 Jun 2020 17:00:28 GMT, Ambarish Rapte wrote: > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. @aghaisas can you also review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Tue Jun 2 17:33:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Jun 2020 17:33:58 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: On Tue, 2 Jun 2020 17:00:28 GMT, Ambarish Rapte wrote: > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1808: > 1807: boolean sortingInProgress; > 1808: protected boolean isSortingInProgress() { > 1809: return sortingInProgress; This is an implementation detail. By making it `protected` it becomes public API. You will need to make it package-scope instead ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From jvos at openjdk.java.net Tue Jun 2 17:59:59 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 2 Jun 2020 17:59:59 GMT Subject: RFR: 8246357: Allow static build of webkit library on linux Message-ID: add changes to build a static version of libjfxwebkit.a Fox for JDK-8246357 ------------- Commit messages: - add changes to build a static version of libjfxwebkit.a Changes: https://git.openjdk.java.net/jfx/pull/245/files Webrev: https://webrevs.openjdk.java.net/jfx/245/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246357 Stats: 20 lines in 4 files changed: 17 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/245.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/245/head:pull/245 PR: https://git.openjdk.java.net/jfx/pull/245 From arapte at openjdk.java.net Tue Jun 2 18:02:50 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 2 Jun 2020 18:02:50 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Change isSortingInProgress to package scope ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/244/files - new: https://git.openjdk.java.net/jfx/pull/244/files/d6376dfc..44052f35 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/244/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/244/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/244/head:pull/244 PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Tue Jun 2 18:03:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Jun 2020 18:03:47 GMT Subject: RFR: 8246357: Allow static build of webkit library on linux In-Reply-To: References: Message-ID: On Tue, 2 Jun 2020 17:52:37 GMT, Johan Vos wrote: > add changes to build a static version of libjfxwebkit.a > Fox for JDK-8246357 @arun-Joseph @guruhb can one of you also review? ------------- PR: https://git.openjdk.java.net/jfx/pull/245 From kcr at openjdk.java.net Tue Jun 2 21:10:39 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Jun 2020 21:10:39 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> On Tue, 2 Jun 2020 18:02:50 GMT, Ambarish Rapte wrote: >> Issue: >> In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not >> retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using >> `setAll()`). Cause: >> >> 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. >> 2. The indices from these TreeModificationEvents are not reliable. >> 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor >> results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of >> sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the >> selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or >> collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues >> combine in wrong update of the selection. Fix: >> >> 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the >> TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is >> almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change >> events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as >> before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change >> events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` >> Verification: >> The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the >> change should not cause any other failures. Added unit tests which fail before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Change isSortingInProgress to package scope The algorithm looks correct to me for sorting. How much regression testing have you done for cases where rows or columns are inserted? I left a few comments, and will complete my testing in parallel. modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1822: > 1821: public void sort() { > 1822: sortingInProgress = true; > 1823: final ObservableList> sortOrder = getSortOrder(); I presume that sorting cannot be called recursively? modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1807: > 1806: > 1807: boolean sortingInProgress; > 1808: boolean isSortingInProgress() { Minor: the field itself can be private. modules/javafx.controls/src/main/java/javafx/scene/control/TreeTablePosition.java line 82: > 81: // This causes issue by triggering a new TreeModificationEvent while one TreeModificationEvent > 82: // is being handled currently. > 83: // This is kind of a copy constructor with different value for row. The first three lines of added comments don't really belong here. I would just document the new constructor as a copy-like constructor (with a different row) and mention that it is used by the TreeTableView::sort method. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From almatvee at openjdk.java.net Tue Jun 2 21:57:57 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 2 Jun 2020 21:57:57 GMT Subject: [Integrated] RFR: 8239095: Upgrade libFFI to the latest 3.3 version In-Reply-To: References: Message-ID: On Fri, 29 May 2020 01:24:29 GMT, Alexander Matveev wrote: > - Updated libffi to 3.3. This pull request has now been integrated. Changeset: 6bd0e22d Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/6bd0e22d Stats: 10217 lines in 37 files changed: 4167 ins; 5498 del; 552 mod 8239095: Upgrade libFFI to the latest 3.3 version Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/242 From arapte at openjdk.java.net Wed Jun 3 04:57:19 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 3 Jun 2020 04:57:19 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Tue, 2 Jun 2020 21:00:27 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Change isSortingInProgress to package scope > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1822: > >> 1821: public void sort() { >> 1822: sortingInProgress = true; >> 1823: final ObservableList> sortOrder = getSortOrder(); > > I presume that sorting cannot be called recursively? The `sort()` is called only once for a `TreeTableView`. This method does not perform the actual sorting but it is performed by the sort policy(`DEFAULT_SORT_POLICY`). `DEFAULT_SORT_POLICY` initiates the sorting by calling `rootItem.sort()`, which results in call to `TreeItem.doSort()`. `TreeItem.doSort()` makes the final call to sort the children list, this method gets executed once for the root TreeItem and then for each expanded child TreeItem. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 3 05:21:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 3 Jun 2020 05:21:09 GMT Subject: [Rev 02] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: kcr review comment changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/244/files - new: https://git.openjdk.java.net/jfx/pull/244/files/44052f35..1561d2db Webrevs: - full: https://webrevs.openjdk.java.net/jfx/244/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/244/webrev.01-02 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/244/head:pull/244 PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 3 05:21:10 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 3 Jun 2020 05:21:10 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Tue, 2 Jun 2020 21:01:05 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Change isSortingInProgress to package scope > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1807: > >> 1806: >> 1807: boolean sortingInProgress; >> 1808: boolean isSortingInProgress() { > > Minor: the field itself can be private. Corrected in the next commit. > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTablePosition.java line 82: > >> 81: // This causes issue by triggering a new TreeModificationEvent while one TreeModificationEvent >> 82: // is being handled currently. >> 83: // This is kind of a copy constructor with different value for row. > > The first three lines of added comments don't really belong here. I would just document the new constructor as a > copy-like constructor (with a different row) and mention that it is used by the TreeTableView::sort method. Updated the doc in next commit, please take a look ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 3 05:21:23 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 3 Jun 2020 05:21:23 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Tue, 2 Jun 2020 21:08:27 GMT, Kevin Rushforth wrote: > The algorithm looks correct to me for sorting. How much regression testing have you done for cases where rows or > columns are inserted? I have tested with a small TreeTableView of 15 rows of 3 levels and 3 columns. Would it be enough to test with TreeTableView of ~500 rows of 5 levels, 10 columns ? ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 3 09:40:53 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 3 Jun 2020 09:40:53 GMT Subject: [Rev 02] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: <4-ncKpqge7uTUvJgfCv0QtfdBsGmhNXmnQILS7YSkr0=.ec7de5f0-b985-427f-b1a6-a186824819a9@github.com> On Tue, 2 Jun 2020 17:31:52 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> kcr review comment changes > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1808: > >> 1807: boolean sortingInProgress; >> 1808: protected boolean isSortingInProgress() { >> 1809: return sortingInProgress; > > This is an implementation detail. By making it `protected` it becomes public API. You will need to make it > package-scope instead Updated in next commit ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From fastegal at openjdk.java.net Wed Jun 3 12:05:55 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 3 Jun 2020 12:05:55 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Wed, 3 Jun 2020 05:15:34 GMT, Ambarish Rapte wrote: >> The algorithm looks correct to me for sorting. How much regression testing have you done for cases where rows or >> columns are inserted? >> I left a few comments, and will complete my testing in parallel. > >> The algorithm looks correct to me for sorting. How much regression testing have you done for cases where rows or >> columns are inserted? > > I have tested with a small TreeTableView of 15 rows of 3 levels and 3 columns. > Would it be enough to test with TreeTableView of ~500 rows of 5 levels, 10 columns ? > > Update: I am testing with 7 level of nested rows, with 10, 9, 7, 6, 5, 4, 3 number of children in each level > respectively. The fix works fine till level 3. But can observe issue with level 4 and further. Shall debug this more > and update. hmm .. TreeModificationEvent seems to have a different interpretation (than a list change) of _permutated_: its wasPermutated may return true even on a replace - that's why some tests are throwing a IllegalStateException before the fix. The other way round: do we really want to introduce a singularity in selection handling after replace? The other selectionModels for virtualized controls try to keep the selectedItem/Index only. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From fastegal at openjdk.java.net Wed Jun 3 12:20:44 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 3 Jun 2020 12:20:44 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Wed, 3 Jun 2020 12:03:43 GMT, Jeanette Winzenburg wrote: >>> The algorithm looks correct to me for sorting. How much regression testing have you done for cases where rows or >>> columns are inserted? >> >> I have tested with a small TreeTableView of 15 rows of 3 levels and 3 columns. >> Would it be enough to test with TreeTableView of ~500 rows of 5 levels, 10 columns ? >> >> Update: I am testing with 7 level of nested rows, with 10, 9, 7, 6, 5, 4, 3 number of children in each level >> respectively. The fix works fine till level 3. But can observe issue with level 4 and further. Shall debug this more >> and update. > > hmm .. TreeModificationEvent seems to have a different interpretation (than a list change) of _permutated_: its > wasPermutated may return true even on a replace - that's why some tests are throwing a IllegalStateException before the > fix. The other way round: do we really want to introduce a singularity in selection handling after replace? The other > selectionModels for virtualized controls try to keep the selectedItem/Index only. ahh .. was wrong (note to self: run examples for all controls before commenting ;) - TableView also tries to keep all selected state on replace with the same items in changed sequence, ListView doesn't (which then is the singularity which might need a fix?). ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From fastegal at openjdk.java.net Wed Jun 3 13:01:44 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 3 Jun 2020 13:01:44 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Wed, 3 Jun 2020 12:03:43 GMT, Jeanette Winzenburg wrote: >>> The algorithm looks correct to me for sorting. How much regression testing have you done for cases where rows or >>> columns are inserted? >> >> I have tested with a small TreeTableView of 15 rows of 3 levels and 3 columns. >> Would it be enough to test with TreeTableView of ~500 rows of 5 levels, 10 columns ? >> >> Update: I am testing with 7 level of nested rows, with 10, 9, 7, 6, 5, 4, 3 number of children in each level >> respectively. The fix works fine till level 3. But can observe issue with level 4 and further. Shall debug this more >> and update. > > hmm .. TreeModificationEvent seems to have a different interpretation (than a list change) of _permutated_: its > wasPermutated may return true even on a replace - that's probably why some tests are throwing a IllegalStateException > before the fix. The other way round: do we really want to introduce a singularity in selection handling after > replace? The other selectionModels for virtualized controls try to keep the selectedItem/Index only. need a break ;) Will come back later with an example comparing the behavior of multiple selection state across virtualized controls - preliminary results Sort: - ListView/TableView keep selection (corrrectly) on all selectedItems, adjust indices as needed - TreeView: ?? - TreeTableView: throws IllegalState before this fix, keeps selection (correctly) on all selectedItems, adjusts indices as needed after this fix Replace with same items in different sequence - ListView/TableView: keep only selectedItem, adjust selectedIndex as needed - TreeView: keeps selectedIndices (?) - TreeTableView: throws IllegalState before this fix, keeps selectedItems, adjusts selectedIndices as needed after this fix ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kevin.rushforth at oracle.com Wed Jun 3 13:28:41 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 3 Jun 2020 06:28:41 -0700 Subject: CFV: New OpenJFX Reviewer: Nir Lisker Message-ID: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> I hereby nominate Nir Lisker [1] to OpenJFX Reviewer. Nir is an OpenJFX community member, who has contributed 29 changesets [2][3] to OpenJFX over the course of the past 2 years. Nir consistently participates in code reviews of various OpenJFX pull requests, and has become proficient in the areas of: scene graph, animation, graphics, and bindings. Votes are due by June 17, 2020. Only current OpenJFX Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [5]. Nomination to a project Reviewer is described in [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#nlisker [2] https://github.com/openjdk/jfx/search?q=author-email%3Anlisker%40openjdk.org&s=author-date&type=Commits [3] https://github.com/openjdk/jfx/search?q=author-email%3Anlisker%40gmail.com&s=author-date&type=Commits [4] https://openjdk.java.net/census#openjfx [5] https://openjdk.java.net/bylaws#three-vote-consensus [6] https://openjdk.java.net/projects#project-reviewer From kevin.rushforth at oracle.com Wed Jun 3 13:30:30 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 3 Jun 2020 06:30:30 -0700 Subject: CFV: New OpenJFX Reviewer: Nir Lisker In-Reply-To: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> References: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> Message-ID: <942785cd-afe0-b8bb-eb2c-e83ede573f45@oracle.com> Vote: YES On 6/3/2020 6:28 AM, Kevin Rushforth wrote: > I hereby nominate Nir Lisker [1] to OpenJFX Reviewer. From johan at lodgon.com Wed Jun 3 13:31:36 2020 From: johan at lodgon.com (Johan Vos) Date: Wed, 3 Jun 2020 15:31:36 +0200 Subject: CFV: New OpenJFX Reviewer: Nir Lisker In-Reply-To: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> References: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> Message-ID: Vote: YES - Johan Op wo 3 jun. 2020 om 15:30 schreef Kevin Rushforth < kevin.rushforth at oracle.com>: > I hereby nominate Nir Lisker [1] to OpenJFX Reviewer. > > Nir is an OpenJFX community member, who has contributed 29 changesets > [2][3] to OpenJFX over the course of the past 2 years. Nir consistently > participates in code reviews of various OpenJFX pull requests, and has > become proficient in the areas of: scene graph, animation, graphics, and > bindings. > > Votes are due by June 17, 2020. > > Only current OpenJFX Reviewers [4] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [5]. Nomination to a > project Reviewer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#nlisker > > [2] > > https://github.com/openjdk/jfx/search?q=author-email%3Anlisker%40openjdk.org&s=author-date&type=Commits > > [3] > > https://github.com/openjdk/jfx/search?q=author-email%3Anlisker%40gmail.com&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#three-vote-consensus > > [6] https://openjdk.java.net/projects#project-reviewer > > > > From kcr at openjdk.java.net Wed Jun 3 13:38:57 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Jun 2020 13:38:57 GMT Subject: RFR: 8246357: Allow static build of webkit library on linux In-Reply-To: References: Message-ID: On Tue, 2 Jun 2020 18:01:40 GMT, Kevin Rushforth wrote: >> add changes to build a static version of libjfxwebkit.a >> Fox for JDK-8246357 > > @arun-Joseph @guruhb can one of you also review? The diffs look good. I'm doing test builds now. ------------- PR: https://git.openjdk.java.net/jfx/pull/245 From kcr at openjdk.java.net Wed Jun 3 13:47:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Jun 2020 13:47:26 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Wed, 3 Jun 2020 05:15:34 GMT, Ambarish Rapte wrote: > I have tested with a small TreeTableView of 15 rows of 3 levels and 3 columns. > Would it be enough to test with TreeTableView of ~500 rows of 5 levels, 10 columns ? > > Update: I am testing with 7 level of nested rows, with 10, 9, 7, 6, 5, 4, 3 number of children in each level > respectively. The fix works fine till level 3. But can observe issue with level 4 and further. Shall debug this more > and update. OK, thanks. In addition to making sure that insertion, deletion, and sorting work, are you also checking that the events being sent are as expected? ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From philip.race at oracle.com Wed Jun 3 14:12:26 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 03 Jun 2020 07:12:26 -0700 Subject: CFV: New OpenJFX Reviewer: Nir Lisker In-Reply-To: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> References: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> Message-ID: <5ED7AFCA.1070607@oracle.com> Vote: yes. -phil. From kcr at openjdk.java.net Wed Jun 3 16:36:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Jun 2020 16:36:38 GMT Subject: RFR: 8246357: Allow static build of webkit library on linux In-Reply-To: References: Message-ID: <2zB2bUmPBiXhAbuIjEZHeMJKs6mF0wJ3ejvaiPMcDUs=.65ecaf55-e5d4-4f72-bb31-3a42c780b0cf@github.com> On Tue, 2 Jun 2020 17:52:37 GMT, Johan Vos wrote: > add changes to build a static version of libjfxwebkit.a > Fox for JDK-8246357 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/245 From kcr at openjdk.java.net Wed Jun 3 17:13:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Jun 2020 17:13:42 GMT Subject: RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux In-Reply-To: References: Message-ID: On Mon, 1 Jun 2020 17:52:46 GMT, Michael Paus wrote: > It seems to be sufficient to add "intel" as an additional vendor to the list in the X11GLFactory class. Tests pass and > my own application also works with the new build. modules/javafx.graphics/src/main/java/com/sun/prism/es2/X11GLFactory.java line 46: > 45: new GLGPUInfo("intel open source technology center", null), > 46: new GLGPUInfo("intel", null), > 47: new GLGPUInfo("nvidia", null), Since the qualification check is `vendor.startsWith(gi.vendor)` you can replace the previous `"intel open source technology center"` entry with the new one. ------------- PR: https://git.openjdk.java.net/jfx/pull/243 From ajoseph at openjdk.java.net Wed Jun 3 19:30:05 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Wed, 3 Jun 2020 19:30:05 GMT Subject: RFR: 8246357: Allow static build of webkit library on linux In-Reply-To: References: Message-ID: On Tue, 2 Jun 2020 17:52:37 GMT, Johan Vos wrote: > add changes to build a static version of libjfxwebkit.a > Fox for JDK-8246357 Changes looks good to me. ------------- Marked as reviewed by ajoseph (Committer). PR: https://git.openjdk.java.net/jfx/pull/245 From ambarish.rapte at oracle.com Thu Jun 4 07:58:54 2020 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 4 Jun 2020 00:58:54 -0700 (PDT) Subject: CFV: New OpenJFX Reviewer: Nir Lisker In-Reply-To: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> References: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> Message-ID: <2dfa3ab2-ce59-4963-8b73-970dbcf0eb89@default> Vote: YES Regards, Ambarish From fastegal at openjdk.java.net Thu Jun 4 08:40:25 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 4 Jun 2020 08:40:25 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Wed, 3 Jun 2020 13:45:12 GMT, Kevin Rushforth wrote: >>> The algorithm looks correct to me for sorting. How much regression testing have you done for cases where rows or >>> columns are inserted? >> >> I have tested with a small TreeTableView of 15 rows of 3 levels and 3 columns. >> Would it be enough to test with TreeTableView of ~500 rows of 5 levels, 10 columns ? >> >> Update: I am testing with 7 level of nested rows, with 10, 9, 7, 6, 5, 4, 3 number of children in each level >> respectively. The fix works fine till level 3. But can observe issue with level 4 and further. Shall debug this more >> and update. > >> I have tested with a small TreeTableView of 15 rows of 3 levels and 3 columns. >> Would it be enough to test with TreeTableView of ~500 rows of 5 levels, 10 columns ? >> >> Update: I am testing with 7 level of nested rows, with 10, 9, 7, 6, 5, 4, 3 number of children in each level >> respectively. The fix works fine till level 3. But can observe issue with level 4 and further. Shall debug this more >> and update. > > OK, thanks. In addition to making sure that insertion, deletion, and sorting work, are you also checking that the > events being sent are as expected? Unrelated to this fix I see two pain points (which were not introduced here :) #### A. replaced vs. permutated These are types of change as decided by the list (aka: model) - treeModificationEvent (aka: view) must follow the lead (vs. spreading its own interpretation). Doing so is a bug, IMO. #### B. treeTableView.sort changing internals of the selectionModel that's a no-no-no-go, always. Instead let the selectionModel handle the permutated state correctly (didn't dig why it was deemed necessary to do so in sort - though it has the side-effect of leaving out selectionModels that are not of the expected type) ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From mpaus at openjdk.java.net Thu Jun 4 08:46:09 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Thu, 4 Jun 2020 08:46:09 GMT Subject: [Rev 01] RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux In-Reply-To: References: Message-ID: > It seems to be sufficient to add "intel" as an additional vendor to the list in the X11GLFactory class. Tests pass and > my own application also works with the new build. Michael Paus has updated the pull request incrementally with one additional commit since the last revision: Remove duplicate GLGPUInfo according to review comment My original intention was to keep two entries in order to make it clearer that there are currently two distinct vendor strings for Intel floating around. But having just one entry which covers both cases is ok for me too. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/243/files - new: https://git.openjdk.java.net/jfx/pull/243/files/759af32c..4142adb3 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/243/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/243/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/243.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/243/head:pull/243 PR: https://git.openjdk.java.net/jfx/pull/243 From ajit.ghaisas at oracle.com Thu Jun 4 08:47:14 2020 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 4 Jun 2020 14:17:14 +0530 Subject: CFV: New OpenJFX Reviewer: Nir Lisker In-Reply-To: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> References: <8e4ecd3e-2b7c-6e2d-7a73-c353858d3cea@oracle.com> Message-ID: <57C364EE-20E6-43CF-80E2-EA4B5CCBEA27@oracle.com> Vote: YES Regards, Ajit > On 03-Jun-2020, at 6:58 PM, Kevin Rushforth wrote: > > I hereby nominate Nir Lisker [1] to OpenJFX Reviewer. > > Nir is an OpenJFX community member, who has contributed 29 changesets [2][3] to OpenJFX over the course of the past 2 years. Nir consistently participates in code reviews of various OpenJFX pull requests, and has become proficient in the areas of: scene graph, animation, graphics, and bindings. > > Votes are due by June 17, 2020. > > Only current OpenJFX Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [5]. Nomination to a project Reviewer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#nlisker > > [2] https://github.com/openjdk/jfx/search?q=author-email%3Anlisker%40openjdk.org&s=author-date&type=Commits > > [3] https://github.com/openjdk/jfx/search?q=author-email%3Anlisker%40gmail.com&s=author-date&type=Commits > > [4] https://openjdk.java.net/census#openjfx > > [5] https://openjdk.java.net/bylaws#three-vote-consensus > > [6] https://openjdk.java.net/projects#project-reviewer > > > From fastegal at openjdk.java.net Thu Jun 4 10:26:23 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 4 Jun 2020 10:26:23 GMT Subject: RFR: 8246195: ListViewSkin/Behavior: misbehavior on switching skin Message-ID: Cleanup memory leaks and malicious side-effects (produced by eventhandlers and listeners that were not removed) when replacing a ListViewSkin. The fix is to remove the listeners/handlers as needed. Added tests that failed before and pass after the fix. It's part of the ongoing cleanup effort [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). ------------- Commit messages: - 8246195: ListViewSkin/Behavior: misbehavior on switching skin Changes: https://git.openjdk.java.net/jfx/pull/247/files Webrev: https://webrevs.openjdk.java.net/jfx/247/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246195 Stats: 269 lines in 7 files changed: 252 ins; 9 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/247.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/247/head:pull/247 PR: https://git.openjdk.java.net/jfx/pull/247 From arapte at openjdk.java.net Thu Jun 4 11:18:57 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 4 Jun 2020 11:18:57 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Wed, 3 Jun 2020 13:45:12 GMT, Kevin Rushforth wrote: > Update: I am testing with 7 level of nested rows, with 10, 9, 7, 6, 5, 4, 3 number of children in each level > respectively. The fix works fine till level 3. But can observe issue with level 4 and further. Shall debug this more > and update. In the above case, The selection updates correctly but the received change event on SelectedItems after sort is incorrect. As of now it looks like the selection is updated correctly with this fix, but the event generated from sort() method is always incorrect. Looking in to fix the change event.... ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Thu Jun 4 11:25:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 4 Jun 2020 11:25:55 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: <1fAURcS1z5M1IIUdPpncGico5sgFvzJhbOoCYGkckMo=.562f23b0-d394-4480-809e-13e5575840d2@github.com> On Wed, 3 Jun 2020 12:03:43 GMT, Jeanette Winzenburg wrote: > The other selectionModels for virtualized controls try to keep the selectedItem/Index only. Keeping the selection after sort/permutation seems more correct from a user's perspective. I did not look into how other controls handle this. Looking at your observation seems like we need to fix this in other controls too, preferably each control in a separate issue :) ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Thu Jun 4 11:47:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Jun 2020 11:47:58 GMT Subject: [Rev 01] RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux In-Reply-To: References: Message-ID: On Thu, 4 Jun 2020 08:46:09 GMT, Michael Paus wrote: >> It seems to be sufficient to add "intel" as an additional vendor to the list in the X11GLFactory class. Tests pass and >> my own application also works with the new build. > > Michael Paus has updated the pull request incrementally with one additional commit since the last revision: > > Remove duplicate GLGPUInfo according to review comment > > My original intention was to keep two entries in order to make it clearer that there are currently two distinct vendor > strings for Intel floating around. But having just one entry which covers both cases is ok for me too. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/243 From mpaus at openjdk.java.net Thu Jun 4 12:54:13 2020 From: mpaus at openjdk.java.net (Michael Paus) Date: Thu, 4 Jun 2020 12:54:13 GMT Subject: [Integrated] RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux In-Reply-To: References: Message-ID: On Mon, 1 Jun 2020 17:52:46 GMT, Michael Paus wrote: > It seems to be sufficient to add "intel" as an additional vendor to the list in the X11GLFactory class. Tests pass and > my own application also works with the new build. This pull request has now been integrated. Changeset: 97499820 Author: Michael Paus Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/97499820 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8246204: No 3D support for newer Intel graphics drivers on Linux Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/243 From fastegal at openjdk.java.net Thu Jun 4 13:02:22 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 4 Jun 2020 13:02:22 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: <1fAURcS1z5M1IIUdPpncGico5sgFvzJhbOoCYGkckMo=.562f23b0-d394-4480-809e-13e5575840d2@github.com> References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> <1fAURcS1z5M1IIUdPpncGico5sgFvzJhbOoCYGkckMo=.562f23b0-d394-4480-809e-13e5575840d2@github.com> Message-ID: On Thu, 4 Jun 2020 11:23:42 GMT, Ambarish Rapte wrote: > > > > The other selectionModels for virtualized controls try to keep the selectedItem/Index only. > > Keeping the selection after sort/permutation seems more correct from a user's perspective. I did not look into how > other controls handle this. Looking at your observation seems like we need to fix this in other controls too, > preferably each control in a separate issue :) well, I don't think so (except for tree which is doing the-wrong-thingy-always): they do keep all state on sort, but not on replace-in-different-sequence - which is correct, I think: it's the semantic of the change notification that must rule, not some assumption of the view. If a replace-in-different-sequence is required to be interpretated as a permutation in a particular use-case, the place to implement it would be a custom list that checks for that corner case and sends a notification of type wasPermutated (instead of a wasReplaced). ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From github.com+60214806+ronyfla at openjdk.java.net Thu Jun 4 15:44:49 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Thu, 4 Jun 2020 15:44:49 GMT Subject: [Rev 02] RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts In-Reply-To: References: Message-ID: > This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The > PI data is turned into a boolean value using "Boolean.parseBoolean(String)". > This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if > the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case > compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be > done without compilation. Because of the fallback scripts get compiled with this version by default. > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > ### Issue > * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement > javax.script.Compilable compile scripts > > > ### Download > `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` > `$ git checkout pull/192` Rony G. Flatscher has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Updates to meet Kevin's comment in PR 192 as of May 27th. - Merge remote-tracking branch 'upstream/master' into scriptCompilablePIcompileFallback - Reword the compile processing instructions (replace 'Hint' with 'Note:', adjust text to context), remove spurious empty line in script example code. - Document the compile processing instruction for scripts. - Add missing language processing instruction. - Correct typo, replace tabs, remove trailing blanks. - Make sure we test the default behaviour to compile script by leaving out the compile PI. - Revert temporary rename of test method. - Correct ModuleLauncherTest (remove non-existing test), correct formatting. - Always supply the script's filename in the error message first to further ease spotting the location of script exceptions. - ... and 17 more: https://git.openjdk.java.net/jfx/compare/6bd0e22d...7ef1bd68 ------------- Changes: https://git.openjdk.java.net/jfx/pull/192/files Webrev: https://webrevs.openjdk.java.net/jfx/192/webrev.02 Stats: 2545 lines in 29 files changed: 2516 ins; 2 del; 27 mod Patch: https://git.openjdk.java.net/jfx/pull/192.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192 PR: https://git.openjdk.java.net/jfx/pull/192 From github.com+2720909+jskov at openjdk.java.net Fri Jun 5 07:05:10 2020 From: github.com+2720909+jskov at openjdk.java.net (Jesper Skov) Date: Fri, 5 Jun 2020 07:05:10 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com> References: <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com> Message-ID: On Thu, 30 Apr 2020 20:15:22 GMT, Kevin Rushforth wrote: >> I have tested on Linux (Fedora 31) only. >> It works as intended (with one test failure due to 15-ea+4 being too old now). >> >> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. >> But as I could not find anything about it, that section in the documentation may need some love. > > Here are a few preliminary comments: Can I do anything to expedite the landing of this - before it gets obsoleted? :) ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From arapte at openjdk.java.net Fri Jun 5 10:01:02 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 5 Jun 2020 10:01:02 GMT Subject: RFR: 8246195: ListViewSkin/Behavior: misbehavior on switching skin In-Reply-To: References: Message-ID: <4Vr7l5Qbare6DMLLeoHX4UKTrqr2pSrdOS_Bi00Mpqw=.cafb4d2f-ff8e-48e7-87a0-13816576acc2@github.com> On Thu, 4 Jun 2020 10:19:47 GMT, Jeanette Winzenburg wrote: > Cleanup memory leaks and malicious side-effects (produced by eventhandlers and listeners that were not removed) when > replacing a ListViewSkin. > The fix is to remove the listeners/handlers as needed. Added tests that failed before and pass after the fix. > > It's part of the ongoing cleanup effort [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/247 From pbansal at openjdk.java.net Sat Jun 6 13:06:15 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sat, 6 Jun 2020 13:06:15 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Fri, 3 Apr 2020 23:41:49 GMT, Thiago Milczarek Sayao wrote: >> I see a lot of work going into this. >> >> In order for this to progress beyond the prototype or concept phase, we will need to have a discussion on the >> openjfx-dev mailing list in a separate email thread that is not directly tied to the PR -- meaning not a reply to the >> RFR thread and not a comment in the PR. @tsayao When you are ready, please send a short email (not a reply to any >> existing message) to openjfx-dev at openjdk.java.net with the following: >> 1. A short summary of the proposed enhancement >> 2. The goals of the proposed enhancement >> 3. A description of the proposed changes (basically, the bullet items from the description of this PR) >> 4. A pointer to this PR for reference >> >> I want to focus the openjfx-dev discussion on getting general agreement on the overall approach rather than on the >> details of the code changes. This is a big change, so getting feedback on the overall goals and approach is important; >> review comments in the PR aren't the best way to have that discussion. We aren't following the formal JEP process for >> JavaFX features, but the JEP template in [JEP 2](https://openjdk.java.net/jeps/2) is a good format to follow for large >> or high-impact features to make sure that the motivation, goals, and tradeoffs are documented. Finally, I note that >> this will eventually need a CSR, but that can be done once there is agreement on the approach, and when this is farther >> along in the review process. > > @kevinrushforth Ok, will do as the instructions. Thanks. I ran the systemTests on Ubuntu 18.04 using gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test. Following are the results Results_18 04 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From jvos at openjdk.java.net Mon Jun 8 09:26:49 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 8 Jun 2020 09:26:49 GMT Subject: RFR: 8245575: Show the ContextMenu of input controls with long press gesture on iOS In-Reply-To: References: Message-ID: On Fri, 22 May 2020 11:45:25 GMT, Jose Pereda wrote: > This PR uses iOS long press gesture to generate a menu event that will trigger a `ContextMenuEvent`. > > Based on this event, input controls will show the ContextMenu (once JDK-8245499 is fixed), and if required, a developer > could add an event handler based on `ContextMenuEvent.CONTEXT_MENU_REQUESTED` for custom processing of such event. modules/javafx.graphics/src/main/native-glass/ios/GlassViewDelegate.m line 385: > 384: } else if (sender.state == UIGestureRecognizerStateEnded) { > 385: // Prevent touch ended event > 386: self.mouseTouch = nil; no release event needed? ------------- PR: https://git.openjdk.java.net/jfx/pull/232 From jpereda at openjdk.java.net Mon Jun 8 09:40:24 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 8 Jun 2020 09:40:24 GMT Subject: RFR: 8245575: Show the ContextMenu of input controls with long press gesture on iOS In-Reply-To: References: Message-ID: <78pCqlcd_A3GnTDXPX-JNMUPtHoCaMdKQnzN3xZZeWM=.8826a731-1332-43c8-8faf-26efc1ee4a20@github.com> On Mon, 8 Jun 2020 09:24:32 GMT, Johan Vos wrote: >> This PR uses iOS long press gesture to generate a menu event that will trigger a `ContextMenuEvent`. >> >> Based on this event, input controls will show the ContextMenu (once JDK-8245499 is fixed), and if required, a developer >> could add an event handler based on `ContextMenuEvent.CONTEXT_MENU_REQUESTED` for custom processing of such event. > > modules/javafx.graphics/src/main/native-glass/ios/GlassViewDelegate.m line 385: > >> 384: } else if (sender.state == UIGestureRecognizerStateEnded) { >> 385: // Prevent touch ended event >> 386: self.mouseTouch = nil; > > no release event needed? The "right-click" event (enter+right down) is simulated when the long press event is detected (`UIGestureRecognizerStateBegan `, which happens after 0.5 seconds by default). This will trigger the ContextMenu. However, the user is still pressing for a few more time. After releasing the tap, (`UIGestureRecognizerStateEnded`), there is no need of adding a release event (exit+right up), as this will probably will close the ContextMenu. The user now can select any of the options from the menu, or simply tap elsewhere to close it. ------------- PR: https://git.openjdk.java.net/jfx/pull/232 From jvos at openjdk.java.net Mon Jun 8 09:52:29 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 8 Jun 2020 09:52:29 GMT Subject: RFR: 8245635: GlassPasteboard::getUTFs fails on iOS In-Reply-To: <_rKgQYpD6f8Wmwr9ao0Nedgd3BqWNp_dTdGfFWKotlw=.314168d5-4fa1-4c48-bd6b-1e79daa837f6@github.com> References: <_rKgQYpD6f8Wmwr9ao0Nedgd3BqWNp_dTdGfFWKotlw=.314168d5-4fa1-4c48-bd6b-1e79daa837f6@github.com> Message-ID: <9GKTezmnCDarNuMqxDztNPF_v4g0gNJe1NhiV8Mjqbs=.7437c2c3-4d31-4dcd-816a-a5c66d90a6dc@github.com> On Fri, 22 May 2020 13:00:07 GMT, Jose Pereda wrote: > As a follow-up of JDK-8245456, IosPasteboard throws a ClassCastException when trying to paste clipboard content on iOS > devices. Same fix apply, using the correct signature. > When retrieving the UTF formats, the native method fails to create the correct String array, as the total number of > keys is not taken into account. Using a for loop fixes the issue. > Relates to JDK-8245499 and JDK-8245575 Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/233 From jpereda at openjdk.java.net Mon Jun 8 09:56:51 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 8 Jun 2020 09:56:51 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: <0lJ9LsO0Tm6LfRtohHck4R3AoPQPv4r02MKPLL-aODQ=.c7cc7e49-cada-4859-a8c7-d0b9cc0f2c1a@github.com> References: <7GsdMU7qYXUo9L2rWoQub9VSfKWHzHpJSC7oAmkF1j0=.fee56afb-90ae-4d2f-922b-22aa45d0cf6f@github.com> <0lJ9LsO0Tm6LfRtohHck4R3AoPQPv4r02MKPLL-aODQ=.c7cc7e49-cada-4859-a8c7-d0b9cc0f2c1a@github.com> Message-ID: On Tue, 26 May 2020 20:17:44 GMT, Kevin Rushforth wrote: >> It would be nice to show this debug info when javafx.pulseLogger is true, and hide it when that property is false. It >> shows interesting information about the rendering phase, so when that info is requested (by enabling pulseLogger), it >> is useful. > > @jperedadnr I think this is pending an answer to @johanvos comment. Also, he should review it, so I set the number of > reviewers to 2. I'll work on showing the log info only when `javafx.pulseLogger` is true. ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From jvos at openjdk.java.net Mon Jun 8 12:11:06 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 8 Jun 2020 12:11:06 GMT Subject: RFR: 8245575: Show the ContextMenu of input controls with long press gesture on iOS In-Reply-To: References: Message-ID: <_rhTvGu_wj0Z8I8ohHM2tYnm-hhQo-VlX5OhquleQHQ=.da28aae9-7a02-4d07-bca2-610fc0baf3e0@github.com> On Fri, 22 May 2020 11:45:25 GMT, Jose Pereda wrote: > This PR uses iOS long press gesture to generate a menu event that will trigger a `ContextMenuEvent`. > > Based on this event, input controls will show the ContextMenu (once JDK-8245499 is fixed), and if required, a developer > could add an event handler based on `ContextMenuEvent.CONTEXT_MENU_REQUESTED` for custom processing of such event. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/232 From fastegal at openjdk.java.net Mon Jun 8 15:38:30 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 8 Jun 2020 15:38:30 GMT Subject: [Integrated] RFR: 8246195: ListViewSkin/Behavior: misbehavior on switching skin In-Reply-To: References: Message-ID: On Thu, 4 Jun 2020 10:19:47 GMT, Jeanette Winzenburg wrote: > Cleanup memory leaks and malicious side-effects (produced by eventhandlers and listeners that were not removed) when > replacing a ListViewSkin. > The fix is to remove the listeners/handlers as needed. Added tests that failed before and pass after the fix. > > It's part of the ongoing cleanup effort [JDK-8241364](https://bugs.openjdk.java.net/browse/JDK-8241364). This pull request has now been integrated. Changeset: a02e09dd Author: Jeanette Winzenburg Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/a02e09dd Stats: 269 lines in 7 files changed: 9 ins; 252 del; 8 mod 8246195: ListViewSkin/Behavior: misbehavior on switching skin Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/247 From github.com+6719843+schelldorfer at openjdk.java.net Tue Jun 9 07:28:41 2020 From: github.com+6719843+schelldorfer at openjdk.java.net (Martin Schelldorfer) Date: Tue, 9 Jun 2020 07:28:41 GMT Subject: RFR: 8244824: TableView : Incorrect German translation In-Reply-To: References: <1Ll4pNkWqP2G6RYxITJo120MTjcA63Q0CQyLd2wO0Nc=.cb0d61f6-0129-4202-8f82-cd82776397ed@github.com> Message-ID: <54Lnf0Q__JUXkXdK9FVthRTVngFCObCRdVxNt894Ke4=.468e2974-4187-4400-bad7-5492d465e46e@github.com> On Tue, 19 May 2020 14:38:01 GMT, Kevin Rushforth wrote: >> @kevinrushforth brought to my notice that there is a PR (https://github.com/openjdk/jfx/pull/210) opened for the same >> issue by [schelldorfer](https://github.com/schelldorfer). I was not aware of this PR as it did not have 'rfr' label - >> which I look for. I picked up this issue from JBS and submitted the solution mentioned in JBS. >> I would *NOT* like to step on a new contributor's contribution. >> >> Now, I see that the original PR has been closed. Once his signed OCA has been recorded, we have two options : >> 1. I will integrate with this PR with due attribution given to [schelldorfer](https://github.com/schelldorfer) >> OR >> 2. I will withdraw my PR without integrating and [schelldorfer](https://github.com/schelldorfer) can reopen and submit >> his PR. > > @aghaisas that sounds fine to me. In order to attribute the fix, you will need to wait for the OCA to be recorded. > > @schelldorfer once your OCA is recorded, which would you prefer to do? Create a new PR yourself or have @aghaisas list > you as the contributor. I signed the OCA a few days ago and my name is listed on the page https://www.oracle.com/technetwork/community/oca-486395.html#s ------------- PR: https://git.openjdk.java.net/jfx/pull/220 From jose.pereda at gluonhq.com Tue Jun 9 09:23:01 2020 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Tue, 9 Jun 2020 11:23:01 +0200 Subject: ListProperty::bind has different behavior than StringProperty::bind when observables are equal Message-ID: Hi, We have come across a possible issue that affects bind() over different types of properties. We are not sure if it's a bug or it behaves as it should be. Therefore, we are reaching out to the community for insight. See these short code snippets below: Snippet 1. StringProperty (could be other like IntegerProperty) StringProperty a = new SimpleStringProperty(); StringProperty b = new SimpleStringProperty(); StringProperty c = new SimpleStringProperty(); c.addListener((obs, ov, nv) -> System.out.println("Change: " + nv)); c.bind(a); c.bind(b); b.set("One"); System.out.println("c contains: " + c.get()); ==== Snippet 2. ListProperty ListProperty a = new SimpleListProperty<>(FXCollections.observableArrayList()); ListProperty b = new SimpleListProperty<>(FXCollections.observableArrayList()); ListProperty c = new SimpleListProperty<>(); c.addListener((ListChangeListener.Change change) -> System.out.println("Change: " + change)); c.bind(a); c.bind(b); b.add("One"); b.add("Two"); System.out.println("c contains: " + Arrays.toString(c.toArray())); ==== While snippet 1 produces: Change: One c contains: One as expected, snippet 2 produces: Change: { [] added at 0 } c contains: [] But the expected result is: Change: { [] added at 0 } Change: { [] added at 0 } Change: { [One] added at 0 } Change: { [Two] added at 1 } c contains: [One, Two] This expected result only happens by manually doing: c.bind(a); c.unbind(); // need to explicitly unbind c.bind(b); Summing up: when binding a new observable to a bound property, unbind is required if that property is a ListProperty, but not a StringProperty (or IntegerProperty). Explanation In the ListProperty.bind implementation [1] there is a check, and only when both current bound observable and new observable are equal, unbind() is applied. The equals is implemented in ReadOnlyListProperty::equals [2] and, being a list, follows the List::equals[3] contract, therefore, it compares by items of the list. This is not the case when using other properties like StringPropertyBase or IntegerPropertyBase, where bind() is implemented in the same way [4], but equals now uses Object::equals[5], so the comparison is now done with ==, instead of comparing by the content of each property. Is this a bug? Should StringProperty, IntegerProperty override equals to compare by content and not by object, like ListProperty does? Should ListProperty use == operator instead of equals? This difference in behavior should be at least documented, shouldn't it? Thanks for any input on this, Jose [1] https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java#L268 [2] https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyListProperty.java#L110 [3] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L542 [4] https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/StringPropertyBase.java#L161 [5] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Object.java#L150 -- From florian.kirmaier at gmail.com Tue Jun 9 10:41:34 2020 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Tue, 9 Jun 2020 12:41:34 +0200 Subject: RFR: 8247163 Fixing exception when clicking on JFXPanel when no Scene is set Message-ID: Hi everyone, I've fixed a small bug in the JFXPanel. Check out my PR for more details: https://github.com/openjdk/jfx/pull/248 Greetings Florian Kirmaier From fkirmaier at openjdk.java.net Tue Jun 9 10:48:28 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 9 Jun 2020 10:48:28 GMT Subject: RFR: 8247163: Fixing exception when clicking on JFXPanel when no Scene is set Message-ID: Fixing exception when clicking on JFXPanel when no Scene is set. quick test: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests: test --tests *javafx.embed.swing.JFXPan* --info` It's a regression from my previous PR: https://github.com/openjdk/jfx/pull/25 ------------- Commit messages: - 8247163: Changes: https://git.openjdk.java.net/jfx/pull/248/files Webrev: https://webrevs.openjdk.java.net/jfx/248/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247163 Stats: 22 lines in 2 files changed: 20 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/248.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/248/head:pull/248 PR: https://git.openjdk.java.net/jfx/pull/248 From jvos at openjdk.java.net Tue Jun 9 11:13:51 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 9 Jun 2020 11:13:51 GMT Subject: [Integrated] RFR: 8246357: Allow static build of webkit library on linux In-Reply-To: References: Message-ID: On Tue, 2 Jun 2020 17:52:37 GMT, Johan Vos wrote: > add changes to build a static version of libjfxwebkit.a > Fox for JDK-8246357 This pull request has now been integrated. Changeset: ba501ef2 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/ba501ef2 Stats: 20 lines in 4 files changed: 0 ins; 17 del; 3 mod 8246357: Allow static build of webkit library on linux Reviewed-by: kcr, ajoseph ------------- PR: https://git.openjdk.java.net/jfx/pull/245 From jpereda at openjdk.java.net Tue Jun 9 11:23:38 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 9 Jun 2020 11:23:38 GMT Subject: [Integrated] RFR: 8245635: GlassPasteboard::getUTFs fails on iOS In-Reply-To: <_rKgQYpD6f8Wmwr9ao0Nedgd3BqWNp_dTdGfFWKotlw=.314168d5-4fa1-4c48-bd6b-1e79daa837f6@github.com> References: <_rKgQYpD6f8Wmwr9ao0Nedgd3BqWNp_dTdGfFWKotlw=.314168d5-4fa1-4c48-bd6b-1e79daa837f6@github.com> Message-ID: On Fri, 22 May 2020 13:00:07 GMT, Jose Pereda wrote: > As a follow-up of JDK-8245456, IosPasteboard throws a ClassCastException when trying to paste clipboard content on iOS > devices. Same fix apply, using the correct signature. > When retrieving the UTF formats, the native method fails to create the correct String array, as the total number of > keys is not taken into account. Using a for loop fixes the issue. > Relates to JDK-8245499 and JDK-8245575 This pull request has now been integrated. Changeset: 53042665 Author: Jose Pereda Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/53042665 Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod 8245635: GlassPasteboard::getUTFs fails on iOS Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/233 From jpereda at openjdk.java.net Tue Jun 9 11:26:27 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 9 Jun 2020 11:26:27 GMT Subject: [Integrated] RFR: 8245575: Show the ContextMenu of input controls with long press gesture on iOS In-Reply-To: References: Message-ID: On Fri, 22 May 2020 11:45:25 GMT, Jose Pereda wrote: > This PR uses iOS long press gesture to generate a menu event that will trigger a `ContextMenuEvent`. > > Based on this event, input controls will show the ContextMenu (once JDK-8245499 is fixed), and if required, a developer > could add an event handler based on `ContextMenuEvent.CONTEXT_MENU_REQUESTED` for custom processing of such event. This pull request has now been integrated. Changeset: afa805fe Author: Jose Pereda Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/afa805fe Stats: 32 lines in 3 files changed: 0 ins; 32 del; 0 mod 8245575: Show the ContextMenu of input controls with long press gesture on iOS Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/232 From joeri.sykora at gluonhq.com Tue Jun 9 11:41:25 2020 From: joeri.sykora at gluonhq.com (Joeri Sykora) Date: Tue, 9 Jun 2020 13:41:25 +0200 Subject: normalizing media URIs before sending the request Message-ID: Hi all, JavaFX media has support for parsing HLS M3U media playlist files. Such a m3u (or m3u8) file contains a list of URIs to the actual media files. These URIs are currently not normalized before the HTTP request is made, which can cause issues in case the URI contains .. segments. For example, try loading the following playlist with the JavaFX media player: https://bcovlive-a.akamaihd.net/r8ceb94e3229b4c0bb2dd461dacb3ab07/us-east-1/6057994532001/playlist.m3u8 It will ultimately try to request the following URL: https://bcovlive-a.akamaihd.net/r8ceb94e3229b4c0bb2dd461dacb3ab07/us-east-1/6057994532001/../../us-east-1/us-east-1/6057994532001/profile_0/chunklist.m3u8 which fails because the HTTP server responds with a 403 response. An easy fix is to normalize the URI (see https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URI.html#normalize()) before making the request in the following sections of HLSConnectionHolder.java: https://github.com/openjdk/jfx/blob/master/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java#L174 https://github.com/openjdk/jfx/blob/master/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java#L370 This time, the request will succeed and the media can be played by JavaFX. The only issue with this fix, is that it is a change in existing behaviour. On the other hand, all browsers that I've tested, first normalize the URI when loading it. The same is true when loading the URI with cURL or other media players I've tested. You can simulate the failing behaviour with cURL when providing the --path-as-is option: curl -I --path-as-is https://bcovlive-a.akamaihd.net/r8ceb94e3229b4c0bb2dd461dacb3ab07/us-east-1/6057994532001/../../us-east-1/us-east-1/6057994532001/profile_0/chunklist.m3u8 I have a strong preference of changing the default behaviour to normalize URIs before making the request. What are your opinions? -- Joeri Sykora *Gluon*E: joeri.sykora at gluonhq.com From fastegal at swingempire.de Tue Jun 9 12:30:59 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 09 Jun 2020 14:30:59 +0200 Subject: ListProperty::bind has different behavior than StringProperty::bind when observables are equal In-Reply-To: References: Message-ID: <20200609143059.Horde.IHhWXB5b55XZHB85VZcQ1g5@webmail.df.eu> sounds a bit like https://bugs.openjdk.java.net/browse/JDK-8094799 - listProperty was fixed for notification of changeListeners to test against identity always, should do in binding as well, IMO Zitat von Jos? Pereda : > Hi, > > We have come across a possible issue that affects bind() over different > types of properties. > We are not sure if it's a bug or it behaves as it should be. Therefore, we > are reaching out to the community for insight. > > See these short code snippets below: > > Snippet 1. StringProperty (could be other like IntegerProperty) > > StringProperty a = new SimpleStringProperty(); > StringProperty b = new SimpleStringProperty(); > StringProperty c = new SimpleStringProperty(); > c.addListener((obs, ov, nv) -> System.out.println("Change: " + nv)); > c.bind(a); > c.bind(b); > b.set("One"); > System.out.println("c contains: " + c.get()); > ==== > > Snippet 2. ListProperty > > ListProperty a = new > SimpleListProperty<>(FXCollections.observableArrayList()); > ListProperty b = new > SimpleListProperty<>(FXCollections.observableArrayList()); > ListProperty c = new SimpleListProperty<>(); > c.addListener((ListChangeListener.Change change) -> > System.out.println("Change: " + change)); > c.bind(a); > c.bind(b); > b.add("One"); > b.add("Two"); > System.out.println("c contains: " + Arrays.toString(c.toArray())); > ==== > > While snippet 1 produces: > > Change: One > c contains: One > > as expected, snippet 2 produces: > > Change: { [] added at 0 } > c contains: [] > > But the expected result is: > > Change: { [] added at 0 } > Change: { [] added at 0 } > Change: { [One] added at 0 } > Change: { [Two] added at 1 } > c contains: [One, Two] > > This expected result only happens by manually doing: > > c.bind(a); > c.unbind(); // need to explicitly unbind > c.bind(b); > > Summing up: when binding a new observable to a bound property, unbind is > required if that property is a ListProperty, but not a StringProperty (or > IntegerProperty). > > Explanation > > In the ListProperty.bind implementation [1] there is a check, and only when > both current bound observable and new observable are equal, unbind() is > applied. > > The equals is implemented in ReadOnlyListProperty::equals [2] and, being a > list, follows the List::equals[3] contract, therefore, it compares by items > of the list. > > This is not the case when using other properties like StringPropertyBase or > IntegerPropertyBase, where bind() is implemented in the same way [4], but > equals now uses Object::equals[5], so the comparison is now done with ==, > instead of comparing by the content of each property. > > Is this a bug? Should StringProperty, IntegerProperty override equals to > compare by content and not by object, like ListProperty does? Should > ListProperty use == operator instead of equals? > > This difference in behavior should be at least documented, shouldn't it? > > > Thanks for any input on this, > Jose > > > [1] > https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java#L268 > [2] > https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyListProperty.java#L110 > [3] > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L542 > [4] > https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/StringPropertyBase.java#L161 > [5] > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Object.java#L150 > > -- From fastegal at swingempire.de Tue Jun 9 13:41:23 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 09 Jun 2020 15:41:23 +0200 Subject: ListCellSkin: cleanup to not use (misbehaving) listeners .. Message-ID: <20200609154123.Horde.DtKnHufmMumwvZGz77C0gg1@webmail.df.eu> After a couple of days spent to understand why/how ListCellSkin listening to the listView's fixedCellSize is misbehaving (there are multiple stumbling stones in its listener registration, details in the bug report https://bugs.openjdk.java.net/browse/JDK-8246745) - I'm about to remove that listener completely. All it does is to copy the value of the listView's fixedCellSize to the skin, without any action triggered. Later on, that copied value is used in the computeXXHeight methods. Code snippets: // fields private double fixedCellSize; private boolean fixedCellSizeEnabled; // listener: registerChangeListener(listView.fixedCellSizeProperty(), e -> { this.fixedCellSize = getSkinnable().getListView().getFixedCellSize(); this.fixedCellSizeEnabled = fixedCellSize > 0; }); // usage @Override protected double computePrefHeight(...) { if (fixedCellSizeEnabled) { return fixedCellSize; } // do the per-row calc ... } Instead of keeping the fields in-sync with those of the listView, we could just query the current state: @Override protected double computePrefHeight(...) { double fixedCellSize = getFixedCellSize(); if (fixedCellSize > 0) { return fixedCellSize; } // do the per-row calc ... } double getFixedCellSize() { ListView listView = getSkinnable().getListView(); return listView != null ? listView.getFixedCellSize() : Region.USE_COMPUTED_SIZE; } Doing so would by-pass the pitfalls of corrently re-wiring the listener to the path property (it's added complexity without benefit). Plus cleanup unneeded aliasing (which I think is a code smell anyway) Opinions, please -- Jeanette From kevin.rushforth at oracle.com Tue Jun 9 13:48:14 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Jun 2020 06:48:14 -0700 Subject: Bulk request to backport 12 fixes to 11-dev for 11.0.8 Message-ID: <510cec0d-e93c-6dcf-52bf-9695dc42f5d3@oracle.com> Hi Johan, I request approval to backport the following 12 fixes to openjfx11: JDK-8237889: Update libxml2 to version 2.9.10 JDK-8244579: Windows "User Objects" leakage with WebView JDK-8236832: [macos 10.15] JavaFX Application hangs on video play on Catalina JDK-8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina JDK-8241629: [macos10.15] Long startup delay playing media over https on Catalina JDK-8242209: Increase web native thread stack size for x86 mode JDK-8239107: Update libjpeg to version 9d JDK-8234474: [macos 10.15] Crash in file dialog in sandbox mode JDK-8236971: [macos] Gestures handled incorrectly due to missing events JDK-8242530: [macos] Some audio files miss spectrum data when another audio file plays first JDK-8241474: Build failing on Ubuntu 20.04 JDK-8237078: [macOS] Media build broken on XCode 11 -- Kevin From jose.pereda at gluonhq.com Tue Jun 9 13:50:42 2020 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Tue, 9 Jun 2020 15:50:42 +0200 Subject: ListProperty::bind has different behavior than StringProperty::bind when observables are equal In-Reply-To: <20200609143059.Horde.IHhWXB5b55XZHB85VZcQ1g5@webmail.df.eu> References: <20200609143059.Horde.IHhWXB5b55XZHB85VZcQ1g5@webmail.df.eu> Message-ID: Thanks, that's helpful. If I get it right, the change applied in ListExpressionHelper [1][2] removed equals: - if ((currentValue == null)? (oldValue != null) : !currentValue.equals(oldValue)) { + if (currentValue != oldValue) { So that will imply that we should do the same in ListPropertyBase::bind? [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/26b7aedb6d60 [2] https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/com/sun/javafx/binding/ListExpressionHelper.java#L552 On Tue, Jun 9, 2020 at 2:33 PM Jeanette Winzenburg wrote: > > sounds a bit like https://bugs.openjdk.java.net/browse/JDK-8094799 - > listProperty was fixed for notification of changeListeners to test > against identity always, should do in binding as well, IMO > > Zitat von Jos? Pereda : > > > Hi, > > > > We have come across a possible issue that affects bind() over different > > types of properties. > > We are not sure if it's a bug or it behaves as it should be. Therefore, > we > > are reaching out to the community for insight. > > > > See these short code snippets below: > > > > Snippet 1. StringProperty (could be other like IntegerProperty) > > > > StringProperty a = new SimpleStringProperty(); > > StringProperty b = new SimpleStringProperty(); > > StringProperty c = new SimpleStringProperty(); > > c.addListener((obs, ov, nv) -> System.out.println("Change: " + nv)); > > c.bind(a); > > c.bind(b); > > b.set("One"); > > System.out.println("c contains: " + c.get()); > > ==== > > > > Snippet 2. ListProperty > > > > ListProperty a = new > > SimpleListProperty<>(FXCollections.observableArrayList()); > > ListProperty b = new > > SimpleListProperty<>(FXCollections.observableArrayList()); > > ListProperty c = new SimpleListProperty<>(); > > c.addListener((ListChangeListener.Change change) -> > > System.out.println("Change: " + change)); > > c.bind(a); > > c.bind(b); > > b.add("One"); > > b.add("Two"); > > System.out.println("c contains: " + Arrays.toString(c.toArray())); > > ==== > > > > While snippet 1 produces: > > > > Change: One > > c contains: One > > > > as expected, snippet 2 produces: > > > > Change: { [] added at 0 } > > c contains: [] > > > > But the expected result is: > > > > Change: { [] added at 0 } > > Change: { [] added at 0 } > > Change: { [One] added at 0 } > > Change: { [Two] added at 1 } > > c contains: [One, Two] > > > > This expected result only happens by manually doing: > > > > c.bind(a); > > c.unbind(); // need to explicitly unbind > > c.bind(b); > > > > Summing up: when binding a new observable to a bound property, unbind is > > required if that property is a ListProperty, but not a StringProperty (or > > IntegerProperty). > > > > Explanation > > > > In the ListProperty.bind implementation [1] there is a check, and only > when > > both current bound observable and new observable are equal, unbind() is > > applied. > > > > The equals is implemented in ReadOnlyListProperty::equals [2] and, being > a > > list, follows the List::equals[3] contract, therefore, it compares by > items > > of the list. > > > > This is not the case when using other properties like StringPropertyBase > or > > IntegerPropertyBase, where bind() is implemented in the same way [4], but > > equals now uses Object::equals[5], so the comparison is now done with ==, > > instead of comparing by the content of each property. > > > > Is this a bug? Should StringProperty, IntegerProperty override equals to > > compare by content and not by object, like ListProperty does? Should > > ListProperty use == operator instead of equals? > > > > This difference in behavior should be at least documented, shouldn't it? > > > > > > Thanks for any input on this, > > Jose > > > > > > [1] > > > https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/ListPropertyBase.java#L268 > > [2] > > > https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyListProperty.java#L110 > > [3] > > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/List.java#L542 > > [4] > > > https://github.com/openjdk/jfx/blob/22d4343fe8563c2931910b98e8f18c6fd4a48f05/modules/javafx.base/src/main/java/javafx/beans/property/StringPropertyBase.java#L161 > > [5] > > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Object.java#L150 > > > > -- > > > > -- From fastegal at swingempire.de Tue Jun 9 14:16:29 2020 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Tue, 09 Jun 2020 16:16:29 +0200 Subject: ListProperty::bind has different behavior than StringProperty::bind when observables are equal In-Reply-To: References: <20200609143059.Horde.IHhWXB5b55XZHB85VZcQ1g5@webmail.df.eu> Message-ID: <20200609161629.Horde.8tCsYcVg7uh6ICREFtypTw1@webmail.df.eu> Zitat von Jos? Pereda : > Thanks, that's helpful. > > If I get it right, the change applied in ListExpressionHelper [1][2] > removed equals: > > - if ((currentValue == null)? (oldValue != null) : > !currentValue.equals(oldValue)) { > + if (currentValue != oldValue) { > > So that will imply that we should do the same in ListPropertyBase::bind? > exactly :) IMO, at least - otherwise we get all the old problems back: the binding (just the same as listing) must be to an exact instance, not to something that's equal but another instance. From johan.vos at gluonhq.com Tue Jun 9 14:36:59 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 9 Jun 2020 16:36:59 +0200 Subject: Bulk request to backport 12 fixes to 11-dev for 11.0.8 In-Reply-To: <510cec0d-e93c-6dcf-52bf-9695dc42f5d3@oracle.com> References: <510cec0d-e93c-6dcf-52bf-9695dc42f5d3@oracle.com> Message-ID: Approved. On Tue, Jun 9, 2020 at 3:48 PM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the following 12 fixes to openjfx11: > > JDK-8237889: Update libxml2 to version 2.9.10 > JDK-8244579: Windows "User Objects" leakage with WebView > JDK-8236832: [macos 10.15] JavaFX Application hangs on video play on > Catalina > JDK-8240694: [macos 10.15] JavaFX Media hangs on some video files on > Catalina > JDK-8241629: [macos10.15] Long startup delay playing media over https on > Catalina > JDK-8242209: Increase web native thread stack size for x86 mode > JDK-8239107: Update libjpeg to version 9d > JDK-8234474: [macos 10.15] Crash in file dialog in sandbox mode > JDK-8236971: [macos] Gestures handled incorrectly due to missing events > JDK-8242530: [macos] Some audio files miss spectrum data when another > audio file plays first > JDK-8241474: Build failing on Ubuntu 20.04 > JDK-8237078: [macOS] Media build broken on XCode 11 > > -- Kevin > > From kcr at openjdk.java.net Tue Jun 9 23:14:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Jun 2020 23:14:26 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Sat, 6 Jun 2020 13:03:36 GMT, Pankaj Bansal wrote: >> @kevinrushforth Ok, will do as the instructions. Thanks. > > I ran the systemTests on Ubuntu 18.04 using > gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest > :systemTests:test. Following are the results Results_18 04 src="https://user-images.githubusercontent.com/6153953/83944842-359d1f00-a824-11ea-964b-f7d9664af9f3.png"> In case it is useful to those reviewing the code, I have created a [WIP pull request](https://github.com/kevinrushforth/jfx/pull/1) in my repo solely for the purpose of looking at the diffs between the existing gtk native code and the experimental GTK native code from *this* pull request. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Tue Jun 9 23:16:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Jun 2020 23:16:51 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Tue, 9 Jun 2020 23:12:15 GMT, Kevin Rushforth wrote: >> I ran the systemTests on Ubuntu 18.04 using >> gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest >> :systemTests:test. Following are the results Results_18 04> src="https://user-images.githubusercontent.com/6153953/83944842-359d1f00-a824-11ea-964b-f7d9664af9f3.png"> > > In case it is useful to those reviewing the code, I have created a [WIP pull > request](https://github.com/kevinrushforth/jfx/pull/1) in my repo solely for the purpose of looking at the diffs > between the existing gtk native code and the experimental GTK native code from *this* pull request. I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle Linux 7.7. One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle checking GTK version 3 trying GTK library libgtk-3.so.0 using GTK library version 3 set libgtk-3.so.0 Glass GTK library to load is glassgtk3_exp loaded gdk_x11_display_set_window_scale java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: gdk_display_get_n_monitors ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jun 10 00:30:23 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 10 Jun 2020 00:30:23 GMT Subject: [Rev 52] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Forgot a g_print ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/7d350bc6..e947aa66 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.52 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.51-52 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jun 10 00:30:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Jun 2020 00:30:23 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Tue, 9 Jun 2020 23:14:31 GMT, Kevin Rushforth wrote: >> In case it is useful to those reviewing the code, I have created a [WIP pull >> request](https://github.com/kevinrushforth/jfx/pull/1) in my repo solely for the purpose of looking at the diffs >> between the existing gtk native code and the experimental GTK native code from *this* pull request. > > I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle > Linux 7.7. > One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: > > $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle > checking GTK version 3 > trying GTK library libgtk-3.so.0 > using GTK library version 3 set libgtk-3.so.0 > Glass GTK library to load is glassgtk3_exp > loaded gdk_x11_display_set_window_scale > java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: > gdk_display_get_n_monitors Here are the results with Ubuntu 20.04: ![Ubuntu-20 04-test-results](https://user-images.githubusercontent.com/34689748/84213198-e0a41780-aa74-11ea-9362-08c621af6746.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jun 10 02:31:38 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 10 Jun 2020 02:31:38 GMT Subject: [Rev 53] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Limit GTK on 3.18 (Ubuntu 16.04) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/e947aa66..9c83ac12 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.53 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.52-53 Stats: 80 lines in 4 files changed: 1 ins; 76 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jun 10 02:40:38 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 10 Jun 2020 02:40:38 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: On Tue, 9 Jun 2020 23:14:31 GMT, Kevin Rushforth wrote: > I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle > Linux 7.7. > One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: > > ``` > $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle > checking GTK version 3 > trying GTK library libgtk-3.so.0 > using GTK library version 3 set libgtk-3.so.0 > Glass GTK library to load is glassgtk3_exp > loaded gdk_x11_display_set_window_scale > java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: > gdk_display_get_n_monitors ``` I have limited GTK compilation to use GTK 3.8 symbols. Will run more tests, but should fix it. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Wed Jun 10 02:40:37 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 10 Jun 2020 02:40:37 GMT Subject: [Rev 54] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Limit GTK on 3.8 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/9c83ac12..2700f6fb Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.54 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.53-54 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From aghaisas at openjdk.java.net Wed Jun 10 08:57:38 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 10 Jun 2020 08:57:38 GMT Subject: RFR: 8242892: SpinnerValueFactory has an implicit no-arg constructor Message-ID: Issue : https://bugs.openjdk.java.net/browse/JDK-8242892 Fix : Added a constructor to SpinnerValueFactory class with minimal description. ------------- Commit messages: - added constructor Changes: https://git.openjdk.java.net/jfx/pull/250/files Webrev: https://webrevs.openjdk.java.net/jfx/250/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242892 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/250.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/250/head:pull/250 PR: https://git.openjdk.java.net/jfx/pull/250 From jvos at openjdk.java.net Wed Jun 10 12:07:24 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 10 Jun 2020 12:07:24 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars Message-ID: This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 ------------- Commit messages: - Add check for 0 in text - allow different TextRuns to share the same UTF 16 text, but create separate - Use number of real characters when obtaining pointers in a string. Changes: https://git.openjdk.java.net/jfx/pull/249/files Webrev: https://webrevs.openjdk.java.net/jfx/249/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246348 Stats: 44 lines in 4 files changed: 37 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/249/head:pull/249 PR: https://git.openjdk.java.net/jfx/pull/249 From fastegal at openjdk.java.net Wed Jun 10 12:35:58 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 10 Jun 2020 12:35:58 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin Message-ID: ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the listView and incorrect update of internal state (see bug report for details) Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView state when needed. Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior before/after. ------------- Commit messages: - 8246745: ListCell/Skin: misbehavior on switching skin Changes: https://git.openjdk.java.net/jfx/pull/251/files Webrev: https://webrevs.openjdk.java.net/jfx/251/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246745 Stats: 98 lines in 4 files changed: 59 ins; 33 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/251.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/251/head:pull/251 PR: https://git.openjdk.java.net/jfx/pull/251 From tsayao at openjdk.java.net Wed Jun 10 13:13:46 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 10 Jun 2020 13:13:46 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> Message-ID: <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@github.com> On Wed, 10 Jun 2020 02:25:00 GMT, Thiago Milczarek Sayao wrote: >> I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle >> Linux 7.7. >> One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: >> >> $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle >> checking GTK version 3 >> trying GTK library libgtk-3.so.0 >> using GTK library version 3 set libgtk-3.so.0 >> Glass GTK library to load is glassgtk3_exp >> loaded gdk_x11_display_set_window_scale >> java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: >> gdk_display_get_n_monitors > >> I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle >> Linux 7.7. >> One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: >> >> ``` >> $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle >> checking GTK version 3 >> trying GTK library libgtk-3.so.0 >> using GTK library version 3 set libgtk-3.so.0 >> Glass GTK library to load is glassgtk3_exp >> loaded gdk_x11_display_set_window_scale >> java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: >> gdk_display_get_n_monitors ``` > > I have limited GTK compilation to use GTK 3.8 symbols. Will run more tests, but should fix it. Here is the result on Ubuntu 20.04 with the latest changes: ![image](https://user-images.githubusercontent.com/30704286/84271590-abdea180-ab02-11ea-9d2d-dbca39755db0.png) Some tests seems intermittent. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Wed Jun 10 23:35:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Jun 2020 23:35:52 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 12:25:04 GMT, Jeanette Winzenburg wrote: > ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the > listView and incorrect update of internal state (see bug report for details) > Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView > state when needed. > Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior > before/after. @arapte can you review? ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From kcr at openjdk.java.net Thu Jun 11 00:20:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 00:20:01 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 19:33:01 GMT, Johan Vos wrote: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 87: > 86: > 87: private Map runUtf8 = new HashMap<>(); > 88: public void layout(TextRun run, PGFont font, FontStrike strike, char[] text) { In order for this to work, each TextRun would need to be immutable (at least during the life of this PangoGlyphLayout) and there would need to be a 1-1 mapping between the TextRun and the string pointer, independent of anything else. Is this the case? I'm seeing some crashes in OSPango.g_utf8_offset_to_pointer when testing. I don't know if they are related to this or not. modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 90: > 89: for (char c: text) { > 90: if (c == 0) c = '\f'; > 91: } This won't actually do anything (it just sets a local variable that immediately goes out of scope). I don't think that we want to modify the array itself, so you will probably want to make a copy of the array in the case there is a '0' character. As for what to replace the '0' char with, maybe a space? @prrace can probably suggest something. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Thu Jun 11 00:33:04 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 00:33:04 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 00:14:23 GMT, Kevin Rushforth wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 90: > >> 89: for (char c: text) { >> 90: if (c == 0) c = '\f'; >> 91: } > > This won't actually do anything (it just sets a local variable that immediately goes out of scope). I don't think that > we want to modify the array itself, so you will probably want to make a copy of the array in the case there is a '0' > character. As for what to replace the '0' char with, maybe a space? @prrace can probably suggest something. Interestingly enough, I don't see a crash due to the 0 character, but I am seeing some new assertion warnings expecting `length >= 0` even in cases where there isn't a 0 character. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Thu Jun 11 00:36:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 00:36:42 GMT Subject: RFR: 8247163: JFXPanel throws exception on click when no Scene is set In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 10:39:29 GMT, Florian Kirmaier wrote: > Fixing exception when clicking on JFXPanel when no Scene is set. > > quick test: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests: test --tests *javafx.embed.swing.JFXPan* --info` > > It's a regression from my previous PR: https://github.com/openjdk/jfx/pull/25 The fix looks correct to me (I haven't tested it yet). I left a minor comment inline. modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 452: > 451: // which doesn't have any side-effects when called multiple times. > 452: if(stagePeer != null) { > 453: int focusCause = AbstractEvents.FOCUSEVENT_ACTIVATED; Minor: space after the `if` ------------- PR: https://git.openjdk.java.net/jfx/pull/248 From jvos at openjdk.java.net Thu Jun 11 13:28:51 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 11 Jun 2020 13:28:51 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 00:30:55 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 90: >> >>> 89: for (char c: text) { >>> 90: if (c == 0) c = '\f'; >>> 91: } >> >> This won't actually do anything (it just sets a local variable that immediately goes out of scope). I don't think that >> we want to modify the array itself, so you will probably want to make a copy of the array in the case there is a '0' >> character. As for what to replace the '0' char with, maybe a space? @prrace can probably suggest something. > > Interestingly enough, I don't see a crash due to the 0 character, but I am seeing some new assertion warnings expecting > `length >= 0` even in cases where there isn't a 0 character. I saw that assertion as well, but that can come from cases where empty TextRun instances are used (start == end). In that case, the length is 0, which pango considers silly, but it won't crash on that (the content array is never examined in that case) ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From jvos at openjdk.java.net Thu Jun 11 13:32:18 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 11 Jun 2020 13:32:18 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 00:12:39 GMT, Kevin Rushforth wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 87: > >> 86: >> 87: private Map runUtf8 = new HashMap<>(); >> 88: public void layout(TextRun run, PGFont font, FontStrike strike, char[] text) { > > In order for this to work, each TextRun would need to be immutable (at least during the life of this PangoGlyphLayout) > and there would need to be a 1-1 mapping between the TextRun and the string pointer, independent of anything else. Is > this the case? I'm seeing some crashes in OSPango.g_utf8_offset_to_pointer when testing. I don't know if they are > related to this or not. I would assume that once the layout method is called, the TextRun won't change anymore. If it would change, the current code might break as well, as the string pointer is currently cached. I agree though that this is a brittle approach. What I'm basically doing here is store additional information (the number of unicode codepoints rather than the number of UTF 16 chars, which can then be mapped to the string pointer pointing to the relevant substring) on the TextRun, but since I didn't want to modify TextRun, that additional info is stored in this Map. I'd prefer modifying TextRun though. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From fastegal at openjdk.java.net Thu Jun 11 14:41:27 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 11 Jun 2020 14:41:27 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: <6WhyH_3NIHMKxVw-xsTv6jAsSb2njDPkaaNVz64y60E=.352fb913-33e4-40ee-a28b-9da54e7095c8@github.com> References: <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com> <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com> <6WhyH_3NIHMKxVw-xsTv6jAsSb2njDPkaaN Vz64y60E=.352fb913-33e4-40ee-a28b-9da54e7095c8@github.com> Message-ID: <4I58IIqTX2S0zeE9j7bhrP7RPdu1Ei1x0sz40K2VaWU=.e33d173d-b104-45ca-b772-721e722c333b@github.com> On Thu, 28 May 2020 06:50:57 GMT, Robert Lichtenberger wrote: >> Most of the time, value in javafx.scene.control.TextInputControl.replaceText(int, int, String, int, int) will already >> be filtered (e.g. linebreaks in TextField) In that case, adjustmentAmount will be zero and one could just do the >> selection before actually inserting the text. >> But a case can be constructed with a TextFormatter that will produce characters that will be filtered by the TextField >> itself: >> >> @Test public void replaceSelectionWithFilteredCharacters() { >> txtField.setText("x xxxyyy"); >> txtField.selectRange(2, 5); >> txtField.setTextFormatter(new TextFormatter<>(this::noDigits)); >> txtField.replaceSelection("a1234a"); >> assertEquals("x aayyy", txtField.getText()); >> assertEquals(4, txtField.getSelection().getStart()); >> assertEquals(4, txtField.getSelection().getStart()); >> } >> >> private Change noDigits(Change change) { >> Change filtered = change.clone(); >> filtered.setText(change.getText().replaceAll("[0-9]","\n")); >> return filtered; >> } > > The last commit on this branch seems like the "best" way to fix this problem. It prevents in-between changes in > selectedText and does not introduce (to the best of my knowledge) any new corner cases. It eliminiates the "root cause" > of the problem by postponing selectedText update to the end of whole replace-operation. So, this is RFR now (I hope). good direction, I think :) Didn't look too closely, just added your changes and run the tests - getting a StringIndexOutofBounds at TextInputControlTest.test_jdk_8171229_replaceText(TextInputControlTest.java:1862) (no failing test because the uncaughtException handler not redirected). Could you check please? ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From kcr at openjdk.java.net Thu Jun 11 17:50:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 17:50:30 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 13:30:00 GMT, Johan Vos wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 87: >> >>> 86: >>> 87: private Map runUtf8 = new HashMap<>(); >>> 88: public void layout(TextRun run, PGFont font, FontStrike strike, char[] text) { >> >> In order for this to work, each TextRun would need to be immutable (at least during the life of this PangoGlyphLayout) >> and there would need to be a 1-1 mapping between the TextRun and the string pointer, independent of anything else. Is >> this the case? I'm seeing some crashes in OSPango.g_utf8_offset_to_pointer when testing. I don't know if they are >> related to this or not. > > I would assume that once the layout method is called, the TextRun won't change anymore. If it would change, the current > code might break as well, as the string pointer is currently cached. I agree though that this is a brittle approach. > What I'm basically doing here is store additional information (the number of unicode codepoints rather than the number > of UTF 16 chars, which can then be mapped to the string pointer pointing to the relevant substring) on the TextRun, but > since I didn't want to modify TextRun, that additional info is stored in this Map. I'd prefer modifying TextRun though. I think I see what you are trying to do, but there are a couple of problems it is causing. I attached a new test program to the JBS bug report, UnicodeTextTest2.java, which avoids any null (0) characters. That test runs fine today, and with the first version of your fix (the one without the Map), but causes assertion failures with the current version of the patch: (java:32761): Pango-CRITICAL **: 10:37:09.535: pango_itemize: assertion 'length >= 0' failed (java:32761): Pango-CRITICAL **: 10:37:09.963: pango_itemize: assertion 'length >= 0' failed I also sometimes get this: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f00456c2d78, pid=32761, tid=32778 # # JRE version: Java(TM) SE Runtime Environment (14.0+36) (build 14+36-1461) # Java VM: Java HotSpot(TM) 64-Bit Server VM (14+36-1461, mixed mode, sharing, tiered, compressed oops, serial gc, linux-amd64) # Problematic frame: # C [libglib-2.0.so.0+0x84d78] g_utf8_offset_to_pointer+0x28 Phil is the expert here, so I'd like him to weigh in. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From prr at openjdk.java.net Thu Jun 11 18:10:27 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 11 Jun 2020 18:10:27 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 19:33:01 GMT, Johan Vos wrote: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 Instead of a space you could use a ZWNJ U+FEFF. Because that is also the endian-ness mark, Unicode actually prefers you now to use U+2060 but you need to make sure these are processed correctly by pango. Unlike a space they should have no rendering effect - not even an advance. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Thu Jun 11 19:06:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 19:06:58 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 19:33:01 GMT, Johan Vos wrote: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 148: > 147: long utflen = OSPango.g_utf8_strlen(str,-1); > 148: long end = OSPango.g_utf8_offset_to_pointer(str, utflen); > 149: long runs = OSPango.pango_itemize(context, str, (int)(start - str), (int)(end - start), attrList, 0); Since you are now creating `n` native strings, 1 per substring based on the `TextRun`, rather than 1 for the entire String, isn't the `start` pointer wrong? Unless I am missing something, I would think that `start` should be set to `str`. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Thu Jun 11 19:13:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 19:13:14 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 19:04:47 GMT, Kevin Rushforth wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 148: > >> 147: long utflen = OSPango.g_utf8_strlen(str,-1); >> 148: long end = OSPango.g_utf8_offset_to_pointer(str, utflen); >> 149: long runs = OSPango.pango_itemize(context, str, (int)(start - str), (int)(end - start), attrList, 0); > > Since you are now creating `n` native strings, 1 per substring based on the `TextRun`, rather than 1 for the entire > String, isn't the `start` pointer wrong? Unless I am missing something, I would think that `start` should be set to > `str`. I did a quick test, and setting `start = str` fixes the spurious assertions and intermittent crash. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Thu Jun 11 19:22:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 19:22:21 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 19:11:03 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 148: >> >>> 147: long utflen = OSPango.g_utf8_strlen(str,-1); >>> 148: long end = OSPango.g_utf8_offset_to_pointer(str, utflen); >>> 149: long runs = OSPango.pango_itemize(context, str, (int)(start - str), (int)(end - start), attrList, 0); >> >> Since you are now creating `n` native strings, 1 per substring based on the `TextRun`, rather than 1 for the entire >> String, isn't the `start` pointer wrong? Unless I am missing something, I would think that `start` should be set to >> `str`. > > I did a quick test, and setting `start = str` fixes the spurious assertions and intermittent crash. I should add that this is without any attempt to filter out `0` chars. Both `UnicodeTextTest` and `UnicodeTextTest2` run correctly with no crashes and no assertions when I comment out the (ineffective) loop checking for 0 and set `start = str` leaving everything else as you have it in the current PR. Loading https://gluonhq.com/ in WebView works, too. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From nlisker at gmail.com Thu Jun 11 19:19:43 2020 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 11 Jun 2020 22:19:43 +0300 Subject: ListProperty::bind has different behavior than StringProperty::bind when observables are equal In-Reply-To: <20200609161629.Horde.8tCsYcVg7uh6ICREFtypTw1@webmail.df.eu> References: <20200609143059.Horde.IHhWXB5b55XZHB85VZcQ1g5@webmail.df.eu> <20200609161629.Horde.8tCsYcVg7uh6ICREFtypTw1@webmail.df.eu> Message-ID: Set and Map will also need this change then. On Tue, Jun 9, 2020 at 5:16 PM Jeanette Winzenburg wrote: > > Zitat von Jos? Pereda : > > > Thanks, that's helpful. > > > > If I get it right, the change applied in ListExpressionHelper [1][2] > > removed equals: > > > > - if ((currentValue == null)? (oldValue != null) : > > !currentValue.equals(oldValue)) { > > + if (currentValue != oldValue) { > > > > So that will imply that we should do the same in ListPropertyBase::bind? > > > > exactly :) IMO, at least - otherwise we get all the old problems back: > the binding (just the same as listing) must be to an exact instance, > not to something that's equal but another instance. > > From kcr at openjdk.java.net Thu Jun 11 19:27:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 19:27:20 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 17:48:16 GMT, Kevin Rushforth wrote: >> I would assume that once the layout method is called, the TextRun won't change anymore. If it would change, the current >> code might break as well, as the string pointer is currently cached. I agree though that this is a brittle approach. >> What I'm basically doing here is store additional information (the number of unicode codepoints rather than the number >> of UTF 16 chars, which can then be mapped to the string pointer pointing to the relevant substring) on the TextRun, but >> since I didn't want to modify TextRun, that additional info is stored in this Map. I'd prefer modifying TextRun though. > > I think I see what you are trying to do, but there are a couple of problems it is causing. I attached a new test > program to the JBS bug report, UnicodeTextTest2.java, which avoids any null (0) characters. That test runs fine today, > and with the first version of your fix (the one without the Map), but causes assertion failures with the current > version of the patch: (java:32761): Pango-CRITICAL **: 10:37:09.535: pango_itemize: assertion 'length >= 0' failed > (java:32761): Pango-CRITICAL **: 10:37:09.963: pango_itemize: assertion 'length >= 0' failed > > I also sometimes get this: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007f00456c2d78, pid=32761, tid=32778 > # > # JRE version: Java(TM) SE Runtime Environment (14.0+36) (build 14+36-1461) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (14+36-1461, mixed mode, sharing, tiered, compressed oops, serial gc, > linux-amd64) # Problematic frame: > # C [libglib-2.0.so.0+0x84d78] g_utf8_offset_to_pointer+0x28 > > Phil is the expert here, so I'd like him to weigh in. Given my observation with the `start` pointer, I think the `HashMap` as you are using it is fine. Do you think a `LinkedHashMap` might be useful to preserve the iteration order? (since you only iterate it once in `dispose` it probably doesn't matter). ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Thu Jun 11 20:49:21 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 20:49:21 GMT Subject: [Rev 04] RFR: 8218973: SVG with masking is not rendering image with mask effect In-Reply-To: References: Message-ID: On Tue, 19 May 2020 10:13:44 GMT, Bhawesh Choudhary wrote: >> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp in WebKit was not implemented, so masking >> doesn't take place at all while rendering SVGRect. to fix this issue add implementation of function clipToImageBuffer() >> in GraphicsContextJava.cpp and send clip image to WCGraphicsPrismContext.java While rendering in >> WCGraphicsPrismContext.java if image clip mask is available, use it for rendering using MaskTextureGraphics interface >> otherwise use usual way of rendering. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessery Ceil Functions The code looks good (with a couple minor formatting issues). All of the onscreen testing I did looks good on Windows. I'd like to test it on Mac as well. There is an issue with printing in the case of Hi-DPI scaling, which is what I run by default on Windows. The gradient texture appears to be scaled incorrectly (as if the scale was applied more than once). If I force scaling to 1 with `-Dglass.win.uiScale=1` then it prints correctly. modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 531: > 530: render(g, shadow, paint, null, node); > 531: } else if(state.getClipMaskImageNoClone() != null) { > 532: Rectangle rect = new Rectangle((int) x, (int) y, (int) w, (int) h); space after `if` modules/javafx.web/src/main/java/com/sun/javafx/webkit/prism/WCGraphicsPrismContext.java line 553: > 552: maskTexture.dispose(); > 553: if(g instanceof MaskTextureGraphics && !(g instanceof PrinterGraphics)) { > 554: MaskTextureGraphics mg = (MaskTextureGraphics) (g); space after `if` ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From prr at openjdk.java.net Thu Jun 11 23:01:20 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 11 Jun 2020 23:01:20 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 19:33:01 GMT, Johan Vos wrote: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 140: > 139: runUtf8.put(run, str); > 140: if (check(str, "Failed allocating UTF-8 buffer.", context, desc, attrList)) { > 141: return; Did you really mean to store the run in the map before checking if str is null ? ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From prr at openjdk.java.net Thu Jun 11 23:32:01 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 11 Jun 2020 23:32:01 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 19:20:05 GMT, Kevin Rushforth wrote: >> I did a quick test, and setting `start = str` fixes the spurious assertions and intermittent crash. > > I should add that this is without any attempt to filter out `0` chars. Both `UnicodeTextTest` and `UnicodeTextTest2` > run correctly with no crashes and no assertions when I comment out the (ineffective) loop checking for 0 and set `start > = str` leaving everything else as you have it in the current PR. Loading https://gluonhq.com/ in WebView works, too. I agree. the text array is now the subset for the run, so effectively run.getStart() should be zero, so there should be no need for that call. This probably looks OK when there is one run not otherwise. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Thu Jun 11 23:39:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 23:39:53 GMT Subject: RFR: 8247163: JFXPanel throws exception on click when no Scene is set In-Reply-To: References: Message-ID: <-ciZDh41dLgOR8dcN1ZxND60CBqIfUfqN_8iiHVY0v4=.65397f8e-8199-4276-9c1c-04179c364ad6@github.com> On Thu, 11 Jun 2020 00:34:20 GMT, Kevin Rushforth wrote: >> Fixing exception when clicking on JFXPanel when no Scene is set. >> >> quick test: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests: test --tests *javafx.embed.swing.JFXPan* --info` >> >> It's a regression from my previous PR: https://github.com/openjdk/jfx/pull/25 > > The fix looks correct to me (I haven't tested it yet). I left a minor comment inline. The fix and test both look good. Approved pending the minor format change (no need for a second reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/248 From kcr at openjdk.java.net Thu Jun 11 23:56:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Jun 2020 23:56:46 GMT Subject: RFR: 8242892: SpinnerValueFactory has an implicit no-arg constructor In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 08:49:48 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8242892 > > Fix : Added a constructor to SpinnerValueFactory class with minimal description. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/250 From aghaisas at openjdk.java.net Fri Jun 12 04:20:34 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 12 Jun 2020 04:20:34 GMT Subject: [Integrated] RFR: 8242892: SpinnerValueFactory has an implicit no-arg constructor In-Reply-To: References: Message-ID: <_QSNhpx3tBqY195moY5jykiIPH_5oz6jpNkTuaTnrio=.21753ff4-1f1b-4bef-b841-eb2662511e51@github.com> On Wed, 10 Jun 2020 08:49:48 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8242892 > > Fix : Added a constructor to SpinnerValueFactory class with minimal description. This pull request has now been integrated. Changeset: b2b46eb3 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/b2b46eb3 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod 8242892: SpinnerValueFactory has an implicit no-arg constructor Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/250 From pbansal at openjdk.java.net Fri Jun 12 05:59:01 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 12 Jun 2020 05:59:01 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Wed, 10 Jun 2020 13:11:29 GMT, Thiago Milczarek Sayao wrote: >>> I am running a full test using GTK 3 on Ubuntu 20.04 and will publish results. I will later do the same for Oracle >>> Linux 7.7. >>> One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. I get the following running any program: >>> >>> ``` >>> $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle >>> checking GTK version 3 >>> trying GTK library libgtk-3.so.0 >>> using GTK library version 3 set libgtk-3.so.0 >>> Glass GTK library to load is glassgtk3_exp >>> loaded gdk_x11_display_set_window_scale >>> java: symbol lookup error: /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: undefined symbol: >>> gdk_display_get_n_monitors ``` >> >> I have limited GTK compilation to use GTK 3.8 symbols. Will run more tests, but should fix it. > > Here is the result on Ubuntu 20.04 with the latest changes: > > ![image](https://user-images.githubusercontent.com/30704286/84271590-abdea180-ab02-11ea-9d2d-dbca39755db0.png) > > Some tests seems intermittent. I have run the test on OL82 on updated code. Following are the results. I will rerun this on Ubuntu 18.04 and get back with the results OL82 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+7450507+fthevenet at openjdk.java.net Fri Jun 12 09:30:25 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 12 Jun 2020 09:30:25 GMT Subject: [Rev 05] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with three additional commits since the last revision: - Use boolean[] instead of AtomicBoolean to effec pass-by-reference - Fixed typo in comment - Removed fully qualified name when declaring RTTexture ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/7f5f2890..1fb04e56 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.04-05 Stats: 126 lines in 1 file changed: 31 ins; 79 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+6719843+schelldorfer at openjdk.java.net Fri Jun 12 10:04:16 2020 From: github.com+6719843+schelldorfer at openjdk.java.net (Martin Schelldorfer) Date: Fri, 12 Jun 2020 10:04:16 GMT Subject: RFR: 8244824: TableView : Incorrect German translation In-Reply-To: References: <1Ll4pNkWqP2G6RYxITJo120MTjcA63Q0CQyLd2wO0Nc=.cb0d61f6-0129-4202-8f82-cd82776397ed@github.com> Message-ID: On Tue, 19 May 2020 14:27:40 GMT, Ajit Ghaisas wrote: >> Correct :) > > @kevinrushforth brought to my notice that there is a PR (https://github.com/openjdk/jfx/pull/210) opened for the same > issue by [schelldorfer](https://github.com/schelldorfer). I was not aware of this PR as it did not have 'rfr' label - > which I look for. I picked up this issue from JBS and submitted the solution mentioned in JBS. > I would *NOT* like to step on a new contributor's contribution. > > Now, I see that the original PR has been closed. Once his signed OCA has been recorded, we have two options : > 1. I will integrate with this PR with due attribution given to [schelldorfer](https://github.com/schelldorfer) > OR > 2. I will withdraw my PR without integrating and [schelldorfer](https://github.com/schelldorfer) can reopen and submit > his PR. @aghaisas can you proceed with this one or is there anything required from my side? ------------- PR: https://git.openjdk.java.net/jfx/pull/220 From aghaisas at openjdk.java.net Fri Jun 12 10:31:26 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 12 Jun 2020 10:31:26 GMT Subject: RFR: 8244824: TableView : Incorrect German translation In-Reply-To: References: <1Ll4pNkWqP2G6RYxITJo120MTjcA63Q0CQyLd2wO0Nc=.cb0d61f6-0129-4202-8f82-cd82776397ed@github.com> Message-ID: On Fri, 12 Jun 2020 10:01:52 GMT, Martin Schelldorfer wrote: >> @kevinrushforth brought to my notice that there is a PR (https://github.com/openjdk/jfx/pull/210) opened for the same >> issue by [schelldorfer](https://github.com/schelldorfer). I was not aware of this PR as it did not have 'rfr' label - >> which I look for. I picked up this issue from JBS and submitted the solution mentioned in JBS. >> I would *NOT* like to step on a new contributor's contribution. >> >> Now, I see that the original PR has been closed. Once his signed OCA has been recorded, we have two options : >> 1. I will integrate with this PR with due attribution given to [schelldorfer](https://github.com/schelldorfer) >> OR >> 2. I will withdraw my PR without integrating and [schelldorfer](https://github.com/schelldorfer) can reopen and submit >> his PR. > > @aghaisas can you proceed with this one or is there anything required from my side? I need confirmation from you about which option you prefer (See my last comment above). @kevinrushforth also has asked the same question in his last comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/220 From pbansal at openjdk.java.net Fri Jun 12 11:58:12 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 12 Jun 2020 11:58:12 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Fri, 12 Jun 2020 05:56:41 GMT, Pankaj Bansal wrote: >> Here is the result on Ubuntu 20.04 with the latest changes: >> >> ![image](https://user-images.githubusercontent.com/30704286/84271590-abdea180-ab02-11ea-9d2d-dbca39755db0.png) >> >> Some tests seems intermittent. > > I have run the test on OL82 on updated code. Following are the results. I will rerun this on Ubuntu 18.04 and get back > with the results OL82 src="https://user-images.githubusercontent.com/6153953/84469824-918dfa80-ac9f-11ea-9494-36208798312a.png"> I ran the systemTests on OL8.2 using gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test. Following are the results OL82 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Fri Jun 12 12:34:09 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 12:34:09 GMT Subject: RFR: 8244824: TableView : Incorrect German translation In-Reply-To: References: Message-ID: On Fri, 15 May 2020 06:49:04 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8244824 > > Fix : As simple as it gets !!! Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/220 From jvos at openjdk.java.net Fri Jun 12 12:40:06 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 12 Jun 2020 12:40:06 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 13:26:33 GMT, Johan Vos wrote: >> Interestingly enough, I don't see a crash due to the 0 character, but I am seeing some new assertion warnings expecting >> `length >= 0` even in cases where there isn't a 0 character. > > I saw that assertion as well, but that can come from cases where empty TextRun instances are used (start == end). In > that case, the length is 0, which pango considers silly, but it won't crash on that (the content array is never > examined in that case) the crash with 0 is gone with the second patch indeed (1 str per Run), which might be a consequence of doing strlen calculations before we send content down to the pango lib ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From jvos at openjdk.java.net Fri Jun 12 13:07:26 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 12 Jun 2020 13:07:26 GMT Subject: [Rev 01] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 23:28:41 GMT, Phil Race wrote: >> I should add that this is without any attempt to filter out `0` chars. Both `UnicodeTextTest` and `UnicodeTextTest2` >> run correctly with no crashes and no assertions when I comment out the (ineffective) loop checking for 0 and set `start >> = str` leaving everything else as you have it in the current PR. Loading https://gluonhq.com/ in WebView works, too. > > I agree. the text array is now the subset for the run, so effectively run.getStart() should be zero, > so there should be no need for that call. This probably looks OK when there is one run not otherwise. You're both correct. I simplified it. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Fri Jun 12 13:10:08 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 13:10:08 GMT Subject: [Rev 01] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 12:37:01 GMT, Johan Vos wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 140: >> >>> 139: runUtf8.put(run, str); >>> 140: if (check(str, "Failed allocating UTF-8 buffer.", context, desc, attrList)) { >>> 141: return; >> >> Did you really mean to store the run in the map before checking if str is null ? > > I'm not sure what should happen if str is null. Do we want to be able to retry later? In that case, we shouldn't store > it in the map. But if it is fatal, and seems to indicate a problem with rtext (e.g. too big?), so in that case it might > not be worth retrying. If `str` is null, you would end up retrying it anyway, since `Map::get` will return `null` the next time (if there is a next time). Also, I think the dispose method might then crash trying to free a null pointer. So I think Phil is right and that you should not add the `str` to the `Map` if it is null. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From jvos at openjdk.java.net Fri Jun 12 12:52:39 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 12 Jun 2020 12:52:39 GMT Subject: [Rev 01] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: process reviewer comments: start == str check on 0 char not needed anymore ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/249/files - new: https://git.openjdk.java.net/jfx/pull/249/files/d345c744..998f55c6 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/249/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/249/webrev.00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/249/head:pull/249 PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Fri Jun 12 13:25:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 13:25:43 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 18:08:18 GMT, Phil Race wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > Instead of a space you could use a ZWNJ U+FEFF. Because that is also the endian-ness > mark, Unicode actually prefers you now to use U+2060 but you need to make sure these > are processed correctly by pango. Unlike a space they should have no rendering effect - not even an advance. Once you address the question of storing a null value in the Map, the only remaining question I have is whether to use a LinkedHashMap instead of an ordinary HashMap. In general, I like the predictability of a LinkedHashMap for maps that are iterated, but in this case, I don't feel strongly about it one way or the other. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From github.com+3197675+abhinayagarwal at openjdk.java.net Fri Jun 12 13:41:18 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Fri, 12 Jun 2020 13:41:18 GMT Subject: [Rev 03] RFR: 8245053: Keyboard doesn't show when TextInputControl has focus In-Reply-To: References: Message-ID: On Fri, 29 May 2020 16:48:29 GMT, Johan Vos wrote: >> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo: dispose should remove event handler > > worth discussing the case were a TextInput is the only control. @mipastgt The issue happens because of the focus listener. With this PR, we introduce `mouseEventListener` to show the Keyboard on `MOUSE_CLICKED` event. Therefore, the issue brought up by your previous comment should be resolved by updating the `focusChangeListener` to: private final ChangeListener focusChangeListener = (observable, wasFocused, isFocused) -> { if (wasFocused && !isFocused) { hideSoftwareKeyboard(); } }; We should most probably also introduce an API for showing the keyboard as available on both iOS and Android platforms :) Thoughts? ------------- PR: https://git.openjdk.java.net/jfx/pull/219 From pbansal at openjdk.java.net Fri Jun 12 12:51:51 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 12 Jun 2020 12:51:51 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Fri, 12 Jun 2020 11:55:47 GMT, Pankaj Bansal wrote: >> I have run the test on OL82 on updated code. Following are the results. I will rerun this on Ubuntu 18.04 and get back >> with the results OL82> src="https://user-images.githubusercontent.com/6153953/84469824-918dfa80-ac9f-11ea-9494-36208798312a.png"> > > I ran the systemTests on OL8.2 using > gradle -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest > :systemTests:test. Following are the results OL82 src="https://user-images.githubusercontent.com/6153953/84500229-bdc26f00-acd1-11ea-8d69-2ac3812db636.png"> After the latest commit on June 10, this is not building for me on my Ubuntu 18.04. I am attaching the build log for reference. [build.log](https://github.com/openjdk/jfx/files/4770864/build.log) ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From jvos at openjdk.java.net Fri Jun 12 12:40:06 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 12 Jun 2020 12:40:06 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 22:59:04 GMT, Phil Race wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/PangoGlyphLayout.java line 140: > >> 139: runUtf8.put(run, str); >> 140: if (check(str, "Failed allocating UTF-8 buffer.", context, desc, attrList)) { >> 141: return; > > Did you really mean to store the run in the map before checking if str is null ? I'm not sure what should happen if str is null. Do we want to be able to retry later? In that case, we shouldn't store it in the map. But if it is fatal, and seems to indicate a problem with rtext (e.g. too big?), so in that case it might not be worth retrying. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From aghaisas at openjdk.java.net Fri Jun 12 12:50:27 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 12 Jun 2020 12:50:27 GMT Subject: [Integrated] RFR: 8244824: TableView : Incorrect German translation In-Reply-To: References: Message-ID: On Fri, 15 May 2020 06:49:04 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8244824 > > Fix : As simple as it gets !!! This pull request has now been integrated. Changeset: b2008913 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/b2008913 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8244824: TableView : Incorrect German translation Co-authored-by: Martin Schelldorfer Reviewed-by: fastegal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/220 From tsayao at openjdk.java.net Fri Jun 12 14:10:12 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 12 Jun 2020 14:10:12 GMT Subject: [Rev 56] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix compilation on 18.04 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/ad8823de..aeff508e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.56 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.55-56 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Fri Jun 12 14:10:12 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 12 Jun 2020 14:10:12 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Fri, 12 Jun 2020 12:49:42 GMT, Pankaj Bansal wrote: > After the latest commit on June 10, this is not building for me on my Ubuntu 18.04. I am attaching the build log for > reference. [build.log](https://github.com/openjdk/jfx/files/4770864/build.log) It's now fixed. I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). But that does not seem to work on 18.04, so I removed it. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Fri Jun 12 14:10:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 14:10:33 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Fri, 12 Jun 2020 13:49:23 GMT, Thiago Milczarek Sayao wrote: > I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). > But that does not seem to work on 18.04, so I removed it. Good. I was going to ask you about that, so I'm happy to see it gone. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+6719843+schelldorfer at openjdk.java.net Fri Jun 12 11:51:34 2020 From: github.com+6719843+schelldorfer at openjdk.java.net (Martin Schelldorfer) Date: Fri, 12 Jun 2020 11:51:34 GMT Subject: RFR: 8244824: TableView : Incorrect German translation In-Reply-To: References: <1Ll4pNkWqP2G6RYxITJo120MTjcA63Q0CQyLd2wO0Nc=.cb0d61f6-0129-4202-8f82-cd82776397ed@github.com> Message-ID: On Fri, 12 Jun 2020 10:29:08 GMT, Ajit Ghaisas wrote: >> @aghaisas can you proceed with this one or is there anything required from my side? > > I need confirmation from you about which option you prefer (See my last comment above). @kevinrushforth also has asked > the same question in his last comment. let's do option 1 ------------- PR: https://git.openjdk.java.net/jfx/pull/220 From tsayao at openjdk.java.net Fri Jun 12 13:45:13 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 12 Jun 2020 13:45:13 GMT Subject: [Rev 55] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: - Merge branch 'master' into jdk_8236651 - Merge pull request #10 from openjdk/master Update from master - Limit GTK on 3.8 - Limit GTK on 3.18 (Ubuntu 16.04) - Forgot a g_print - Fix build with merged linux.gradle - Merge branch 'master' into jdk_8236651 - Merge pull request #9 from openjdk/master Merge from upstream - Fix window position bug - Rename flag to javafx.gtk.experimental - ... and 10 more: https://git.openjdk.java.net/jfx/compare/9f50e9ca...ad8823de ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/2700f6fb..ad8823de Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.55 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.54-55 Stats: 14139 lines in 267 files changed: 8389 ins; 4633 del; 1117 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Fri Jun 12 14:27:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 14:27:40 GMT Subject: [Rev 01] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 14:16:06 GMT, Johan Vos wrote: >> If `str` is null, you would end up retrying it anyway, since `Map::get` will return `null` the next time (if there is a >> next time). Also, I think the dispose method might then crash trying to free a null pointer. So I think Phil is right >> and that you should not add the `str` to the `Map` if it is null. > > I don't think it will be `null` but it will be `0` in which case it is stored in the `Map` > The only reason the str == null is then that we never tried to convert the Java chars to utf8, unless I'm missing a > case? Oh, right. It will be a Long 0, not null. If you store it you will still have the problem I mentioned with dispose unless you add back in the `str != 0` check. And you would need a check for `str != 0` in the layout method so that the second time it doesn't treat it as a valid pointer. It might be safer to not store it if 0, which matches the current behavior? ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From jvos at openjdk.java.net Fri Jun 12 15:01:36 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 12 Jun 2020 15:01:36 GMT Subject: [Rev 02] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 14:25:25 GMT, Kevin Rushforth wrote: >> I don't think it will be `null` but it will be `0` in which case it is stored in the `Map` >> The only reason the str == null is then that we never tried to convert the Java chars to utf8, unless I'm missing a >> case? > > Oh, right. It will be a Long 0, not null. If you store it you will still have the problem I mentioned with dispose > unless you add back in the `str != 0` check. And you would need a check for `str != 0` in the layout method so that the > second time it doesn't treat it as a valid pointer. It might be safer to not store it if 0, which matches the current > behavior? That makes sense indeed. For the dispose call, a valid pointer is required. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From jvos at openjdk.java.net Fri Jun 12 15:01:35 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 12 Jun 2020 15:01:35 GMT Subject: [Rev 02] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: use LinkedHashMap instead of HashMap Only store the pointer to the utf8 string if its creation was successful ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/249/files - new: https://git.openjdk.java.net/jfx/pull/249/files/998f55c6..0d6e9093 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/249/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/249/webrev.01-02 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/249/head:pull/249 PR: https://git.openjdk.java.net/jfx/pull/249 From jvos at openjdk.java.net Fri Jun 12 14:18:24 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 12 Jun 2020 14:18:24 GMT Subject: [Rev 01] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 13:07:53 GMT, Kevin Rushforth wrote: >> I'm not sure what should happen if str is null. Do we want to be able to retry later? In that case, we shouldn't store >> it in the map. But if it is fatal, and seems to indicate a problem with rtext (e.g. too big?), so in that case it might >> not be worth retrying. > > If `str` is null, you would end up retrying it anyway, since `Map::get` will return `null` the next time (if there is a > next time). Also, I think the dispose method might then crash trying to free a null pointer. So I think Phil is right > and that you should not add the `str` to the `Map` if it is null. I don't think it will be `null` but it will be `0` in which case it is stored in the `Map` The only reason the str == null is then that we never tried to convert the Java chars to utf8, unless I'm missing a case? ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From github.com+7450507+fthevenet at openjdk.java.net Fri Jun 12 15:10:28 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 12 Jun 2020 15:10:28 GMT Subject: [Rev 06] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Revert changes to import statements ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/1fb04e56..0642096a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.05-06 Stats: 112 lines in 1 file changed: 79 ins; 28 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+10960818+Schmidor at openjdk.java.net Fri Jun 12 16:33:55 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Fri, 12 Jun 2020 16:33:55 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% Message-ID: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared rendering. The changes were already proposed by the submitter in JBS-8220484. OCA is signed and send. ------------- Commit messages: - 8220484: calculate buffer size of JFXPanel#createResizePixelBuffer as EmbeddedScene#getPixels does Changes: https://git.openjdk.java.net/jfx/pull/246/files Webrev: https://webrevs.openjdk.java.net/jfx/246/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8220484 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/246.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/246/head:pull/246 PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Fri Jun 12 16:33:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 16:33:55 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% In-Reply-To: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: <7RNBv7iGfqy_SssrxaTtFsYmDDl5oPlLnEuZAYZHIFI=.2c28b182-20c2-443f-ae4d-6afc96982c48@github.com> On Wed, 3 Jun 2020 15:46:36 GMT, Oliver Schmidtmer wrote: > In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and > EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared > rendering. The changes were already proposed by the submitter in JBS-8220484. > > OCA is signed and send. @Schmidor in general, we don't use the `/issue` command to identify other issues that happen to be fixed by a commit. Rather, if they are the same bug, or if one is caused by the other, we would closed the other one as a duplicate. This seems like a good thing for me to add to the [CONTRIBUTING](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) guidelines. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+7450507+fthevenet at openjdk.java.net Fri Jun 12 18:05:44 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 12 Jun 2020 18:05:44 GMT Subject: [Rev 07] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Changed tile walking logic ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/0642096a..8f0c2d22 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.07 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.06-07 Stats: 80 lines in 1 file changed: 23 ins; 17 del; 40 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Fri Jun 12 18:20:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 18:20:34 GMT Subject: RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 13:23:29 GMT, Kevin Rushforth wrote: >> Instead of a space you could use a ZWNJ U+FEFF. Because that is also the endian-ness >> mark, Unicode actually prefers you now to use U+2060 but you need to make sure these >> are processed correctly by pango. Unlike a space they should have no rendering effect - not even an advance. > > Once you address the question of storing a null value in the Map, the only remaining question I have is whether to use > a LinkedHashMap instead of an ordinary HashMap. In general, I like the predictability of a LinkedHashMap for maps that > are iterated, but in this case, I don't feel strongly about it one way or the other. The fix looks good now. As for the test, even if StubFont were updated to provide a real font, the StubToolkit doesn't load Prism (so none of the text rendering code is exercised). Do you think you could instead add a simple test or two in the system tests project instead (maybe one testing UTF16 chars and one with a 0 char)? ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From prr at openjdk.java.net Fri Jun 12 18:31:04 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 12 Jun 2020 18:31:04 GMT Subject: [Rev 02] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 14:49:50 GMT, Johan Vos wrote: >> Oh, right. It will be a Long 0, not null. If you store it you will still have the problem I mentioned with dispose >> unless you add back in the `str != 0` check. And you would need a check for `str != 0` in the layout method so that the >> second time it doesn't treat it as a valid pointer. It might be safer to not store it if 0, which matches the current >> behavior? > > That makes sense indeed. For the dispose call, a valid pointer is required. I wasn't completely sure what the idea was, which is why I phrased it as a question :-) ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From prr at openjdk.java.net Fri Jun 12 18:31:04 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 12 Jun 2020 18:31:04 GMT Subject: [Rev 02] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 13:05:03 GMT, Johan Vos wrote: >> I agree. the text array is now the subset for the run, so effectively run.getStart() should be zero, >> so there should be no need for that call. This probably looks OK when there is one run not otherwise. > > You're both correct. I simplified it. Looks good now. ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From prr at openjdk.java.net Fri Jun 12 18:31:03 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 12 Jun 2020 18:31:03 GMT Subject: [Rev 02] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 15:01:35 GMT, Johan Vos wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > use LinkedHashMap instead of HashMap > Only store the pointer to the utf8 string if its creation was successful Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From tsayao at openjdk.java.net Fri Jun 12 19:42:06 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 12 Jun 2020 19:42:06 GMT Subject: [Rev 57] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Small Adjustments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/aeff508e..2f3bdb2c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.57 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.56-57 Stats: 40 lines in 3 files changed: 35 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Fri Jun 12 20:22:51 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 12 Jun 2020 20:22:51 GMT Subject: [Rev 58] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Revert to all events mask ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/2f3bdb2c..e373848e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.58 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.57-58 Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Fri Jun 12 20:26:07 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 12 Jun 2020 20:26:07 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Fri, 12 Jun 2020 13:51:58 GMT, Kevin Rushforth wrote: >>> After the latest commit on June 10, this is not building for me on my Ubuntu 18.04. I am attaching the build log for >>> reference. [build.log](https://github.com/openjdk/jfx/files/4770864/build.log) >> >> It's now fixed. I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > >> 3.8 were used). But that does not seem to work on 18.04, so I removed it. > >> I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). >> But that does not seem to work on 18.04, so I removed it. > > Good. I was going to ask you about that, so I'm happy to see it gone. I have investigated the Tab Pane Drag Test and it works manually. import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Tab; import javafx.scene.control.TabPane; import javafx.stage.Stage; public class Test extends Application { @Override public void start(Stage stage) { TabPane tabPane = new TabPane(); tabPane.setTabDragPolicy(TabPane.TabDragPolicy.REORDER); Scene scene = new Scene(tabPane, 800, 600); stage.setScene(scene); Tab tab1 = new Tab("Tab1"); Tab tab2 = new Tab("Tab2"); tabPane.getTabs().addAll(tab1, tab2); stage.setAlwaysOnTop(true); stage.show(); } public static class Main { public static void main(String[] args) { Application.launch(Test.class, args); } } } It also works if I switch back to GDK Events instead of Gtk Signals. But it is a drag test, by experience they don't work well on Robot. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From kcr at openjdk.java.net Fri Jun 12 20:45:30 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 20:45:30 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% In-Reply-To: <7RNBv7iGfqy_SssrxaTtFsYmDDl5oPlLnEuZAYZHIFI=.2c28b182-20c2-443f-ae4d-6afc96982c48@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> <7RNBv7iGfqy_SssrxaTtFsYmDDl5oPlLnEuZAYZHIFI=.2c28b182-20c2-443f-ae4d-6afc96982c48@github.com> Message-ID: On Wed, 3 Jun 2020 16:07:24 GMT, Kevin Rushforth wrote: >> In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and >> EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared >> rendering. The changes were already proposed by the submitter in JBS-8220484. >> >> OCA is signed and send. > > @Schmidor in general, we don't use the `/issue` command to identify other issues that happen to be fixed by a commit. > Rather, if they are the same bug, or if one is caused by the other, we would closed the other one as a duplicate. This > seems like a good thing for me to add to the [CONTRIBUTING](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) > guidelines. Even though this is a seemingly simple fix, I'd like @prsadhuk to also review it. @Schmidor Can you do the following? 1. Provide an evaluation as to why this is the correct fix, and indicate what testing you have done to ensure no regressions in behavior. Changes to rounding in width and height computations tend to be trickier than they might seem. 2. Provide a test as part of this fix. Ideally, this would be an automated test, in the system tests project (under `tests/system`), and should set the `glass.win.uiScale` system property to `1.25` before running the test. There are a few examples you can follow under tests/system that create a JFrame with a JFXPanel and use Robot to verify the rendered image. If it turns out that an automated is not feasible, a manual test would be an acceptable alternative. 3. Enter the `/issue remove 8230007` command to remove that issue from this PR. I've already closed [JDK-8230007](https://bugs.openjdk.java.net/browse/JDK-8230007) in JBS as a duplicate. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+10960818+Schmidor at openjdk.java.net Fri Jun 12 21:14:41 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Fri, 12 Jun 2020 21:14:41 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> <7RNBv7iGfqy_SssrxaTtFsYmDDl5oPlLnEuZAYZHIFI=.2c28b182-20c2-443f-ae4d-6afc96982c48@github.com> Message-ID: <7Okv-YbYsEbiNU6CH5BSDD0ISK0UlkDIB1nlUFYeOnU=.3c2b8095-18ba-4f5c-8e78-e88b9660b0dc@github.com> On Fri, 12 Jun 2020 20:43:18 GMT, Kevin Rushforth wrote: >> @Schmidor in general, we don't use the `/issue` command to identify other issues that happen to be fixed by a commit. >> Rather, if they are the same bug, or if one is caused by the other, we would closed the other one as a duplicate. This >> seems like a good thing for me to add to the [CONTRIBUTING](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) >> guidelines. > > Even though this is a seemingly simple fix, I'd like @prsadhuk to also review it. > > @Schmidor Can you do the following? > > 1. Provide an evaluation as to why this is the correct fix, and indicate what testing you have done to ensure no > regressions in behavior. Changes to rounding in width and height computations tend to be trickier than they might seem. > 2. Provide a test as part of this fix. Ideally, this would be an automated test, in the system tests project (under > `tests/system`), and should set the `glass.win.uiScale` system property to `1.25` before running the test. There are a > few examples you can follow under tests/system that create a JFrame with a JFXPanel and use Robot to verify the > rendered image. If it turns out that an automated is not feasible, a manual test would be an acceptable alternative. 3. > Enter the `/issue remove 8230007` command to remove that issue from this PR. I've already closed > [JDK-8230007](https://bugs.openjdk.java.net/browse/JDK-8230007) in JBS as a duplicate. I'll look into a more detailed description with code references and try to create a test. The backbuffer of the Stage is created with Math.round(baseSize*uiScale) and for Swing the DataBuffer is referenced into an BufferdImage, where the bounds are calculated with Math.ceil(baseSize*uiScale). So when the base-width is 101px and uiscale is 1.25, the unrounded size is 126.25. The real buffer-width is then 126px, but rendered in swing using 127px. So there is an offset of one pixel per line and the resulting image is skewed. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Fri Jun 12 21:41:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 21:41:23 GMT Subject: [Rev 02] RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar In-Reply-To: References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> Message-ID: On Mon, 18 May 2020 05:52:21 GMT, Ajit Ghaisas wrote: >> Issue : >> https://bugs.openjdk.java.net/browse/JDK-8244418 >> >> Root Cause : >> Incorrect assumption about menu list size. >> >> Fix : >> Added check for empty menu list before trying to access it. >> >> Test : >> Added a unit test that fails before fix and passes after it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > review fixes and test addition The fix looks good aside from the one added method used for testing. The test looks good as well. I confirm that it fails without your fix and passes with your fix. modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 764: > 763: void setFocusedIndex(int index) { > 764: this.setFocusedMenuIndex(0); > 765: } Shouldn't this be `this.setFocusedMenuIndex(index)`? The only reason this isn't causing problems is that the test you added never calls it with anything other than 0. Also, the naming of this method is a bit confusing. I might recommend calling it `test_setFocusedMenuIndex`, or else just change the private `setFocusedMenuIndex` method to be package-scope. Either way adding a comment indicating that it is used for testing purposes seems a good idea (if you keep this method then the comment could say that it is only for testing purposes; if you make `setFocusedMenuIndex` package-scope then you could say that it is package scope because it is used for testing). modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 476: > 475: focusedMenuIndex = (index >= -1 && index < getSkinnable().getMenus().size())? index : -1; > 476: focusedMenu = (focusedMenuIndex != -1)? getSkinnable().getMenus().get(index) : null; > 477: Minor: we usually put a space before the `?` (I probably wouldn't have mentioned it, but there is a substantive change you need to make anyway). ------------- PR: https://git.openjdk.java.net/jfx/pull/216 From kcr at openjdk.java.net Fri Jun 12 22:03:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 22:03:58 GMT Subject: [Rev 04] RFR: 8218973: SVG with masking is not rendering image with mask effect In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 20:47:12 GMT, Kevin Rushforth wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unnecessery Ceil Functions > > The code looks good (with a couple minor formatting issues). > > All of the onscreen testing I did looks good on Windows. I'd like to test it on Mac as well. > > There is an issue with printing in the case of Hi-DPI scaling, which is what I run by default on Windows. The gradient > texture appears to be scaled incorrectly (as if the scale was applied more than once). If I force scaling to 1 with > `-Dglass.win.uiScale=1` then it prints correctly. It behaves the same on Mac with a Retina display as it does on Windows with Hi-DPI scaling. The gradient doesn't appear to be scaled correctly when printing. It's fine with on-screen rendering (with both HW and SW pipeline). ------------- PR: https://git.openjdk.java.net/jfx/pull/213 From kcr at openjdk.java.net Fri Jun 12 22:37:33 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 22:37:33 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com> Message-ID: On Fri, 5 Jun 2020 07:02:57 GMT, Jesper Skov wrote: >> Here are a few preliminary comments: > > Can I do anything to expedite the landing of this - before it gets obsoleted? :) Finally getting back to this. The build logic changes look good. So does the new "readme" file. I tested it on Windows and it does what I expect, including (importantly) not causing any behavioral changes by default. I'll test on Mac and Linux and then finish my review. ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From kcr at openjdk.java.net Fri Jun 12 23:18:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 23:18:29 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: <7qp6x1uyJOOOZx7VVl9g0eCXtBsC1o4Y8qguGbrp4QY=.027df68b-7a82-4b12-a444-0f6b6f398e00@github.com> Message-ID: <4MPS_-NozUUIRvHdmMdBDKPlBcaeqj4vH130Fem9kPk=.d2553b63-5654-4e42-b8d9-17f08d5569fd@github.com> On Fri, 1 May 2020 16:01:28 GMT, Jesper Skov wrote: >> build.gradle line 3391: >> >>> 3390: doFirst { >>> 3391: if (IS_STUB_RUNTIME_OPENJFX) { >>> 3392: println "********************************************************" >> >> Perhaps this should be inside the `if (!IS_COMPILE_WEBKIT)` ? > > I assume you mean like this: > ` > if (!IS_COMPILE_WEBKIT) { > if (IS_STUB_RUNTIME_OPENJFX) { > println ... > } else { > println ... > } > } > ` > I do not like the additional indentation level, so I have left it as is. > > The semantics should be the same, as long as no one use stubs *and* compile webkit. > Which should maybe rather cause a build exception? > > But it is not something I feel strongly for, so I am happy to change it :) Yes, that's what I was suggesting, but I'm happy with the way it is. ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From kcr at openjdk.java.net Fri Jun 12 23:23:31 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 23:23:31 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov wrote: > I have tested on Linux (Fedora 31) only. > It works as intended (with one test failure due to 15-ea+4 being too old now). > > UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. > But as I could not find anything about it, that section in the documentation may need some love. Tested on all three platforms with / without setting `STUB_RUNTIME_OPENJFX`. All looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/202 From kcr at openjdk.java.net Fri Jun 12 23:28:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Jun 2020 23:28:38 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: <6WGm5-9BdD4Ro6IjsuM6IfUkuzYhF8qLpIf1kschmCs=.b429308b-8cd5-4eb8-baf5-4c1095c0d20e@github.com> On Fri, 12 Jun 2020 23:21:16 GMT, Kevin Rushforth wrote: >> I have tested on Linux (Fedora 31) only. >> It works as intended (with one test failure due to 15-ea+4 being too old now). >> >> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. >> But as I could not find anything about it, that section in the documentation may need some love. > > Tested on all three platforms with / without setting `STUB_RUNTIME_OPENJFX`. All looks good. Pending review from @johanvos ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From github.com+7450507+fthevenet at openjdk.java.net Sat Jun 13 09:06:25 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Sat, 13 Jun 2020 09:06:25 GMT Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: <7GU_NwPXRJ2nrv98_OZsDFybV0H9p_S16o1KKHAwl0A=.9473c5f2-3056-4344-a4b4-f2f0dd56da67@github.com> References: <7GU_NwPXRJ2nrv98_OZsDFybV0H9p_S16o1KKHAwl0A=.9473c5f2-3056-4344-a4b4-f2f0dd56da67@github.com> Message-ID: On Sat, 16 May 2020 14:20:10 GMT, Kevin Rushforth wrote: >>> >>> >>> Overall, this looks quite good. In particular the tiled rendering, as implemented by the `renderTile` method, should be >>> reasonably efficient. >>> My only high-level comment is that I'm somewhat skeptical of `computeOptimumTileSize` to determine the size and >>> direction of tiling. I note that in the case of an image that is tiled in both X and Y, there are at most 4 distinct >>> tile sizes if it doesn't fit evenly. In the case where only one of X or Y is tiled, there are at most 2 distinct tile >>> sizes. Here is an example: ``` +-----------+-----------+ . +-------+ >>> | | | . | | >>> | M | M | . | R | >>> | | | . | | >>> +-----------+-----------+ . +-------+ >>> | | | . | | >>> | M | M | . | R | >>> | | | . | | >>> +-----------+-----------+ . +-------+ >>> . . . . >>> +-----------+-----------+ . +-------+ >>> | | | . | | >>> | M | M | . | R | >>> | | | . | | >>> +-----------+-----------+ . +-------+ >>> | B | B | . | C | >>> +-----------+-----------+ . +-------+ >>> ``` >>> >>> Where `M` represents the middle set of tiles each with a size of `tileW x tileH`. `R` is the right hand column of >>> tiles, `B` is bottom row, and `C` is corner. >>> Recognizing this, I wonder if it might be better to always use the maximum tile size, but fill all of the middle tiles >>> of that size first, and then pick up the right and/or bottom edges as needed. This will minimize thrashing (no more >>> than 3 changes of tile size), while avoiding the more complicated logic that tries to keep the tiles all the same size >>> at the cost of smaller tiles, and which has to fall back to using uneven tiles anyway. If you do it this way, there is >>> also no need to have code that switches the order of the inner loop. It will naturally handle that. Either way, I'd >>> like to see some additional system tests that cover all of the cases of X and Y fitting/not-fitting exactly (and if you >>> stick with your current approach, X or Y as the inner loop). I left a couple inline comments as well. >> >> I'll need to think about this a bit more, but maybe a good approach could be to generally adopt your solution, but >> still attempt to see if any of the snapshot's dimension can be divided equally by 2 or 3 (while being less than >> maxTextureSize) , and use that a a tile size. As the number of tiles increases, it become less important to have same >> sized tiles as you demonstrated so using maxTextureSize should be fine. This way we get rid of the inner loop >> direction logic (which I agree is verbose and kind of confusing), and still have a chance to optimize the case where >> tiled snapshots are made up of 4 tiles or less (which I see as being the most frequent use case, in my experience >> anyway). > > That sounds like a promising approach. I have re-written the way we walk through tiles as per the discussion above. It isn't really more concise than the previous iteration but it is probably more straight forward and less surprising. It also handles more cases with the least amount of tile resizing than the previous code, so I think it is a clear improvement. What I'm not terribly happy with is the variable names: I must admit I quickly ran out of idea for naming the various instances of tiles sizes and offsets, so I reused the "M, R, B, C" terminology used above. However I'm worried it might seem a bit obscure when taken out of the context of this discussion, so if anyone have better names to suggest, I'd be happy to change these. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From fastegal at openjdk.java.net Sat Jun 13 09:08:17 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 13 Jun 2020 09:08:17 GMT Subject: [Rev 02] RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar In-Reply-To: References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> Message-ID: On Fri, 12 Jun 2020 21:17:09 GMT, Kevin Rushforth wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> review fixes and test addition > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 764: > >> 763: void setFocusedIndex(int index) { >> 764: this.setFocusedMenuIndex(0); >> 765: } > > Shouldn't this be `this.setFocusedMenuIndex(index)`? The only reason this isn't causing problems is that the test you > added never calls it with anything other than 0. > Also, the naming of this method is a bit confusing. I might recommend calling it `test_setFocusedMenuIndex`, or else > just change the private `setFocusedMenuIndex` method to be package-scope. Either way adding a comment indicating that > it is used for testing purposes seems a good idea (if you keep this method then the comment could say that it is only > for testing purposes; if you make `setFocusedMenuIndex` package-scope then you could say that it is package scope > because it is used for testing). darn .. overlooked that fixed index .. As to the naming: personally, I hate violation of naming conventions even for test-only methods, so would tend to make setFocusedMenuIndex package and doc as being used for testing as well as internally. We might consider aligning the corresponding methods in the shim (they are also slightly confusing in get/set/FocusedIndex). ------------- PR: https://git.openjdk.java.net/jfx/pull/216 From kcr at openjdk.java.net Sat Jun 13 15:05:16 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 13 Jun 2020 15:05:16 GMT Subject: [Rev 02] RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar In-Reply-To: References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> Message-ID: On Sat, 13 Jun 2020 09:06:01 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 764: >> >>> 763: void setFocusedIndex(int index) { >>> 764: this.setFocusedMenuIndex(0); >>> 765: } >> >> Shouldn't this be `this.setFocusedMenuIndex(index)`? The only reason this isn't causing problems is that the test you >> added never calls it with anything other than 0. >> Also, the naming of this method is a bit confusing. I might recommend calling it `test_setFocusedMenuIndex`, or else >> just change the private `setFocusedMenuIndex` method to be package-scope. Either way adding a comment indicating that >> it is used for testing purposes seems a good idea (if you keep this method then the comment could say that it is only >> for testing purposes; if you make `setFocusedMenuIndex` package-scope then you could say that it is package scope >> because it is used for testing). > > darn .. overlooked that fixed index .. > > As to the naming: personally, I hate violation of naming conventions even for test-only methods, so would tend to make > setFocusedMenuIndex package and doc as being used for testing as well as internally. > We might consider aligning the corresponding methods in the shim (they are also slightly confusing in > get/set/FocusedIndex). Good suggestion. ------------- PR: https://git.openjdk.java.net/jfx/pull/216 From prr at openjdk.java.net Sat Jun 13 15:57:06 2020 From: prr at openjdk.java.net (Phil Race) Date: Sat, 13 Jun 2020 15:57:06 GMT Subject: [Rev 01] RFR: 8208169: can not print selected pages of web page In-Reply-To: <7Z4jiN5_z3SGrGWAqxqMmmIO2EHmzLg6on3gspsjwtA=.6ec5d087-518a-410f-8810-e1450f2a6e5c@github.com> References: <7Z4jiN5_z3SGrGWAqxqMmmIO2EHmzLg6on3gspsjwtA=.6ec5d087-518a-410f-8810-e1450f2a6e5c@github.com> Message-ID: On Mon, 1 Jun 2020 15:37:09 GMT, Bhawesh Choudhary wrote: >> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, >> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing >> pages otherwise print all pages as usual. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > added manual test tests/manual/printing/PrintPageRangeTest.java line 78: > 77: > 78: static final String initialURL = "https://en.wikipedia.org/wiki/Java_version_history"; > 79: Have you tested this when using a system proxy ? And do the webview tests in general use random webpages from the internet ? Why can't we generate some simple local content that we KNOW is 4 pages long. You don't even know that for sure about this page. ------------- PR: https://git.openjdk.java.net/jfx/pull/222 From pbansal at openjdk.java.net Sun Jun 14 06:52:02 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 14 Jun 2020 06:52:02 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Fri, 12 Jun 2020 20:22:12 GMT, Thiago Milczarek Sayao wrote: >>> I had used two compilation parameters to limit Gtk on 3.8 (so it would generate error if any symbol > 3.8 were used). >>> But that does not seem to work on 18.04, so I removed it. >> >> Good. I was going to ask you about that, so I'm happy to see it gone. > > I have investigated the Tab Pane Drag Test and it works manually. > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Tab; > import javafx.scene.control.TabPane; > import javafx.stage.Stage; > > public class Test > extends Application { > > @Override > public void start(Stage stage) { > TabPane tabPane = new TabPane(); > tabPane.setTabDragPolicy(TabPane.TabDragPolicy.REORDER); > Scene scene = new Scene(tabPane, 800, 600); > stage.setScene(scene); > Tab tab1 = new Tab("Tab1"); > Tab tab2 = new Tab("Tab2"); > > tabPane.getTabs().addAll(tab1, tab2); > > > stage.setAlwaysOnTop(true); > stage.show(); > } > > public static class Main { > public static void main(String[] args) { > Application.launch(Test.class, args); > } > } > } > > It also works if I switch back to GDK Events instead of Gtk Signals. But it is a drag test, by experience they don't > work well on Robot. Following are results in Ubuntu 18.04 after fix for tab pane tests. Results_18 04 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From pbansal at openjdk.java.net Sun Jun 14 11:58:00 2020 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Sun, 14 Jun 2020 11:58:00 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Sun, 14 Jun 2020 06:49:42 GMT, Pankaj Bansal wrote: >> I have investigated the Tab Pane Drag Test and it works manually. >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.control.Tab; >> import javafx.scene.control.TabPane; >> import javafx.stage.Stage; >> >> public class Test >> extends Application { >> >> @Override >> public void start(Stage stage) { >> TabPane tabPane = new TabPane(); >> tabPane.setTabDragPolicy(TabPane.TabDragPolicy.REORDER); >> Scene scene = new Scene(tabPane, 800, 600); >> stage.setScene(scene); >> Tab tab1 = new Tab("Tab1"); >> Tab tab2 = new Tab("Tab2"); >> >> tabPane.getTabs().addAll(tab1, tab2); >> >> >> stage.setAlwaysOnTop(true); >> stage.show(); >> } >> >> public static class Main { >> public static void main(String[] args) { >> Application.launch(Test.class, args); >> } >> } >> } >> >> It also works if I switch back to GDK Events instead of Gtk Signals. But it is a drag test, by experience they don't >> work well on Robot. > > Following are results in Ubuntu 18.04 after fix for tab pane tests. > Results_18 04 src="https://user-images.githubusercontent.com/6153953/84587007-3abc2880-ae39-11ea-8b61-0cbb86e4d4b5.png"> This is the result on OL 82 with latest commit OL82 ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From github.com+4208131+bhaweshkc at openjdk.java.net Sun Jun 14 19:13:41 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Sun, 14 Jun 2020 19:13:41 GMT Subject: [Rev 02] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: > Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, > which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing > pages otherwise print all pages as usual. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Replaced webpage with locally generated html content in test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/222/files - new: https://git.openjdk.java.net/jfx/pull/222/files/75a0362f..4d973a33 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/222/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/222/webrev.01-02 Stats: 66 lines in 1 file changed: 21 ins; 32 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/222/head:pull/222 PR: https://git.openjdk.java.net/jfx/pull/222 From github.com+4208131+bhaweshkc at openjdk.java.net Sun Jun 14 19:13:55 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Sun, 14 Jun 2020 19:13:55 GMT Subject: [Rev 02] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: On Thu, 21 May 2020 17:41:46 GMT, Phil Race wrote: >> Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: >> >> Replaced webpage with locally generated html content in test > > looks ok. Approval waiting on a test. @prrace updated test which uses locally generated html content which should be large enough to cover 4 pages. ------------- PR: https://git.openjdk.java.net/jfx/pull/222 From jpereda at openjdk.java.net Sun Jun 14 19:19:15 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 14 Jun 2020 19:19:15 GMT Subject: [Rev 01] RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: Message-ID: > This PR comments out too verbose console logging, as it has been done with some other fprintf calls. > As a follow up of this PR, a custom directive that enables this output if needed can be considered. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Call fprintf only if pulse logging was requested ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/165/files - new: https://git.openjdk.java.net/jfx/pull/165/files/635e4579..34d256da Webrevs: - full: https://webrevs.openjdk.java.net/jfx/165/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/165/webrev.00-01 Stats: 31 lines in 3 files changed: 28 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/165/head:pull/165 PR: https://git.openjdk.java.net/jfx/pull/165 From thangalin at gmail.com Sun Jun 14 23:03:49 2020 From: thangalin at gmail.com (Thangalin) Date: Sun, 14 Jun 2020 16:03:49 -0700 Subject: JavaFX: Synchronize Editor scrollbar with WebView scrollbar Message-ID: Hey list! Am wondering how to go about synchronizing scroll bars between a JavaFX StyleClassedTextArea that uses a VirtualizedScrollPane and a JavaFX WebView instance. A couple of tangentially-related issues have appeared: 1. Scrollbar. The documentation states, "WebView handles mouse and some keyboard events, and manages scrolling automatically, so there's no need to put it into a ScrollPane." The API appears to prevent direct access to the scrollbar, forcing JavaScript contortions while preventing unidirectional binding of scrollbars (that can interject a ratio calculation). 2. Fading. The default behaviour appears to make the scrollbar disappear after a few seconds. Since, in this case, the scrollbars are meant to be synchronized, it would be convenient to disable that behaviour (i.e., always show the vertical scrollbar). Both these issues would be reasonably easy to solve if the scrollbar property for the WebView could be obtained. Here's a snippet showing the editor beside the preview: public class ScrollSync extends Application { private final StyleClassedTextArea mEditor = new StyleClassedTextArea( false ); private final VirtualizedScrollPane mEditorScrollPane = new VirtualizedScrollPane<>( mEditor ); private final WebView mWebView = new WebView(); private final String mHtml = "%CONTENT%"; public static void main( final String[] args ) { launch( args ); } @Override public void start( final Stage stage ) { mEditorScrollPane.setVbarPolicy( ScrollPane.ScrollBarPolicy.ALWAYS ); mEditor.textProperty().addListener( ( observable, oldValue, newValue ) -> { mWebView.getEngine().loadContent( mHtml.replace( "%CONTENT%", newValue ) ); } ); final SplitPane splitPane = new SplitPane( mEditorScrollPane, mWebView ); stage.setScene( new Scene( splitPane, 800, 400 ) ); stage.show(); } } In the screenshot, notice that the WebView can contain images, which affects the relative heights of the scrollbars; also notice that the scrollbar has faded out from the WebView: https://i.stack.imgur.com/QJFnY.png Although the cursor and scrollbar are positioned at the bottom of the text editor, the WebView remains scrolled to the top, rather than the bottom. I am wondering: (a) Without resorting to using JavaScript's scrollTo functions, how would you ensure that the scrollbar from WebView reflects the relative vertical scrolling offset of the editor pane? (b) How would you make sure the WebView scrollbar is always visible? (I tried many CSS variations, but none would eliminate the fade out animation.) The editor's architecture being implemented resembles the "Example Processing Combination" panel in the following figure: https://i.stack.imgur.com/s1QwK.png There's no simple way for the editor to communicate with the resulting HTML displayed by WebView, which makes passing values that reflect the editor's scrollbar into a JavaScript function non-trivial (because the text could be processed in many ways prior to reaching the WebView). A unidirectional binding at the "pane" would avoid the architectural separation issue altogether, alleviating the need for an inter-pane communication protocol. Thank you! TX From tsayao at openjdk.java.net Mon Jun 15 00:12:10 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 15 Jun 2020 00:12:10 GMT Subject: [Rev 59] RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> Message-ID: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix mouse click event ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/77/files - new: https://git.openjdk.java.net/jfx/pull/77/files/e373848e..ffe3c36e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/77/webrev.59 - incr: https://webrevs.openjdk.java.net/jfx/77/webrev.58-59 Stats: 18 lines in 2 files changed: 6 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx/pull/77 From tsayao at openjdk.java.net Mon Jun 15 00:12:10 2020 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 15 Jun 2020 00:12:10 GMT Subject: RFR: 8236651: Simplify and update glass gtk backend In-Reply-To: References: <18qiCT5oGbDR-HA0CvK7izwp1QwkAcJXmqyQ3mPlCo8=.57178071-ad2a-47cd-8a92-6cc758704223@github.com> <31X4pHGnuhexI5Rz9Y8afMrdFl0pfNPKp9nMYMNcG50=.1f068b3f-0901-43f3-a2d1-8a12aa18b040@github.com> <3sbI8nmc6ExsBiXVLTLxw4NWOJMATH4TQty2VaJRaUE=.88892ec3-9640-4786-b237-73f2f553069e@github.com> <1rDuK8OxEZvUNDWVq-Lda5WPfD54KRsICqP_mijyxao=.79fea868-b311-4c3a-8fd6-80cc4c99d473@github.com> <_y4vk8gAqpxSB4yMJ-XkLvNejR7rsqF8RbW3pg6Pe_E=.6176c026-2bd9-4541-8f8b-035cac2d3758@ github.com> Message-ID: On Sun, 14 Jun 2020 11:55:45 GMT, Pankaj Bansal wrote: >> Following are results in Ubuntu 18.04 after fix for tab pane tests. >> Results_18 04> src="https://user-images.githubusercontent.com/6153953/84587007-3abc2880-ae39-11ea-8b61-0cbb86e4d4b5.png"> > > This is the result on OL 82 with latest commit > OL82 src="https://user-images.githubusercontent.com/6153953/84592508-d82c5200-ae63-11ea-87d3-7f55671ed302.png"> @pankaj-bansal Sorry for commiting again. Now the Tab Pane test works properly. ------------- PR: https://git.openjdk.java.net/jfx/pull/77 From ajoseph at openjdk.java.net Mon Jun 15 04:52:51 2020 From: ajoseph at openjdk.java.net (Arun Joseph) Date: Mon, 15 Jun 2020 04:52:51 GMT Subject: [Rev 02] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: On Sun, 14 Jun 2020 19:13:41 GMT, Bhawesh Choudhary wrote: >> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, >> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing >> pages otherwise print all pages as usual. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Replaced webpage with locally generated html content in test tests/manual/printing/PrintPageRangeTest.java line 80: > 79: > 80: static final String initialURL = "https://en.wikipedia.org/wiki/Java_version_history"; > 81: initialURL is no longer required ------------- PR: https://git.openjdk.java.net/jfx/pull/222 From github.com+4208131+bhaweshkc at openjdk.java.net Mon Jun 15 05:22:48 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Mon, 15 Jun 2020 05:22:48 GMT Subject: [Rev 03] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: > Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, > which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing > pages otherwise print all pages as usual. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: cleanup unused variable ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/222/files - new: https://git.openjdk.java.net/jfx/pull/222/files/4d973a33..717dac0f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/222/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/222/webrev.02-03 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/222/head:pull/222 PR: https://git.openjdk.java.net/jfx/pull/222 From rlichten at openjdk.java.net Mon Jun 15 05:38:45 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 15 Jun 2020 05:38:45 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: <4I58IIqTX2S0zeE9j7bhrP7RPdu1Ei1x0sz40K2VaWU=.e33d173d-b104-45ca-b772-721e722c333b@github.com> References: <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com> <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com> <6WhyH_3NIHMKxVw-xsTv6jAsSb2njDPkaaN Vz64y60E=.352fb913-33e4-40ee-a28b-9da54e7095c8@github.com> <4I58IIqTX2S0zeE9j7bhrP7RPdu1Ei1x0sz40K2VaWU=.e33d173d-b104-45ca-b772-721e722c333b@github.com> Message-ID: On Thu, 11 Jun 2020 14:39:08 GMT, Jeanette Winzenburg wrote: > good direction, I think :) > > Didn't look too closely, just added your changes and run the tests - getting a StringIndexOutofBounds at > TextInputControlTest.test_jdk_8171229_replaceText(TextInputControlTest.java:1862) (no failing test because the > uncaughtException handler not redirected). Could you check please? Will check this week. ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From arapte at openjdk.java.net Mon Jun 15 06:27:55 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Jun 2020 06:27:55 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 12:25:04 GMT, Jeanette Winzenburg wrote: > ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the > listView and incorrect update of internal state (see bug report for details) > Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView > state when needed. > Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior > before/after. modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListCellSkin.java line 100: > 99: double fixedCellSize = getFixedCellSize(); > 100: if (fixedCellSize > 0) { > 101: return fixedCellSize; These compute methods get invoked multiple times during each layout pass(10s of times). Fetching the fixed cell size on each call to these methods seems to be costly and repeated operation compared to previous boolean check. I think we should keep the previous way of handling it: registering the change listener to `listView.fixedCellSizeProperty()`. ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From fastegal at openjdk.java.net Mon Jun 15 07:51:39 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 15 Jun 2020 07:51:39 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 06:25:36 GMT, Ambarish Rapte wrote: >> ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the >> listView and incorrect update of internal state (see bug report for details) >> Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView >> state when needed. >> Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior >> before/after. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListCellSkin.java line 100: > >> 99: double fixedCellSize = getFixedCellSize(); >> 100: if (fixedCellSize > 0) { >> 101: return fixedCellSize; > > These compute methods get invoked multiple times during each layout pass(10s of times). Fetching the fixed cell size on > each call to these methods seems to be repeated and costly operation compared to previous boolean check. I think we > should keep the previous way of handling it: registering the change listener to `listView.fixedCellSizeProperty()`. ehh .. last time I did such micro-optimization was in the 80ies of last century ;) Are there any performance measurements anywhere to demonstrate the impact? ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From r.lichtenberger at gmail.com Mon Jun 15 08:12:19 2020 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 15 Jun 2020 10:12:19 +0200 Subject: Build Problems on Linux Message-ID: I haven't built in a while but today I pulled the current master branch and tried to build OpenJFX. Unfortunately, the task :graphics:ccLinuxGlassGlassgtk2 fails like this: :graphics:ccLinuxGlassGlassgtk2 (Thread[Daemon worker Thread 2,5,main]) started. Starting process 'command 'gcc''. Working directory: /home/rli/PWEs/jfx/modules/javafx.graphics Command: gcc -fno-strict-aliasing -fPIC -fno-omit-frame-pointer -fstack-protector -Wextra -Wall -Wformat-security -Wno-unused -Wno-parentheses -Werror=implicit-function-declaration -Werror=trampolines -I/usr/java/jdk-12.0.2+10/include -I/usr/java/jdk-12.0.2+10/include/linux -c -ffunction-sections -fdata-sections -O2 -DNDEBUG -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/atk-1.0 -pthread -I/home/rli/PWEs/jfx/modules/javafx.graphics/build/gensrc/headers/javafx.graphics -o /home/rli/PWEs/jfx/modules/javafx.graphics/build/native/glass/linux/glassgtk2/wrapped.obj /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c Successfully started process 'command 'gcc'' gcc: error: : No such file or directory ... repeats 17 times for different files ... > Task :graphics:ccLinuxGlassGlassgtk2 FAILED Caching disabled for task ':graphics:ccLinuxGlassGlassgtk2' because: Build cache is disabled Task ':graphics:ccLinuxGlassGlassgtk2' is not up-to-date because: Task has failed previously. Compiling native files: [/home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_key.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassView.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassCommonDialogs.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassRobot.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassPixels.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassDnDClipboard.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassCursor.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassWindow.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassSystemClipboard.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_evloop.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassTimer.cpp, /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_screen.cpp] :graphics:ccLinuxGlassGlassgtk2 (Thread[Daemon worker Thread 2,5,main]) completed. Took 0.06 secs. FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':graphics:ccLinuxGlassGlassgtk2'. > java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: Process 'command 'gcc'' finished with non-zero exit value 1 * Try: Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output. Run with --scan to get full insights. * Get more help at https://help.gradle.org Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use '--warning-mode all' to show the individual deprecation warnings. See https://docs.gradle.org/6.0/userguide/command_line_interface.html#sec:command_line_warnings BUILD FAILED in 1s When I execute the command manually: gcc -fno-strict-aliasing -fPIC -fno-omit-frame-pointer -fstack-protector -Wextra -Wall -Wformat-security -Wno-unused -Wno-parentheses -Werror=implicit-function-declaration -Werror=trampolines -I/usr/java/jdk-12.0.2+10/include -I/usr/java/jdk-12.0.2+10/include/linux -c -ffunction-sections -fdata-sections -O2 -DNDEBUG -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/atk-1.0 -pthread -I/home/rli/PWEs/jfx/modules/javafx.graphics/build/gensrc/headers/javafx.graphics -o /home/rli/PWEs/jfx/modules/javafx.graphics/build/native/glass/linux/glassgtk2/wrapped.obj /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c I can successfully compile the file. Any hints / suggestions welcome as to what is going wrong here. Robert From fastegal at openjdk.java.net Mon Jun 15 08:14:01 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 15 Jun 2020 08:14:01 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 07:49:24 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ListCellSkin.java line 100: >> >>> 99: double fixedCellSize = getFixedCellSize(); >>> 100: if (fixedCellSize > 0) { >>> 101: return fixedCellSize; >> >> These compute methods get invoked multiple times during each layout pass(10s of times). Fetching the fixed cell size on >> each call to these methods seems to be repeated and costly operation compared to previous boolean check. I think we >> should keep the previous way of handling it: registering the change listener to `listView.fixedCellSizeProperty()`. > > ehh .. last time I did such micro-optimization was in the 80ies of last century ;) > > Are there any performance measurements anywhere to demonstrate the impact? a bit less flippant: really interested in the measurements - certainly, they are somewhere but can't find anything. Any pointer where to look? ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From jvos at openjdk.java.net Mon Jun 15 09:08:15 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 15 Jun 2020 09:08:15 GMT Subject: [Rev 02] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 18:28:47 GMT, Phil Race wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> use LinkedHashMap instead of HashMap >> Only store the pointer to the utf8 string if its creation was successful > > Marked as reviewed by prr (Reviewer). > As for the test, even if StubFont were updated to provide a real font, the StubToolkit doesn't load Prism (so none of > the text rendering code is exercised). Do you think you could instead add a simple test or two in the system tests > project instead (maybe one testing UTF16 chars and one with a 0 char)? I added a systemtest ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From jvos at openjdk.java.net Mon Jun 15 09:08:14 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 15 Jun 2020 09:08:14 GMT Subject: [Rev 03] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Add test for testing Pango behavior with Character(0) and surrogate pairs ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/249/files - new: https://git.openjdk.java.net/jfx/pull/249/files/0d6e9093..8c6e73a0 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/249/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/249/webrev.02-03 Stats: 147 lines in 1 file changed: 147 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/249/head:pull/249 PR: https://git.openjdk.java.net/jfx/pull/249 From arapte at openjdk.java.net Mon Jun 15 09:47:56 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Jun 2020 09:47:56 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 08:11:40 GMT, Jeanette Winzenburg wrote: >> ehh .. last time I did such micro-optimization was in the 80ies of last century ;) >> >> Are there any performance measurements anywhere to demonstrate the impact? > > a bit less flippant: really interested in the measurements - certainly, they are somewhere but can't find anything. Any > pointer where to look? Even I do not know if there are any performance measurements for such scenario. :) May be @kevinrushforth could help in that. I just counted the calls by adding a log, and observed that for a ListView with only one item, these three methods combinely are called 97 times when the Stage is displayed for the first time and 45 times when the item is selected. ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From rlichten at openjdk.java.net Mon Jun 15 09:43:37 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 15 Jun 2020 09:43:37 GMT Subject: [Rev 04] RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: Message-ID: > This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Let Exceptions fail TextInputControlTest Fix undo/redo by delaying selectedText update Add a test for redo ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/138/files - new: https://git.openjdk.java.net/jfx/pull/138/files/6f10355d..533774fe Webrevs: - full: https://webrevs.openjdk.java.net/jfx/138/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/138/webrev.03-04 Stats: 65 lines in 2 files changed: 47 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jfx/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138 PR: https://git.openjdk.java.net/jfx/pull/138 From fastegal at openjdk.java.net Mon Jun 15 09:56:17 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 15 Jun 2020 09:56:17 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 09:44:40 GMT, Ambarish Rapte wrote: >> a bit less flippant: really interested in the measurements - certainly, they are somewhere but can't find anything. Any >> pointer where to look? > > Even I do not know if there are any performance measurements for such scenario. :) May be @kevinrushforth could help in > that. I just counted the calls by adding a log, and observed that for a ListView with only one item, these three > methods combinely are called 23 times when the Stage is displayed for the first time and 5 times when the item is > selected. (updated the counts after rechecking, looks like the methods are invoked for empty cells too, which seems > correct) hmm, do you mean a list with height of one cell only? My experiment (having counters per instance and per computeXXHeight), logs 1 (or 2) for computePref with fixed size and 5 (1 each for min/max and 3 for pref) without fixedSize per layout pass. So it's 5* access of either the local field or the listView method .. wouldn't expect any problems, but then assumed performance is reading in coffee ground :) Let's hope there are some metrics to use :) ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From fastegal at openjdk.java.net Mon Jun 15 10:12:43 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 15 Jun 2020 10:12:43 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: <7EMK7pS39nZqQwVEunQjnqN51JWrdxV3uUydA106vow=.478325d8-4026-4e60-abb3-ac7c9d9f8346@github.com> <8JzXWbqndJMF8iKBKqYjWc05F-VUBxPHUiIRmEgqfmg=.3b10e715-8949-4f28-96e2-715392808f1b@github.com> <6WhyH_3NIHMKxVw-xsTv6jAsSb2njDPkaaN Vz64y60E=.352fb913-33e4-40ee-a28b-9da54e7095c8@github.com> <4I58IIqTX2S0zeE9j7bhrP7RPdu1Ei1x0sz40K2VaWU=.e33d173d-b104-45ca-b772-721e722c333b@github.com> Message-ID: On Mon, 15 Jun 2020 05:36:35 GMT, Robert Lichtenberger wrote: >> good direction, I think :) >> >> Didn't look too closely, just added your changes and run the tests - getting a StringIndexOutofBounds at >> TextInputControlTest.test_jdk_8171229_replaceText(TextInputControlTest.java:1862) (no failing test because the >> uncaughtException handler not redirected). Could you check please? > >> good direction, I think :) >> >> Didn't look too closely, just added your changes and run the tests - getting a StringIndexOutofBounds at >> TextInputControlTest.test_jdk_8171229_replaceText(TextInputControlTest.java:1862) (no failing test because the >> uncaughtException handler not redirected). Could you check please? > > Will check this week. seeing that you are working at it (and still without too close a look, sry ;) - we need more tests about the notifications of all properties involved: text, selectedText, indexRange (anything else?). The things to test are count and old/new value. F.i. something like: List values = new ArrayList(); textField.selectedTextProperty().addListener((src, ov, nv) -> { list.addAll(ov, nv); } // do stuff assertEquals(2, values.size()); assertEquals(expectedOldValue, values.get(0)); assertEquals(expectedNewValue, values.get(1)); ------------- PR: https://git.openjdk.java.net/jfx/pull/138 From aghaisas at openjdk.java.net Mon Jun 15 11:50:41 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 15 Jun 2020 11:50:41 GMT Subject: [Rev 03] RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar In-Reply-To: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> Message-ID: > Issue : > https://bugs.openjdk.java.net/browse/JDK-8244418 > > Root Cause : > Incorrect assumption about menu list size. > > Fix : > Added check for empty menu list before trying to access it. > > Test : > Added a unit test that fails before fix and passes after it. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: fix_review_comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/216/files - new: https://git.openjdk.java.net/jfx/pull/216/files/683849c0..331766a6 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/216/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/216/webrev.02-03 Stats: 19 lines in 3 files changed: 3 ins; 4 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/216/head:pull/216 PR: https://git.openjdk.java.net/jfx/pull/216 From aghaisas at openjdk.java.net Mon Jun 15 11:50:41 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 15 Jun 2020 11:50:41 GMT Subject: [Rev 02] RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar In-Reply-To: References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> Message-ID: On Sat, 13 Jun 2020 15:03:00 GMT, Kevin Rushforth wrote: >> darn .. overlooked that fixed index .. >> >> As to the naming: personally, I hate violation of naming conventions even for test-only methods, so would tend to make >> setFocusedMenuIndex package and doc as being used for testing as well as internally. >> We might consider aligning the corresponding methods in the shim (they are also slightly confusing in >> get/set/FocusedIndex). > > Good suggestion. Thanks @kevinrushforth for catching this. It was a big overlook on my part. ------------- PR: https://git.openjdk.java.net/jfx/pull/216 From kcr at openjdk.java.net Mon Jun 15 13:29:46 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Jun 2020 13:29:46 GMT Subject: [Rev 03] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 09:08:14 GMT, Johan Vos wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add test for testing Pango behavior with Character(0) and surrogate pairs The new test look good. I confirm that it fails without your patch and passes with your patch. I added a few suggestions to bring it in line with current best practices. tests/system/src/test/java/test/com/sun/javafx/font/freetype/PangoTest.java line 77: > 76: stage.show(); > 77: launchLatch.countDown(); > 78: } Our newer system tests use a `WINDOW_SHOWN` event to trigger the countdown of the latch, like this (which would be added before the stage is shown). stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e -> Platform.runLater(launchLatch::countDown)); This ensures that the Stage has been shown before the first test is run. tests/system/src/test/java/test/com/sun/javafx/font/freetype/PangoTest.java line 117: > 116: if (!rDone.await(TIMEOUT, TimeUnit.MILLISECONDS)) { > 117: throw new AssertionFailedError("Timeout waiting for runLater"); > 118: } This could also be replaced with `assertTrue("Timeout ...", rDone.await(TIMEOUT, TimeUnit.MILLISECONDS)` if you add `throws Exception` to this method and the calling test methods. modules/javafx.graphics/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 102: > 101: @Ignore() // ignored since StubFontLoader used in tests return fonts with null resources > 102: @Test public void utf16chars() { > 103: GlyphLayout layout = GlyphLayout.getInstance(); Since this is `@Ignore`d with no real way to make it a useful test, maybe it would be best to revert the changes to this file? ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Mon Jun 15 13:33:22 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Jun 2020 13:33:22 GMT Subject: [Rev 03] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 09:08:14 GMT, Johan Vos wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Add test for testing Pango behavior with Character(0) and surrogate pairs tests/system/src/test/java/test/com/sun/javafx/font/freetype/PangoTest.java line 88: > 87: if (!launchLatch.await(TIMEOUT, TimeUnit.MILLISECONDS)) { > 88: throw new AssertionFailedError("Timeout waiting for Application to launch"); > 89: } Somehow this comment was dropped from my previous comments... If you add `throws Exception` to this method, then the entire try/catch block can be replaced with: assertTrue("Timeout waiting for Application to launch", launchLatch.await(TIMEOUT, TimeUnit.MILLISECONDS)); ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kevin.rushforth at oracle.com Mon Jun 15 13:57:27 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jun 2020 06:57:27 -0700 Subject: Result: New OpenJFX Committer: Jeanette Winzenburg Message-ID: Voting for Jeanette Winzenburg [1] to OpenJFX Committer [2] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#fastegal [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-June/026563.html From kevin.rushforth at oracle.com Mon Jun 15 13:58:10 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jun 2020 06:58:10 -0700 Subject: Result: New OpenJFX Committer: Jose Pereda Message-ID: <310fc9de-9549-b219-c9ca-53b49c2918b6@oracle.com> Voting for Jose Pereda [1] to OpenJFX Committer [2] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#jpereda [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-June/026564.html From kcr at openjdk.java.net Mon Jun 15 14:38:13 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Jun 2020 14:38:13 GMT Subject: [Rev 03] RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar In-Reply-To: References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> Message-ID: <9ABP_HUD5sCu05kwhgRHEH1usX7NHcj4L5m-5A575gY=.2a233408-990e-4790-a138-f53be9430a44@github.com> On Mon, 15 Jun 2020 11:50:41 GMT, Ajit Ghaisas wrote: >> Issue : >> https://bugs.openjdk.java.net/browse/JDK-8244418 >> >> Root Cause : >> Incorrect assumption about menu list size. >> >> Fix : >> Added check for empty menu list before trying to access it. >> >> Test : >> Added a unit test that fails before fix and passes after it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > fix_review_comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/216 From jvos at openjdk.java.net Mon Jun 15 15:46:24 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 15 Jun 2020 15:46:24 GMT Subject: [Rev 04] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: use latest patterns in system test revert ignored test in :graphics ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/249/files - new: https://git.openjdk.java.net/jfx/pull/249/files/8c6e73a0..cc178e77 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/249/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/249/webrev.03-04 Stats: 46 lines in 2 files changed: 2 ins; 37 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/249/head:pull/249 PR: https://git.openjdk.java.net/jfx/pull/249 From github.com+7450507+fthevenet at openjdk.java.net Mon Jun 15 15:57:33 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 15 Jun 2020 15:57:33 GMT Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Sat, 9 May 2020 17:43:08 GMT, Kevin Rushforth wrote: > [...] I'd like to see some additional system tests that cover all of the cases of X and Y fitting/not-fitting exactly > (and if you stick with your current approach, X or Y as the inner loop). What kind of tests do you have in mind? More specifically do you mean simply adding tests that expand on the existing `doTestSnapshotScaleNodeDefer`and `doTestSnapshotScaleNodeImm` (which basically just prove that taking a snapshot returns a non-null image of the expected size)? Or do you think we need to include a test that proves the snapshot produced by tiling is entirely faithful to the original, pixel-wise? ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From jvos at openjdk.java.net Mon Jun 15 16:04:05 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 15 Jun 2020 16:04:05 GMT Subject: [Rev 05] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: remove trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/249/files - new: https://git.openjdk.java.net/jfx/pull/249/files/cc178e77..889c013c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/249/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/249/webrev.04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/249/head:pull/249 PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Mon Jun 15 16:13:32 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Jun 2020 16:13:32 GMT Subject: [Rev 05] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: <3DGKJ9-JIiPJ8lt-yIiggmBon6OOHgDWxizesacGzIk=.aa76527e-2cbc-4c60-8c71-137b6ea0c77d@github.com> On Mon, 15 Jun 2020 16:04:05 GMT, Johan Vos wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > remove trailing whitespace Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/249 From prr at openjdk.java.net Mon Jun 15 16:55:26 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 15 Jun 2020 16:55:26 GMT Subject: [Rev 05] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 16:04:05 GMT, Johan Vos wrote: >> This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > remove trailing whitespace Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From jvos at openjdk.java.net Mon Jun 15 17:15:12 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 15 Jun 2020 17:15:12 GMT Subject: [Integrated] RFR: 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars In-Reply-To: References: Message-ID: <7AJGEQo8M5YNFAdoZcbq14h8lg9EuBXdpFo5TxrvFjM=.60dd7b49-1839-4968-972e-523313861c41@github.com> On Tue, 9 Jun 2020 19:33:01 GMT, Johan Vos wrote: > This addresses https://bugs.openjdk.java.net/browse/JDK-8246348 This pull request has now been integrated. Changeset: bf2e972d Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/bf2e972d Stats: 155 lines in 4 files changed: 2 ins; 146 del; 7 mod 8246348: Crash in libpango on Ubuntu 20.04 with some unicode chars Reviewed-by: prr, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/249 From kcr at openjdk.java.net Mon Jun 15 17:50:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Jun 2020 17:50:23 GMT Subject: [Rev 01] RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: Message-ID: On Sun, 14 Jun 2020 19:19:15 GMT, Jose Pereda wrote: >> This PR comments out too verbose console logging, as it has been done with some other fprintf calls. >> As a follow up of this PR, a custom directive that enables this output if needed can be considered. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Call fprintf only if pulse logging was requested Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From prr at openjdk.java.net Mon Jun 15 17:54:08 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 15 Jun 2020 17:54:08 GMT Subject: [Rev 03] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: <3uuB2zADNo3N7Yqgv_-IEKj7A-8mXQa6fgK3zGb2XOs=.1f1fef51-62d4-4e8b-9189-15d2b8336e7a@github.com> On Mon, 15 Jun 2020 05:22:48 GMT, Bhawesh Choudhary wrote: >> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, >> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing >> pages otherwise print all pages as usual. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > cleanup unused variable Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/222 From arapte at openjdk.java.net Mon Jun 15 19:23:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Jun 2020 19:23:45 GMT Subject: [Rev 03] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: <6PkXqtv8-Mv87VodFnTavpbSgJYF05k9vJHpHRSC-vs=.13a8567f-4a34-4aef-9671-4cadf1692b85@github.com> > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Correcting the selection change events generated post sorting ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/244/files - new: https://git.openjdk.java.net/jfx/pull/244/files/1561d2db..e733a6c1 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/244/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/244/webrev.02-03 Stats: 142 lines in 2 files changed: 104 ins; 14 del; 24 mod Patch: https://git.openjdk.java.net/jfx/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/244/head:pull/244 PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Mon Jun 15 19:25:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Jun 2020 19:25:52 GMT Subject: [Rev 01] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <8TwSS7QP-d5ZRbk81I149czrigowA3IAQ_pji-BVfaI=.09da4b70-1057-40d3-9cf6-0246c2101023@github.com> Message-ID: On Thu, 4 Jun 2020 11:16:50 GMT, Ambarish Rapte wrote: > In the above case, The selection updates correctly but the received change event on SelectedItems is incorrect. As of > now it looks like the selection is updated correctly with this fix, but the event generated from sort() method is > always incorrect. Looking in to fix the change event.... Please take a look at the updated changes. The `GenericAddRemoveChange` event generated from `TreeTableView.sort()` method does not result in correct selection change events. @kevinrushforth , Thanks for the guidance on this in offline discussion. The solution is to sort the tree of selected items upfront before generating the `GenericAddRemoveChange` event. Rest of the TreeItems can be left to be sorted lazily whenever accessed. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Mon Jun 15 19:30:17 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 15 Jun 2020 19:30:17 GMT Subject: [Rev 03] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: <6PkXqtv8-Mv87VodFnTavpbSgJYF05k9vJHpHRSC-vs=.13a8567f-4a34-4aef-9671-4cadf1692b85@github.com> References: <6PkXqtv8-Mv87VodFnTavpbSgJYF05k9vJHpHRSC-vs=.13a8567f-4a34-4aef-9671-4cadf1692b85@github.com> Message-ID: <4tBFi0UHuZDp8AiWyGCBBhDQ6vq-ygpPts9Y7JWxiC4=.7ee33805-fede-4f1a-8eca-0a5c269625c6@github.com> On Mon, 15 Jun 2020 19:23:45 GMT, Ambarish Rapte wrote: >> Issue: >> In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not >> retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using >> `setAll()`). Cause: >> >> 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. >> 2. The indices from these TreeModificationEvents are not reliable. >> 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor >> results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of >> sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the >> selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or >> collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues >> combine in wrong update of the selection. Fix: >> >> 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the >> TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is >> almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change >> events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as >> before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change >> events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` >> Verification: >> The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the >> change should not cause any other failures. Added unit tests which fail before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Correcting the selection change events generated post sorting modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 2592: > 2591: selectedCellsMap.setAll(updatedSelection); > 2592: stopAtomic(); > 2593: } else { This code block gets executed only as a result of sorting performed by `TreeTableView.sort()` method. The method `TreeTableView.sort()` makes call to the `SelectionModel.startAtomic()` and `SelectionModel.stopAtomic()`. Hence, Ideally it is not required to call those methods from here. But keeping these for precautions to safe guard against any future changes and better understanding when reading. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From jvos at openjdk.java.net Mon Jun 15 19:40:31 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 15 Jun 2020 19:40:31 GMT Subject: [Rev 01] RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: Message-ID: On Sun, 14 Jun 2020 19:19:15 GMT, Jose Pereda wrote: >> This PR comments out too verbose console logging, as it has been done with some other fprintf calls. >> As a follow up of this PR, a custom directive that enables this output if needed can be considered. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Call fprintf only if pulse logging was requested modules/javafx.graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m line 86: > 85: if (pulseLoggingRequested) { > 86: fprintf(stderr, "IOSWindowSystemInterface : deleteContext unimp\n"); > 87: } this doesn't relate to pulseLogging I believe? ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From jpereda at openjdk.java.net Mon Jun 15 19:54:38 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 15 Jun 2020 19:54:38 GMT Subject: [Rev 01] RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 19:38:19 GMT, Johan Vos wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Call fprintf only if pulse logging was requested > > modules/javafx.graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m line 86: > >> 85: if (pulseLoggingRequested) { >> 86: fprintf(stderr, "IOSWindowSystemInterface : deleteContext unimp\n"); >> 87: } > > this doesn't relate to pulseLogging I believe? Right, but since it wasn't commented out, should I just leave it as it was? ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From kcr at openjdk.java.net Mon Jun 15 23:55:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Jun 2020 23:55:26 GMT Subject: [Rev 03] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: <6PkXqtv8-Mv87VodFnTavpbSgJYF05k9vJHpHRSC-vs=.13a8567f-4a34-4aef-9671-4cadf1692b85@github.com> References: <6PkXqtv8-Mv87VodFnTavpbSgJYF05k9vJHpHRSC-vs=.13a8567f-4a34-4aef-9671-4cadf1692b85@github.com> Message-ID: On Mon, 15 Jun 2020 19:23:45 GMT, Ambarish Rapte wrote: >> Issue: >> In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not >> retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using >> `setAll()`). Cause: >> >> 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. >> 2. The indices from these TreeModificationEvents are not reliable. >> 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor >> results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of >> sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the >> selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or >> collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues >> combine in wrong update of the selection. Fix: >> >> 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the >> TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is >> almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change >> events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as >> before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change >> events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` >> Verification: >> The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the >> change should not cause any other failures. Added unit tests which fail before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Correcting the selection change events generated post sorting The fix looks good now with one suggested cleanup. The tests will catch the bug (including the most recently fixed problem), but I noted a couple of issues with the test inline below. modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1815: > 1814: boolean isSortTreeOfSelectedItems() { > 1815: return sortTreeOfSelectedItems; > 1816: } This method / state attribute isn't really needed. The value is never set to anything other than `true`. I recommend removing it. modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 431: > 430: for (int j = 0; j < FIRST_LEVEL_COUNT - 1; j++) { > 431: TreeItem tj = new TreeItem<>("" + i + j); > 432: tj.setExpanded(true); The tree item strings will not be unique. This won't affect whether the test passes or fails, since `TreeItem` does not override `equals`, but it might be better if the strings were unique (in case there ever was an error it would be easier to understand). modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 472: > 471: countSelectedIndexChangeEvent++; > 472: assertEquals(selectedItemBefore, treeTableView.getTreeItem(sm.getSelectedIndex())); > 473: }); If this assertion ever fails, I don't think it will cause a test failure, since the event handling code will swallow the exception. The same is true of the other listeners. I don't know if it would be possible to use the UncaughtExceptionHandler as is done in other tests -- see [JDK-8244531](https://bugs.openjdk.java.net/browse/JDK-8244531) -- but that might be worth exploring. Another possibility is to wrap all the listeners in a try/catch and keep a list of `Throwable`s that are caught. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Tue Jun 16 00:31:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Jun 2020 00:31:03 GMT Subject: [Rev 03] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 05:22:48 GMT, Bhawesh Choudhary wrote: >> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, >> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing >> pages otherwise print all pages as usual. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > cleanup unused variable Both the fix and the test look good. I left a couple minor formatting / style comments. modules/javafx.web/src/main/java/javafx/scene/web/WebEngine.java line 1615: > 1614: JobSettings jobSettings = job.getJobSettings(); > 1615: if(jobSettings.getPageRanges() != null) { > 1616: PageRange[] pageRanges = jobSettings.getPageRanges(); Minor: space after `if`. tests/manual/printing/PrintPageRangeTest.java line 83: > 82: htmlStringBuilder.append(""); > 83: for(int i = 0; i < 500; ++i) { > 84: htmlStringBuilder.append("

HTML Line No. "); Minor: space after `for` tests/manual/printing/PrintPageRangeTest.java line 122: > 121: > 122: private void SetMessage(String msg) { > 123: bottomMessageLabel.setText(msg); Minor: usual naming convention is for an initial lower-case letter. ------------- PR: https://git.openjdk.java.net/jfx/pull/222 From r.lichtenberger at gmail.com Tue Jun 16 05:08:13 2020 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Tue, 16 Jun 2020 07:08:13 +0200 Subject: Build Problems on Linux In-Reply-To: References: Message-ID: Please ignore my previous mail. I forgot to update my fork of OpenJFX so I was operating on a Mid-March version. After really updating everything worked fine. Am Mo., 15. Juni 2020 um 10:12 Uhr schrieb Robert Lichtenberger < r.lichtenberger at gmail.com>: > I haven't built in a while but today I pulled the current master branch > and tried to build OpenJFX. > Unfortunately, the task :graphics:ccLinuxGlassGlassgtk2 fails like this: > > :graphics:ccLinuxGlassGlassgtk2 (Thread[Daemon worker Thread 2,5,main]) > started. > Starting process 'command 'gcc''. Working directory: > /home/rli/PWEs/jfx/modules/javafx.graphics Command: gcc > -fno-strict-aliasing -fPIC -fno-omit-frame-pointer -fstack-protector > -Wextra -Wall -Wformat-security -Wno-unused -Wno-parentheses > -Werror=implicit-function-declaration -Werror=trampolines > -I/usr/java/jdk-12.0.2+10/include -I/usr/java/jdk-12.0.2+10/include/linux > -c -ffunction-sections -fdata-sections -O2 -DNDEBUG -I/usr/include/gtk-2.0 > -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include > -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/freetype2 > -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pixman-1 > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid > -I/usr/include/atk-1.0 -pthread > -I/home/rli/PWEs/jfx/modules/javafx.graphics/build/gensrc/headers/javafx.graphics > -o > /home/rli/PWEs/jfx/modules/javafx.graphics/build/native/glass/linux/glassgtk2/wrapped.obj > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c > Successfully started process 'command 'gcc'' > gcc: error: : No such file or directory > ... repeats 17 times for different files ... > > > Task :graphics:ccLinuxGlassGlassgtk2 FAILED > Caching disabled for task ':graphics:ccLinuxGlassGlassgtk2' because: > Build cache is disabled > Task ':graphics:ccLinuxGlassGlassgtk2' is not up-to-date because: > Task has failed previously. > Compiling native files: > [/home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_key.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassView.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassCommonDialogs.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassRobot.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassPixels.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassDnDClipboard.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassCursor.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassWindow.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassSystemClipboard.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_evloop.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/GlassTimer.cpp, > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/glass_screen.cpp] > :graphics:ccLinuxGlassGlassgtk2 (Thread[Daemon worker Thread 2,5,main]) > completed. Took 0.06 secs. > > FAILURE: Build failed with an exception. > > * What went wrong: > Execution failed for task ':graphics:ccLinuxGlassGlassgtk2'. > > java.util.concurrent.ExecutionException: > org.gradle.process.internal.ExecException: Process 'command 'gcc'' finished > with non-zero exit value 1 > > * Try: > Run with --stacktrace option to get the stack trace. Run with --debug > option to get more log output. Run with --scan to get full insights. > > * Get more help at https://help.gradle.org > > Deprecated Gradle features were used in this build, making it incompatible > with Gradle 7.0. > Use '--warning-mode all' to show the individual deprecation warnings. > See > https://docs.gradle.org/6.0/userguide/command_line_interface.html#sec:command_line_warnings > > BUILD FAILED in 1s > > When I execute the command manually: > gcc -fno-strict-aliasing -fPIC -fno-omit-frame-pointer -fstack-protector > -Wextra -Wall -Wformat-security -Wno-unused -Wno-parentheses > -Werror=implicit-function-declaration -Werror=trampolines > -I/usr/java/jdk-12.0.2+10/include -I/usr/java/jdk-12.0.2+10/include/linux > -c -ffunction-sections -fdata-sections -O2 -DNDEBUG -I/usr/include/gtk-2.0 > -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include > -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/freetype2 > -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pixman-1 > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid > -I/usr/include/atk-1.0 -pthread > -I/home/rli/PWEs/jfx/modules/javafx.graphics/build/gensrc/headers/javafx.graphics > -o > /home/rli/PWEs/jfx/modules/javafx.graphics/build/native/glass/linux/glassgtk2/wrapped.obj > /home/rli/PWEs/jfx/modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c > > I can successfully compile the file. > > Any hints / suggestions welcome as to what is going wrong here. > Robert > > From r.lichtenberger at gmail.com Tue Jun 16 05:21:07 2020 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Tue, 16 Jun 2020 07:21:07 +0200 Subject: Test style questions Message-ID: While discussing my Pull Request ([1]) for JDK-8176270 ([2]) with Jeanette Winzenburg I came across two questions that I would like to ask the community regarding test cases: 1) How fine-grained to we want tests to be? Is it ok to test two (somewhat similiar) things at once or should a separate test case be written? e.g. this test case of mine: @Test public void replaceSelectionAtEndWithListener() { StringBuilder selectedTextLog = new StringBuilder(); StringBuilder selectionLog = new StringBuilder(); textInput.setText("x xxx"); textInput.selectRange(2, 5); textInput.selectedTextProperty().addListener((__, ___, selection) -> selectedTextLog.append("|" + selection)); textInput.selectionProperty().addListener((__, ___, selection) -> selectionLog.append("|" + selection.getStart() + "," + selection.getEnd())); textInput.replaceSelection("a"); assertEquals("|", selectedTextLog.toString()); assertEquals("|3,3", selectionLog.toString()); assertEquals("x a", textInput.getText()); } Will test the selectedTextProperty AND the selectionProperty at the same time. Is this acceptable/desireable or should the test case be split into two separate tests? 2) When fixing bugs, is it ok to not only provide a test case that will fail before the fix and run successfully after the fix but also provide additional test cases with the intention of preventing regressions? Ideally of course such tests should already exist but what if they are not. In my case I wanted to add a test case to "prove" that redo() will work in the presence of a shortened text and I would also like to have a general test case about selection properties and text property. What's the general rule here? Best regards, Robert [1] https://github.com/openjdk/jfx/pull/138 [2] https://bugs.openjdk.java.net/browse/JDK-8176270 From arapte at openjdk.java.net Tue Jun 16 05:53:23 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 16 Jun 2020 05:53:23 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 09:53:56 GMT, Jeanette Winzenburg wrote: > hmm, do you mean a list with height of one cell only? Yes, List with one cell height. In continuation to my previous comment, looks like 8 of the first 23 calls when window is displayed for the first time are NOT for the one visible cell. These 8 calls are for some intermediate cell. I added a single counter for all three `computeXXHeight` methods and verified with a list of height of one cell. When `fixedCellSize` is not set, total combined number of calls for a cell are, 1:- 15, when Stage is displayed for the first time.(+8 for an intermediate cell, not sure why) 2:- 5, when the list item is selected. 3:- 5, when the Window is resized. ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From fkirmaier at openjdk.java.net Tue Jun 16 07:34:14 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 16 Jun 2020 07:34:14 GMT Subject: [Rev 01] RFR: 8247163: JFXPanel throws exception on click when no Scene is set In-Reply-To: References: Message-ID: On Thu, 11 Jun 2020 00:32:34 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8247163: >> Added space based on code review > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 452: > >> 451: // which doesn't have any side-effects when called multiple times. >> 452: if(stagePeer != null) { >> 453: int focusCause = AbstractEvents.FOCUSEVENT_ACTIVATED; > > Minor: space after the `if` I've added the space. ------------- PR: https://git.openjdk.java.net/jfx/pull/248 From fkirmaier at openjdk.java.net Tue Jun 16 07:34:13 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 16 Jun 2020 07:34:13 GMT Subject: [Rev 01] RFR: 8247163: JFXPanel throws exception on click when no Scene is set In-Reply-To: References: Message-ID: > Fixing exception when clicking on JFXPanel when no Scene is set. > > quick test: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests: test --tests *javafx.embed.swing.JFXPan* --info` > > It's a regression from my previous PR: https://github.com/openjdk/jfx/pull/25 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8247163: Added space based on code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/248/files - new: https://git.openjdk.java.net/jfx/pull/248/files/6f98aefd..6df4635d Webrevs: - full: https://webrevs.openjdk.java.net/jfx/248/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/248/webrev.00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/248.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/248/head:pull/248 PR: https://git.openjdk.java.net/jfx/pull/248 From fkirmaier at openjdk.java.net Tue Jun 16 07:34:13 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 16 Jun 2020 07:34:13 GMT Subject: [Rev 01] RFR: 8247163: JFXPanel throws exception on click when no Scene is set In-Reply-To: <-ciZDh41dLgOR8dcN1ZxND60CBqIfUfqN_8iiHVY0v4=.65397f8e-8199-4276-9c1c-04179c364ad6@github.com> References: <-ciZDh41dLgOR8dcN1ZxND60CBqIfUfqN_8iiHVY0v4=.65397f8e-8199-4276-9c1c-04179c364ad6@github.com> Message-ID: On Thu, 11 Jun 2020 23:37:40 GMT, Kevin Rushforth wrote: >> The fix looks correct to me (I haven't tested it yet). I left a minor comment inline. > > The fix and test both look good. Approved pending the minor format change (no need for a second reviewer). Great, I've added the requested minor format change! ------------- PR: https://git.openjdk.java.net/jfx/pull/248 From github.com+4208131+bhaweshkc at openjdk.java.net Tue Jun 16 07:59:02 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Tue, 16 Jun 2020 07:59:02 GMT Subject: [Rev 04] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: > Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, > which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing > pages otherwise print all pages as usual. Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: Formatting changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/222/files - new: https://git.openjdk.java.net/jfx/pull/222/files/717dac0f..456d0a16 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/222/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/222/webrev.03-04 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/222.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/222/head:pull/222 PR: https://git.openjdk.java.net/jfx/pull/222 From rlichten at openjdk.java.net Tue Jun 16 09:03:35 2020 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Tue, 16 Jun 2020 09:03:35 GMT Subject: [Rev 05] RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException In-Reply-To: References: Message-ID: <5dDCIGDVd43vo4JtxBVmSlPpZAhMjMKV5es8BZ6nj6c=.90895611-47ba-4f08-8232-3d2edd95dcf5@github.com> > This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException Move replaceSelectionAtEndWithListener test to general test class. Add a more general test for selection/text properties and replace/undo/redo operations. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/138/files - new: https://git.openjdk.java.net/jfx/pull/138/files/533774fe..660335bf Webrevs: - full: https://webrevs.openjdk.java.net/jfx/138/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/138/webrev.04-05 Stats: 71 lines in 3 files changed: 44 ins; 27 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/138.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/138/head:pull/138 PR: https://git.openjdk.java.net/jfx/pull/138 From fastegal at openjdk.java.net Tue Jun 16 09:39:42 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 16 Jun 2020 09:39:42 GMT Subject: [Rev 03] RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar In-Reply-To: References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> Message-ID: <8mvDa8dJdZxbg3nyIgfCHXGzGL0XjGw_yP5jHxk4lgo=.beb73297-9c9d-4055-9ccd-13271f260fe7@github.com> On Mon, 15 Jun 2020 11:50:41 GMT, Ajit Ghaisas wrote: >> Issue : >> https://bugs.openjdk.java.net/browse/JDK-8244418 >> >> Root Cause : >> Incorrect assumption about menu list size. >> >> Fix : >> Added check for empty menu list before trying to access it. >> >> Test : >> Added a unit test that fails before fix and passes after it. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > fix_review_comments bot says this needs a re-review - here we go: looks fine. BTW: what we might have learned is to test our test methods as well - if possible :) ------------- Marked as reviewed by fastegal (Author). PR: https://git.openjdk.java.net/jfx/pull/216 From fastegal at openjdk.java.net Tue Jun 16 10:09:32 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 16 Jun 2020 10:09:32 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Tue, 16 Jun 2020 05:50:43 GMT, Ambarish Rapte wrote: >> hmm, do you mean a list with height of one cell only? >> >> My experiment (having counters per instance and per computeXXHeight), logs 1 (or 2) for computePref with fixed size and >> 5 (1 each for min/max and 3 for pref) without fixedSize per layout pass. So it's 5* access of either the local field or >> the listView method .. wouldn't expect any problems, but then assumed performance is reading in coffee ground :) Let's >> hope there are some metrics to use :) > >> hmm, do you mean a list with height of one cell only? > > Yes, List with one cell height. > In continuation to my previous comment, looks like 8 of the first 23 calls when window is displayed for the first time > are NOT for the one visible cell. These 8 calls are for some intermediate cell. I added a single counter for all three > `computeXXHeight` methods and verified with a list of height of one cell. When `fixedCellSize` is not set, total > combined number of calls for a cell are, 1) 15, when Stage is displayed for the first time.(+8 for an intermediate > cell, not sure why) 2) 5, when the list item is selected. > 3) 5, when the Window is resized. something similar as I'm seeing - that's good :) Uploaded my [play code](https://gist.github.com/kleopatra/37ac1bffa0e2ad7580cd55344237cdca) to gist: the idea is to do something (like f.i. moving the selection), then press f1 to log the calls to each cell (the skin has a final instance counter and counters for calling the compute methods). As much fun as this is (really like to dig until I'm dirty all over :) - at the end of the day we'll need some measurements (doing these is not so much fun, still hoping something already available) ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From aghaisas at openjdk.java.net Tue Jun 16 10:16:02 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 16 Jun 2020 10:16:02 GMT Subject: [Integrated] RFR: 8244418: MenuBar: IOOB exception on requestFocus on empty bar In-Reply-To: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> References: <5AJyfBc8UVF0DqPiEWpxhzMst-b6o8ailGH_Qv0umcE=.453a7c7c-7a9a-4a21-a11f-1881ad003926@github.com> Message-ID: On Fri, 8 May 2020 12:21:48 GMT, Ajit Ghaisas wrote: > Issue : > https://bugs.openjdk.java.net/browse/JDK-8244418 > > Root Cause : > Incorrect assumption about menu list size. > > Fix : > Added check for empty menu list before trying to access it. > > Test : > Added a unit test that fails before fix and passes after it. This pull request has now been integrated. Changeset: fb962ac2 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/fb962ac2 Stats: 57 lines in 3 files changed: 3 ins; 41 del; 13 mod 8244418: MenuBar: IOOB exception on requestFocus on empty bar Reviewed-by: fastegal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/216 From kcr at openjdk.java.net Tue Jun 16 12:54:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Jun 2020 12:54:18 GMT Subject: [Rev 04] RFR: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: On Tue, 16 Jun 2020 07:59:02 GMT, Bhawesh Choudhary wrote: >> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, >> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing >> pages otherwise print all pages as usual. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/222 From kevin.rushforth at oracle.com Tue Jun 16 14:14:09 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 16 Jun 2020 07:14:09 -0700 Subject: Test style questions In-Reply-To: References: Message-ID: <079c97e8-c88d-abd9-c4cd-a6066b9206e6@oracle.com> 1. It's a judgment call. I tend to like fairly fine-grained tests as long as they are (at least mostly) independent. If the test is "do A", "verify state", "do B", "verify state" and B is something that you need to do after A, then having them in the same test is better. 2. It depends. If the additional tests are related to the area you are fixing and you are worried that the missing tests could lead to bugs if additional changes were made in the area you are fixing, then I think it's fine to add the new tests. If it's just a case where the test coverage is poor, it might make sense for a follow-on test bug to add new tests. I know that this isn't a definitive answer, but hopefully it will provide some general guidance. -- Kevin On 6/15/2020 10:21 PM, Robert Lichtenberger wrote: > While discussing my Pull Request ([1]) for JDK-8176270 ([2]) with Jeanette > Winzenburg I came across two questions that I would like to ask the > community regarding test cases: > > 1) How fine-grained to we want tests to be? Is it ok to test two (somewhat > similiar) things at once or should a separate test case be written? e.g. > this test case of mine: > @Test public void replaceSelectionAtEndWithListener() { > StringBuilder selectedTextLog = new StringBuilder(); > StringBuilder selectionLog = new StringBuilder(); > textInput.setText("x xxx"); > textInput.selectRange(2, 5); > textInput.selectedTextProperty().addListener((__, ___, selection) > -> selectedTextLog.append("|" + selection)); > textInput.selectionProperty().addListener((__, ___, selection) -> > selectionLog.append("|" + selection.getStart() + "," + selection.getEnd())); > textInput.replaceSelection("a"); > assertEquals("|", selectedTextLog.toString()); > assertEquals("|3,3", selectionLog.toString()); > assertEquals("x a", textInput.getText()); > } > Will test the selectedTextProperty AND the selectionProperty at the same > time. Is this acceptable/desireable or should the test case be split into > two separate tests? > > 2) When fixing bugs, is it ok to not only provide a test case that will > fail before the fix and run successfully after the fix but also provide > additional test cases with the intention of preventing regressions? Ideally > of course such tests should already exist but what if they are not. > In my case I wanted to add a test case to "prove" that redo() will work in > the presence of a shortened text and I would also like to have a general > test case about selection properties and text property. What's the general > rule here? > > Best regards, > Robert > > [1] https://github.com/openjdk/jfx/pull/138 > [2] https://bugs.openjdk.java.net/browse/JDK-8176270 From kcr at openjdk.java.net Tue Jun 16 22:39:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Jun 2020 22:39:47 GMT Subject: RFR: 8247360: Add missing license file for Microsoft DirectShow Samples Message-ID: <-PcVai7r_BipwE68rsBtw9afNUSKSDWPVPLUmI7__iA=.8478801d-b722-4ad9-83fa-7bb9f20ac09f@github.com> This adds a missing third-party license file for the Microsoft DirectShow Samples. ------------- Commit messages: - 8247360: Add missing license file for Microsoft DirectShow Samples Changes: https://git.openjdk.java.net/jfx/pull/252/files Webrev: https://webrevs.openjdk.java.net/jfx/252/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247360 Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/252.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/252/head:pull/252 PR: https://git.openjdk.java.net/jfx/pull/252 From kcr at openjdk.java.net Tue Jun 16 22:39:47 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Jun 2020 22:39:47 GMT Subject: RFR: 8247360: Add missing license file for Microsoft DirectShow Samples In-Reply-To: <-PcVai7r_BipwE68rsBtw9afNUSKSDWPVPLUmI7__iA=.8478801d-b722-4ad9-83fa-7bb9f20ac09f@github.com> References: <-PcVai7r_BipwE68rsBtw9afNUSKSDWPVPLUmI7__iA=.8478801d-b722-4ad9-83fa-7bb9f20ac09f@github.com> Message-ID: On Tue, 16 Jun 2020 22:25:48 GMT, Kevin Rushforth wrote: > This adds a missing third-party license file for the Microsoft DirectShow Samples. @sashamatveev can you review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/252 From kcr at openjdk.java.net Tue Jun 16 22:40:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Jun 2020 22:40:05 GMT Subject: [Integrated] RFR: 8247360: Add missing license file for Microsoft DirectShow Samples In-Reply-To: <-PcVai7r_BipwE68rsBtw9afNUSKSDWPVPLUmI7__iA=.8478801d-b722-4ad9-83fa-7bb9f20ac09f@github.com> References: <-PcVai7r_BipwE68rsBtw9afNUSKSDWPVPLUmI7__iA=.8478801d-b722-4ad9-83fa-7bb9f20ac09f@github.com> Message-ID: On Tue, 16 Jun 2020 22:25:48 GMT, Kevin Rushforth wrote: > This adds a missing third-party license file for the Microsoft DirectShow Samples. This pull request has now been integrated. Changeset: 54e2507f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/54e2507f Stats: 26 lines in 1 file changed: 0 ins; 26 del; 0 mod 8247360: Add missing license file for Microsoft DirectShow Samples Reviewed-by: almatvee ------------- PR: https://git.openjdk.java.net/jfx/pull/252 From almatvee at openjdk.java.net Tue Jun 16 22:40:04 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 16 Jun 2020 22:40:04 GMT Subject: RFR: 8247360: Add missing license file for Microsoft DirectShow Samples In-Reply-To: <-PcVai7r_BipwE68rsBtw9afNUSKSDWPVPLUmI7__iA=.8478801d-b722-4ad9-83fa-7bb9f20ac09f@github.com> References: <-PcVai7r_BipwE68rsBtw9afNUSKSDWPVPLUmI7__iA=.8478801d-b722-4ad9-83fa-7bb9f20ac09f@github.com> Message-ID: On Tue, 16 Jun 2020 22:25:48 GMT, Kevin Rushforth wrote: > This adds a missing third-party license file for the Microsoft DirectShow Samples. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/252 From kevin.rushforth at oracle.com Tue Jun 16 23:58:11 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 16 Jun 2020 16:58:11 -0700 Subject: 11-dev backport request: JDK-8247360: Add missing license file for Microsoft DirectShow Samples Message-ID: Hi Johan, I request approval to backport the following to 11-dev for 11.0.8: JDK-8247360 [1] : Add missing license file for Microsoft DirectShow Samples -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8247360 From r.lichtenberger at gmail.com Wed Jun 17 04:49:06 2020 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Wed, 17 Jun 2020 06:49:06 +0200 Subject: Test style questions In-Reply-To: <079c97e8-c88d-abd9-c4cd-a6066b9206e6@oracle.com> References: <079c97e8-c88d-abd9-c4cd-a6066b9206e6@oracle.com> Message-ID: Thanks for the guidance. Since my additional tests happen to test against a regression that was actually happening I'll keep them in my PR. If the reviewer finds them superfluous I can still remove them. Am Di., 16. Juni 2020 um 16:17 Uhr schrieb Kevin Rushforth < kevin.rushforth at oracle.com>: > 1. It's a judgment call. I tend to like fairly fine-grained tests as > long as they are (at least mostly) independent. If the test is "do A", > "verify state", "do B", "verify state" and B is something that you need > to do after A, then having them in the same test is better. > > 2. It depends. If the additional tests are related to the area you are > fixing and you are worried that the missing tests could lead to bugs if > additional changes were made in the area you are fixing, then I think > it's fine to add the new tests. If it's just a case where the test > coverage is poor, it might make sense for a follow-on test bug to add > new tests. > > I know that this isn't a definitive answer, but hopefully it will > provide some general guidance. > > -- Kevin > > > On 6/15/2020 10:21 PM, Robert Lichtenberger wrote: > > While discussing my Pull Request ([1]) for JDK-8176270 ([2]) with > Jeanette > > Winzenburg I came across two questions that I would like to ask the > > community regarding test cases: > > > > 1) How fine-grained to we want tests to be? Is it ok to test two > (somewhat > > similiar) things at once or should a separate test case be written? e.g. > > this test case of mine: > > @Test public void replaceSelectionAtEndWithListener() { > > StringBuilder selectedTextLog = new StringBuilder(); > > StringBuilder selectionLog = new StringBuilder(); > > textInput.setText("x xxx"); > > textInput.selectRange(2, 5); > > textInput.selectedTextProperty().addListener((__, ___, > selection) > > -> selectedTextLog.append("|" + selection)); > > textInput.selectionProperty().addListener((__, ___, selection) > -> > > selectionLog.append("|" + selection.getStart() + "," + > selection.getEnd())); > > textInput.replaceSelection("a"); > > assertEquals("|", selectedTextLog.toString()); > > assertEquals("|3,3", selectionLog.toString()); > > assertEquals("x a", textInput.getText()); > > } > > Will test the selectedTextProperty AND the selectionProperty at the same > > time. Is this acceptable/desireable or should the test case be split into > > two separate tests? > > > > 2) When fixing bugs, is it ok to not only provide a test case that will > > fail before the fix and run successfully after the fix but also provide > > additional test cases with the intention of preventing regressions? > Ideally > > of course such tests should already exist but what if they are not. > > In my case I wanted to add a test case to "prove" that redo() will work > in > > the presence of a shortened text and I would also like to have a general > > test case about selection properties and text property. What's the > general > > rule here? > > > > Best regards, > > Robert > > > > [1] https://github.com/openjdk/jfx/pull/138 > > [2] https://bugs.openjdk.java.net/browse/JDK-8176270 > > From johan.vos at gluonhq.com Wed Jun 17 07:07:26 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 17 Jun 2020 09:07:26 +0200 Subject: 11-dev backport request: JDK-8247360: Add missing license file for Microsoft DirectShow Samples In-Reply-To: References: Message-ID: approved On Wed, Jun 17, 2020 at 1:58 AM Kevin Rushforth wrote: > Hi Johan, > > I request approval to backport the following to 11-dev for 11.0.8: > > JDK-8247360 [1] : Add missing license file for Microsoft DirectShow Samples > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8247360 > > > From psadhukhan at openjdk.java.net Wed Jun 17 07:35:08 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 17 Jun 2020 07:35:08 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% In-Reply-To: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Wed, 3 Jun 2020 15:46:36 GMT, Oliver Schmidtmer wrote: > In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and > EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared > rendering. The changes were already proposed by the submitter in JBS-8220484. > > OCA is signed and send. In 2D, we normally use sun.java2d.pipe.Region.clipRound as it also checks for -ve/+ve max INTEGER but I guess that is internal class to FX so it's ok to use Math.ceil. Approval pending test creation. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+7450507+fthevenet at openjdk.java.net Wed Jun 17 11:33:59 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 17 Jun 2020 11:33:59 GMT Subject: [Rev 08] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Added tiled snapshots tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/8f0c2d22..2951d538 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.08 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.07-08 Stats: 170 lines in 1 file changed: 168 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From arapte at openjdk.java.net Wed Jun 17 11:38:52 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 17 Jun 2020 11:38:52 GMT Subject: [Rev 03] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <6PkXqtv8-Mv87VodFnTavpbSgJYF05k9vJHpHRSC-vs=.13a8567f-4a34-4aef-9671-4cadf1692b85@github.com> Message-ID: On Mon, 15 Jun 2020 23:26:33 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Correcting the selection change events generated post sorting > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1815: > >> 1814: boolean isSortTreeOfSelectedItems() { >> 1815: return sortTreeOfSelectedItems; >> 1816: } > > This method / state attribute isn't really needed. The value is never set to anything other than `true`. I recommend > removing it. Corrected in the next commit.. > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 431: > >> 430: for (int j = 0; j < FIRST_LEVEL_COUNT - 1; j++) { >> 431: TreeItem tj = new TreeItem<>("" + i + j); >> 432: tj.setExpanded(true); > > The tree item strings will not be unique. This won't affect whether the test passes or fails, since `TreeItem` does not > override `equals`, but it might be better if the strings were unique (in case there ever was an error it would be > easier to understand). Hi Kevin, I verified the the tree item strings again. They seem to be unique. A total of 8800 of tree items get created each with unique string. Could you please recheck. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 17 11:38:45 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 17 Jun 2020 11:38:45 GMT Subject: [Rev 04] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Remove the un-required flag ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/244/files - new: https://git.openjdk.java.net/jfx/pull/244/files/e733a6c1..c70178cf Webrevs: - full: https://webrevs.openjdk.java.net/jfx/244/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/244/webrev.03-04 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/244/head:pull/244 PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 17 11:48:28 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 17 Jun 2020 11:48:28 GMT Subject: [Rev 03] RFR: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: <6PkXqtv8-Mv87VodFnTavpbSgJYF05k9vJHpHRSC-vs=.13a8567f-4a34-4aef-9671-4cadf1692b85@github.com> Message-ID: On Mon, 15 Jun 2020 23:41:08 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Correcting the selection change events generated post sorting > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 472: > >> 471: countSelectedIndexChangeEvent++; >> 472: assertEquals(selectedItemBefore, treeTableView.getTreeItem(sm.getSelectedIndex())); >> 473: }); > > If this assertion ever fails, I don't think it will cause a test failure, since the event handling code will swallow > the exception. The same is true of the other listeners. I don't know if it would be possible to use the > UncaughtExceptionHandler as is done in other tests -- see > [JDK-8244531](https://bugs.openjdk.java.net/browse/JDK-8244531) -- but that might be worth exploring. Another > possibility is to wrap all the listeners in a try/catch and keep a list of `Throwable`s that are caught. Hi Kevin, I tested these listeners by adding assert that always fail. It shows the failures correctly. Also in this file there are other tests which assert inside a listener. I confirmed that those tests also show failures correctly. I could not find out what makes it work though. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From github.com+7450507+fthevenet at openjdk.java.net Wed Jun 17 11:50:58 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 17 Jun 2020 11:50:58 GMT Subject: [Rev 09] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Removed trailing whitespaces ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/2951d538..82746316 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.09 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.08-09 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Wed Jun 17 11:50:59 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 17 Jun 2020 11:50:59 GMT Subject: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 15:55:25 GMT, Frederic Thevenet wrote: >> Overall, this looks quite good. In particular the tiled rendering, as implemented by the `renderTile` method, should be >> reasonably efficient. >> My only high-level comment is that I'm somewhat skeptical of `computeOptimumTileSize` to determine the size and >> direction of tiling. I note that in the case of an image that is tiled in both X and Y, there are at most 4 distinct >> tile sizes if it doesn't fit evenly. In the case where only one of X or Y is tiled, there are at most 2 distinct tile >> sizes. Here is an example: +-----------+-----------+ . +-------+ | | | . | | >> | M | M | . | R | >> | | | . | | >> +-----------+-----------+ . +-------+ >> | | | . | | >> | M | M | . | R | >> | | | . | | >> +-----------+-----------+ . +-------+ >> . . . . >> +-----------+-----------+ . +-------+ >> | | | . | | >> | M | M | . | R | >> | | | . | | >> +-----------+-----------+ . +-------+ >> | B | B | . | C | >> +-----------+-----------+ . +-------+ >> >> Where `M` represents the middle set of tiles each with a size of `tileW x tileH`. `R` is the right hand column of >> tiles, `B` is bottom row, and `C` is corner. >> Recognizing this, I wonder if it might be better to always use the maximum tile size, but fill all of the middle tiles >> of that size first, and then pick up the right and/or bottom edges as needed. This will minimize thrashing (no more >> than 3 changes of tile size), while avoiding the more complicated logic that tries to keep the tiles all the same size >> at the cost of smaller tiles, and which has to fall back to using uneven tiles anyway. If you do it this way, there is >> also no need to have code that switches the order of the inner loop. It will naturally handle that. Either way, I'd >> like to see some additional system tests that cover all of the cases of X and Y fitting/not-fitting exactly (and if you >> stick with your current approach, X or Y as the inner loop). I left a couple inline comments as well. > >> [...] I'd like to see some additional system tests that cover all of the cases of X and Y fitting/not-fitting exactly >> (and if you stick with your current approach, X or Y as the inner loop). > > What kind of tests do you have in mind? More specifically do you mean simply adding tests that expand on the existing > `doTestSnapshotScaleNodeDefer`and `doTestSnapshotScaleNodeImm` (which basically just prove that taking a snapshot > returns a non-null image of the expected size)? Or do you think we need to include a test that proves the snapshot > produced by tiling is entirely faithful to the original, pixel-wise? I went ahead and wrote a bunch of tests that: 1. Setup a scene to display an `ImageView` of a selected dimensions chosen to trigger tiling in different ways when taking snapshots. 2. Fill up the image with noise. 3. Take a snapshot and do a pixel-wise comparison with the original image. I've added the new tests to the existing `Snapshot2Test.java`. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Wed Jun 17 12:31:00 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Jun 2020 12:31:00 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v5] In-Reply-To: References: Message-ID: <2hjiSautqrqvDzeddO6LFsllP1zcb0Hp93NuZegs7p0=.bb6f2e7f-8bc3-489d-b342-f8f20dd45ddf@github.com> On Wed, 17 Jun 2020 11:38:45 GMT, Ambarish Rapte wrote: >> Issue: >> In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not >> retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using >> `setAll()`). Cause: >> >> 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. >> 2. The indices from these TreeModificationEvents are not reliable. >> 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor >> results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of >> sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the >> selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or >> collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues >> combine in wrong update of the selection. Fix: >> >> 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the >> TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is >> almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change >> events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as >> before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change >> events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` >> Verification: >> The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the >> change should not cause any other failures. Added unit tests which fail before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Remove the un-required flag Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Wed Jun 17 12:31:03 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Jun 2020 12:31:03 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v4] In-Reply-To: References: <6PkXqtv8-Mv87VodFnTavpbSgJYF05k9vJHpHRSC-vs=.13a8567f-4a34-4aef-9671-4cadf1692b85@github.com> Message-ID: On Wed, 17 Jun 2020 11:46:07 GMT, Ambarish Rapte wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 472: >> >>> 471: countSelectedIndexChangeEvent++; >>> 472: assertEquals(selectedItemBefore, treeTableView.getTreeItem(sm.getSelectedIndex())); >>> 473: }); >> >> If this assertion ever fails, I don't think it will cause a test failure, since the event handling code will swallow >> the exception. The same is true of the other listeners. I don't know if it would be possible to use the >> UncaughtExceptionHandler as is done in other tests -- see >> [JDK-8244531](https://bugs.openjdk.java.net/browse/JDK-8244531) -- but that might be worth exploring. Another >> possibility is to wrap all the listeners in a try/catch and keep a list of `Throwable`s that are caught. > > Hi Kevin, I tested these listeners by adding assert that always fail. It shows the failures correctly. Also in this > file there are other tests which assert inside a listener. I confirmed that those tests also show failures correctly. I > could not find out what makes it work though. I can confirm that the test fails if an assertion hits. The reason is that this ChangeListener throws any exception to the code that causes the change, so it will propagate to the test thread. >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 431: >> >>> 430: for (int j = 0; j < FIRST_LEVEL_COUNT - 1; j++) { >>> 431: TreeItem tj = new TreeItem<>("" + i + j); >>> 432: tj.setExpanded(true); >> >> The tree item strings will not be unique. This won't affect whether the test passes or fails, since `TreeItem` does not >> override `equals`, but it might be better if the strings were unique (in case there ever was an error it would be >> easier to understand). > > Hi Kevin, I verified the the tree item strings again. They seem to be unique. A total of 8800 of tree items get created > each with unique string. Could you please recheck. Confirmed. This was my mistake. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Wed Jun 17 12:31:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Jun 2020 12:31:52 GMT Subject: RFR: 8247163: JFXPanel throws exception on click when no Scene is set [v2] In-Reply-To: References: Message-ID: On Tue, 16 Jun 2020 07:34:13 GMT, Florian Kirmaier wrote: >> Fixing exception when clicking on JFXPanel when no Scene is set. >> >> quick test: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests: test --tests *javafx.embed.swing.JFXPan* --info` >> >> It's a regression from my previous PR: https://github.com/openjdk/jfx/pull/25 > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8247163: > Added space based on code review Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/248 From github.com+7450507+fthevenet at openjdk.java.net Wed Jun 17 13:21:15 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Wed, 17 Jun 2020 13:21:15 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v11] In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Changed wrong value for image size (for these tests we *don't* want it to be dividable by 2 nor 3) ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/82746316..4752d83e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.10 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.09-10 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From kevin.rushforth at oracle.com Wed Jun 17 13:49:36 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jun 2020 06:49:36 -0700 Subject: Result: New OpenJFX Reviewer: Nir Lisker Message-ID: Voting for Nir Lisker [1] to OpenJFX Reviewer [2] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#nlisker [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-June/026609.html From fkirmaier at openjdk.java.net Wed Jun 17 15:21:50 2020 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 17 Jun 2020 15:21:50 GMT Subject: Integrated: 8247163: JFXPanel throws exception on click when no Scene is set In-Reply-To: References: Message-ID: On Tue, 9 Jun 2020 10:39:29 GMT, Florian Kirmaier wrote: > Fixing exception when clicking on JFXPanel when no Scene is set. > > quick test: `./gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests: test --tests *javafx.embed.swing.JFXPan* --info` > > It's a regression from my previous PR: https://github.com/openjdk/jfx/pull/25 This pull request has now been integrated. Changeset: 1727dfa4 Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/1727dfa4 Stats: 22 lines in 2 files changed: 0 ins; 20 del; 2 mod 8247163: JFXPanel throws exception on click when no Scene is set Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/248 From prr at openjdk.java.net Wed Jun 17 15:47:08 2020 From: prr at openjdk.java.net (Phil Race) Date: Wed, 17 Jun 2020 15:47:08 GMT Subject: RFR: 8208169: can not print selected pages of web page [v5] In-Reply-To: References: Message-ID: <-cos4-HklUxdOMu1Zw3wGUyuA-Es9aBEEyVLWKtGiG4=.b3586cbd-85f8-480e-ba7e-cd2f9677c71c@github.com> On Tue, 16 Jun 2020 07:59:02 GMT, Bhawesh Choudhary wrote: >> Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, >> which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing >> pages otherwise print all pages as usual. > > Bhawesh Choudhary has updated the pull request incrementally with one additional commit since the last revision: > > Formatting changes Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/222 From github.com+4208131+bhaweshkc at openjdk.java.net Wed Jun 17 19:05:21 2020 From: github.com+4208131+bhaweshkc at openjdk.java.net (Bhawesh Choudhary) Date: Wed, 17 Jun 2020 19:05:21 GMT Subject: Integrated: 8208169: can not print selected pages of web page In-Reply-To: References: Message-ID: On Fri, 15 May 2020 16:36:29 GMT, Bhawesh Choudhary wrote: > Print function of WebEngine.java ignores page range setting and prints given number of pages starting from first page, > which is the root cause of this issue. To fix it, put check for page ranges and if it available, use it for printing > pages otherwise print all pages as usual. This pull request has now been integrated. Changeset: 8440b64b Author: bhawesh Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/8440b64b Stats: 159 lines in 2 files changed: 0 ins; 155 del; 4 mod 8208169: can not print selected pages of web page Reviewed-by: prr, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/222 From wurstsemmel at mailbox.org Thu Jun 18 08:51:33 2020 From: wurstsemmel at mailbox.org (wurstsemmel at mailbox.org) Date: Thu, 18 Jun 2020 10:51:33 +0200 Subject: OpenJFX: Follow HiDPI Scaling Settings in Fedora Workstation 32 (Gnome) Message-ID: <8e47f66576dc0ea57956fe3673782d73eeb0643a.camel@mailbox.org> Dear OpenJFX Developers, on Fedora 32 Workstation (Gnome) the AppImage from Cryptomator (cryptomator.org) does not follow the system-wide scale settings from Gnome Settings. *System Setup Linux: Fedora Workstation 32 (Gnome) Hardware: Dell XPS 13 with HiDPI (200 % scaling) Cryptomator version: 1.5.5-x86_64 AppImage *Expected Behavior App window should scale according to system-wide settings. *Actual Behavior App window scales at 100 %. *Two workarounds exist: $gsettings set org.gnome.desktop.interface scaling-factor 2 $GDK_SCALE=2 ./cryptomator-1.5.5-x86_64.AppImage According to the developers from Cryptomator (see https://github.com/cryptomator/cryptomator/issues/1242#issuecomment-643095195 ) this is a bug which was intended to be fixed with https://bugs.openjdk.java.net/browse/JDK-8137050. However, the bug still occurs in OpenJFX 14.0.1 and 11. I am happy to help if anything is unclear. Please re-open the bug JDK- 8137050 and make OpenJFX follow the system-wide scaling settings in Gnome. Thank you! wurstsemmel From kevin.rushforth at oracle.com Thu Jun 18 12:12:32 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jun 2020 05:12:32 -0700 Subject: OpenJFX: Follow HiDPI Scaling Settings in Fedora Workstation 32 (Gnome) In-Reply-To: <8e47f66576dc0ea57956fe3673782d73eeb0643a.camel@mailbox.org> References: <8e47f66576dc0ea57956fe3673782d73eeb0643a.camel@mailbox.org> Message-ID: <5339b584-96fe-5fc2-7e9c-a924eed72b1b@oracle.com> We will need a new bug ID for this (we never reuse a bug ID for which a commit has been pushed). You can file a new bug, mentioning JDK-8137050 in the Description, at: https://bugreport.java.com/ Question for other Linux users on this list: are any of you using a Linux machine with Hi-DPI scaling? Is it detecting it properly or do you have to set the scaling property (either via gsettings or the GDI_SCALE env variable)? yourself? -- Kevin On 6/18/2020 1:51 AM, wurstsemmel at mailbox.org wrote: > Dear OpenJFX Developers, > > on Fedora 32 Workstation (Gnome) the AppImage from Cryptomator > (cryptomator.org) does not follow the system-wide scale settings from > Gnome Settings. > > *System Setup > Linux: Fedora Workstation 32 (Gnome) > Hardware: Dell XPS 13 with HiDPI (200 % scaling) > Cryptomator version: 1.5.5-x86_64 AppImage > > *Expected Behavior > App window should scale according to system-wide settings. > > *Actual Behavior > App window scales at 100 %. > > *Two workarounds exist: > $gsettings set org.gnome.desktop.interface scaling-factor 2 > $GDK_SCALE=2 ./cryptomator-1.5.5-x86_64.AppImage > > According to the developers from Cryptomator (see > https://github.com/cryptomator/cryptomator/issues/1242#issuecomment-643095195 > ) this is a bug which was intended to be fixed with > https://bugs.openjdk.java.net/browse/JDK-8137050. However, the bug > still occurs in OpenJFX 14.0.1 and 11. > > I am happy to help if anything is unclear. Please re-open the bug JDK- > 8137050 and make OpenJFX follow the system-wide scaling settings in > Gnome. > > Thank you! > > wurstsemmel > > > > > From philip.race at oracle.com Thu Jun 18 16:26:21 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Jun 2020 09:26:21 -0700 Subject: OpenJFX: Follow HiDPI Scaling Settings in Fedora Workstation 32 (Gnome) In-Reply-To: <5339b584-96fe-5fc2-7e9c-a924eed72b1b@oracle.com> References: <8e47f66576dc0ea57956fe3673782d73eeb0643a.camel@mailbox.org> <5339b584-96fe-5fc2-7e9c-a924eed72b1b@oracle.com> Message-ID: <5EEB95AD.90407@oracle.com> Although we only support integer scaling on Linux you have 200% which should work. So sounds like it could be a breaking change in Fedora, where it passes around / defines the scale in some new setting and doesn't set the old ones needed for compatibility. > (either via gsettings or the GDI_SCALE env variable) GDK_SCALE, not GDI_SCALE -phil On 6/18/20, 5:12 AM, Kevin Rushforth wrote: > We will need a new bug ID for this (we never reuse a bug ID for which > a commit has been pushed). You can file a new bug, mentioning > JDK-8137050 in the Description, at: > > https://bugreport.java.com/ > > Question for other Linux users on this list: are any of you using a > Linux machine with Hi-DPI scaling? Is it detecting it properly or do > you have to set the scaling property (either via gsettings or the > GDI_SCALE env variable) yourself? > > -- Kevin > > > On 6/18/2020 1:51 AM, wurstsemmel at mailbox.org wrote: >> Dear OpenJFX Developers, >> >> on Fedora 32 Workstation (Gnome) the AppImage from Cryptomator >> (cryptomator.org) does not follow the system-wide scale settings from >> Gnome Settings. >> >> *System Setup >> Linux: Fedora Workstation 32 (Gnome) >> Hardware: Dell XPS 13 with HiDPI (200 % scaling) >> Cryptomator version: 1.5.5-x86_64 AppImage >> >> *Expected Behavior >> App window should scale according to system-wide settings. >> >> *Actual Behavior >> App window scales at 100 %. >> >> *Two workarounds exist: >> $gsettings set org.gnome.desktop.interface scaling-factor 2 >> $GDK_SCALE=2 ./cryptomator-1.5.5-x86_64.AppImage >> >> According to the developers from Cryptomator (see >> https://github.com/cryptomator/cryptomator/issues/1242#issuecomment-643095195 >> >> ) this is a bug which was intended to be fixed with >> https://bugs.openjdk.java.net/browse/JDK-8137050. However, the bug >> still occurs in OpenJFX 14.0.1 and 11. >> >> I am happy to help if anything is unclear. Please re-open the bug JDK- >> 8137050 and make OpenJFX follow the system-wide scaling settings in >> Gnome. >> >> Thank you! >> >> wurstsemmel >> >> >> >> >> > From kevin.rushforth at oracle.com Thu Jun 18 16:37:53 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jun 2020 09:37:53 -0700 Subject: OpenJFX: Follow HiDPI Scaling Settings in Fedora Workstation 32 (Gnome) In-Reply-To: <5EEB95AD.90407@oracle.com> References: <8e47f66576dc0ea57956fe3673782d73eeb0643a.camel@mailbox.org> <5339b584-96fe-5fc2-7e9c-a924eed72b1b@oracle.com> <5EEB95AD.90407@oracle.com> Message-ID: <3da756b8-a849-e694-4e17-899b9db1f4fb@oracle.com> On 6/18/2020 9:26 AM, Philip Race wrote: > Although we only support integer scaling on Linux you have 200% which > should work. > So sounds like it could be a breaking change in Fedora, where it > passes around / defines > the scale in some new setting and doesn't set the old ones needed for > compatibility. That could be. >> ?(either via gsettings or the GDI_SCALE env variable) > > GDK_SCALE, not GDI_SCALE Oops. :)? Of course. -- Kevin > > -phil > > > > On 6/18/20, 5:12 AM, Kevin Rushforth wrote: >> We will need a new bug ID for this (we never reuse a bug ID for which >> a commit has been pushed). You can file a new bug, mentioning >> JDK-8137050 in the Description, at: >> >> https://bugreport.java.com/ >> >> Question for other Linux users on this list: are any of you using a >> Linux machine with Hi-DPI scaling? Is it detecting it properly or do >> you have to set the scaling property (either via gsettings or the >> GDI_SCALE env variable)? yourself? >> >> -- Kevin >> >> >> On 6/18/2020 1:51 AM, wurstsemmel at mailbox.org wrote: >>> Dear OpenJFX Developers, >>> >>> on Fedora 32 Workstation (Gnome) the AppImage from Cryptomator >>> (cryptomator.org) does not follow the system-wide scale settings from >>> Gnome Settings. >>> >>> *System Setup >>> Linux: Fedora Workstation 32 (Gnome) >>> Hardware: Dell XPS 13 with HiDPI (200 % scaling) >>> Cryptomator version: 1.5.5-x86_64 AppImage >>> >>> *Expected Behavior >>> App window should scale according to system-wide settings. >>> >>> *Actual Behavior >>> App window scales at 100 %. >>> >>> *Two workarounds exist: >>> $gsettings set org.gnome.desktop.interface scaling-factor 2 >>> $GDK_SCALE=2 ./cryptomator-1.5.5-x86_64.AppImage >>> >>> According to the developers from Cryptomator (see >>> https://github.com/cryptomator/cryptomator/issues/1242#issuecomment-643095195 >>> >>> ) this is a bug which was intended to be fixed with >>> https://bugs.openjdk.java.net/browse/JDK-8137050. However, the bug >>> still occurs in OpenJFX 14.0.1 and 11. >>> >>> I am happy to help if anything is unclear. Please re-open the bug JDK- >>> 8137050 and make OpenJFX follow the system-wide scaling settings in >>> Gnome. >>> >>> Thank you! >>> >>> wurstsemmel >>> >>> >>> >>> >>> >> From kevin.rushforth at oracle.com Thu Jun 18 16:38:01 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jun 2020 09:38:01 -0700 Subject: Proposed schedule for JavaFX 15 In-Reply-To: References: Message-ID: <94814ae6-dd2c-ee3f-5d5f-bc0007901172@oracle.com> As a reminder, RDP1 for JavaFX 15 starts on July 2, 2020 at 16:00 UTC (09:00 Pacific time), which is two weeks from today. Please allow sufficient time for any feature that needs a CSR. New features should be far enough along in the review process that you can finalize the CSR before Thursday, June 25, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 16. During rampdown of JavaFX 15, the "master" branch of the jfx repo will be open for JavaFX 16 fixes. We will follow the same process as previous releases for getting fixes into JavaFX 15 during rampdown. I'll send a message with detailed information later, but candidates for fixing during RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc bugs of any priority. Some small enhancements might be considered during RDP1, but they require explicit approval; the bar will be high for such requests. -- Kevin On 3/12/2020 10:11 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 15. > > RDP1: Jul 2, 2020 (aka ?feature freeze?) > RDP2: Jul 30, 2020 > Freeze: Aug 20, 2020 > GA: September 8, 2020 > > We plan to fork a jfx15 stabilization branch at RDP1. The GA date is > expected to be one week ahead of JDK 15, matching what we did for 14. > > As a slight change from previous releases, the start of RDP1, the > start of RDP2, and the code freeze will be 16:00 UTC on the respective > dates. > > Please let Johan or me know if you have any questions. > > -- Kevin > From arapte at openjdk.java.net Thu Jun 18 16:41:15 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 18 Jun 2020 16:41:15 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call Message-ID: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong reference to the returned UnmodifiableObservableSet. So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. Added a small unit test. and, Altered(minor) a test which was modified in past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be updated in view of this change. ------------- Commit messages: - 8214699: Node.getPseudoClassStates must return the same instance on every call Changes: https://git.openjdk.java.net/jfx/pull/253/files Webrev: https://webrevs.openjdk.java.net/jfx/253/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8214699 Stats: 19 lines in 3 files changed: 9 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/253.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/253/head:pull/253 PR: https://git.openjdk.java.net/jfx/pull/253 From kcr at openjdk.java.net Thu Jun 18 23:22:52 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Jun 2020 23:22:52 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v2] In-Reply-To: References: <5nK7rqiVIiR0-3z26cwaWJFfVGmUwuaz5OeYXnicOBU=.ff2d9fb7-6008-4cb0-a56c-9883b54f29b9@github.com> Message-ID: On Tue, 26 May 2020 23:27:07 GMT, Kevin Rushforth wrote: >> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >> >> Reword the compile processing instructions (replace 'Hint' with 'Note:', adjust text to context), remove spurious empty >> line in script example code. > > Here are a couple overall comments. > > 1. Please update the Description of this PR now that this is no longer WIP. Also, can you copy any relevant information > from PR #187 so that this PR is standalone (reviewers shouldn't have to go to the earlier PRs for any information)? > 2. The text you provided for the CSR is a good start, so I created a Draft CSR, > [JDK-8245873](https://bugs.openjdk.java.net/browse/JDK-8245873), based on what you have. I'll have additional comments > later, but one thing I noticed that needs to be added is that the "Specification" section needs to list the diffs for > the public API docs in FXMLLoader and for the FXML intro. I also left some inline comments below. I haven't done a > code review yet because I want to get the API documentation and CSR in shape first. @ronyfla the current API changes look good to me. I have updated the [CSR](https://bugs.openjdk.java.net/browse/JDK-8245873) to match what you have in [this comment](https://github.com/openjdk/jfx/pull/192#issuecomment-627464623) and [this comment](https://github.com/openjdk/jfx/pull/192#issuecomment-627863048), and I added the spec diffs. I had to add code-style markup to the following from your first comment so it would show up (it doesn't show up in your comment either): `("" or "")`. Please look it over and see if I missed anything. I will then "Submit" the CSR on your behalf to get an initial review from the CSR chair. In parallel with that, @aghaisas and myself can review the CSR in detail, and then the implementation. ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Fri Jun 19 00:06:51 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Jun 2020 00:06:51 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v3] In-Reply-To: References: Message-ID: On Thu, 4 Jun 2020 15:44:49 GMT, Rony G. Flatscher wrote: >> This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The >> PI data is turned into a boolean value using "Boolean.parseBoolean(String)". >> This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if >> the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case >> compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be >> done without compilation. Because of the fallback scripts get compiled with this version by default. >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> ### Issue >> * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement >> javax.script.Compilable compile scripts >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` >> `$ git checkout pull/192` > > Rony G. Flatscher has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 27 commits: > - Updates to meet Kevin's comment in PR 192 as of May 27th. > - Merge remote-tracking branch 'upstream/master' into scriptCompilablePIcompileFallback > - Reword the compile processing instructions (replace 'Hint' with 'Note:', adjust text to context), remove spurious empty > line in script example code. > - Document the compile processing instruction for scripts. > - Add missing language processing instruction. > - Correct typo, replace tabs, remove trailing blanks. > - Make sure we test the default behaviour to compile script by leaving out the compile PI. > - Revert temporary rename of test method. > - Correct ModuleLauncherTest (remove non-existing test), correct formatting. > - Always supply the script's filename in the error message first to further ease spotting the location of script > exceptions. > - ... and 17 more: https://git.openjdk.java.net/jfx/compare/6bd0e22d...7ef1bd68 I reviewed the implementation, and I think this is close to being ready, but I have a couple questions. I also still need to review the test and run it, but that will be later. I also noticed a few places with minor formatting issues -- mostly missing spaces and extra blank lines added to some files, but also `else {` when it should be `} else {`. I'll wait until the substantive part of the review is done to note them all (so if you can fix them ahead of time, that would be good). modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1571: > 1570: StringBuilder sb = new StringBuilder(); > 1571: char[] charBuffer = new char[4096]; > 1572: int n; Since you use the constant `4096` in three places (although it will be two once you fix the below bug), I recommend to either define a `final int` constant or else to use `charBuffer.length` as the size. modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1578: > 1577: } > 1578: } while (n == 4096); > 1579: script = sb.toString(); You can't assume that you are done if `Reader::read` returns less than what you asked for. You need to keep reading `while (n >= 0)`. modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1769: > 1768: try { > 1769: if (isCompiled) { > 1770: compiledScript.eval(localBindings); I think there may be other places you need to set isCompiled (it isn't set in the first couple of methods where you compile scripts). Can you check this? ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From wurstsemmel at mailbox.org Fri Jun 19 11:29:35 2020 From: wurstsemmel at mailbox.org (wurstsemmel at mailbox.org) Date: Fri, 19 Jun 2020 13:29:35 +0200 Subject: OpenJFX: Follow HiDPI Scaling Settings in Fedora Workstation 32 (Gnome) In-Reply-To: <3da756b8-a849-e694-4e17-899b9db1f4fb@oracle.com> References: <8e47f66576dc0ea57956fe3673782d73eeb0643a.camel@mailbox.org> <5339b584-96fe-5fc2-7e9c-a924eed72b1b@oracle.com> <5EEB95AD.90407@oracle.com> <3da756b8-a849-e694-4e17-899b9db1f4fb@oracle.com> Message-ID: Dear Kevin, Dear Phil, thank you for your quick responses. I submitted a bug report (internal review ID: 9065523). Within the description I listed JDK-8137050 and additionally bug reports from Cryptomator which describe the issue also in Ubuntu 20.04 LTS and pop!OS. Kind regards and thanks, wurstsemmel Am Donnerstag, den 18.06.2020, 09:37 -0700 schrieb Kevin Rushforth: > > On 6/18/2020 9:26 AM, Philip Race wrote: > > Although we only support integer scaling on Linux you have 200% > > which > > should work. > > So sounds like it could be a breaking change in Fedora, where it > > passes around / defines > > the scale in some new setting and doesn't set the old ones needed > > for > > compatibility. > > That could be. > > > > (either via gsettings or the GDI_SCALE env variable) > > > > GDK_SCALE, not GDI_SCALE > > Oops. :) Of course. > > -- Kevin > > > > -phil > > > > > > > > On 6/18/20, 5:12 AM, Kevin Rushforth wrote: > > > We will need a new bug ID for this (we never reuse a bug ID for > > > which > > > a commit has been pushed). You can file a new bug, mentioning > > > JDK-8137050 in the Description, at: > > > > > > https://bugreport.java.com/ > > > > > > Question for other Linux users on this list: are any of you using > > > a > > > Linux machine with Hi-DPI scaling? Is it detecting it properly or > > > do > > > you have to set the scaling property (either via gsettings or > > > the > > > GDI_SCALE env variable) yourself? > > > > > > -- Kevin > > > > > > > > > On 6/18/2020 1:51 AM, wurstsemmel at mailbox.org wrote: > > > > Dear OpenJFX Developers, > > > > > > > > on Fedora 32 Workstation (Gnome) the AppImage from Cryptomator > > > > (cryptomator.org) does not follow the system-wide scale > > > > settings from > > > > Gnome Settings. > > > > > > > > *System Setup > > > > Linux: Fedora Workstation 32 (Gnome) > > > > Hardware: Dell XPS 13 with HiDPI (200 % scaling) > > > > Cryptomator version: 1.5.5-x86_64 AppImage > > > > > > > > *Expected Behavior > > > > App window should scale according to system-wide settings. > > > > > > > > *Actual Behavior > > > > App window scales at 100 %. > > > > > > > > *Two workarounds exist: > > > > $gsettings set org.gnome.desktop.interface scaling-factor 2 > > > > $GDK_SCALE=2 ./cryptomator-1.5.5-x86_64.AppImage > > > > > > > > According to the developers from Cryptomator (see > > > > https://github.com/cryptomator/cryptomator/issues/1242#issuecomment-643095195 > > > > > > > > ) this is a bug which was intended to be fixed with > > > > https://bugs.openjdk.java.net/browse/JDK-8137050. However, the > > > > bug > > > > still occurs in OpenJFX 14.0.1 and 11. > > > > > > > > I am happy to help if anything is unclear. Please re-open the > > > > bug JDK- > > > > 8137050 and make OpenJFX follow the system-wide scaling > > > > settings in > > > > Gnome. > > > > > > > > Thank you! > > > > > > > > wurstsemmel > > > > > > > > > > > > > > > > > > > > From github.com+7450507+fthevenet at openjdk.java.net Fri Jun 19 12:39:06 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Fri, 19 Jun 2020 12:39:06 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v12] In-Reply-To: References: Message-ID: <3i8q7eHZAFnFg00Lbi61LxKeczILjzJm2yEPh_mgZTo=.0aa71190-23ee-4253-b989-53c71014ca33@github.com> > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Crawling pixels in writableImage with parallel stream is a bad idea. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/4752d83e..a01aaa20 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.11 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.10-11 Stats: 16 lines in 1 file changed: 7 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From sam.hutchins at screamingfrog.co.uk Fri Jun 19 13:49:02 2020 From: sam.hutchins at screamingfrog.co.uk (Sam Hutchins) Date: Fri, 19 Jun 2020 13:49:02 +0000 Subject: JavaFX HiDPI layout bugs Message-ID: <2029AC74-7F26-40D4-AAA1-39890FA2FC3D@screamingfrog.co.uk> Hi, I've been doing some investigation into a layout bug in JavaFX on Windows with non-integer scaling values. I think it's related to JDK-8199592, and I've put a small example that will reproduce these layout bugs at the end of this email. The most obvious layout error is truncation of labels in many controls. I've used CheckBoxes in this example, but the truncation errors are apparent in any labeled control. I suspect the issue affects other controls too (and probably the entire layout), but in more subtle ways. With scaling values of 1.25 or 1.5, the label truncation only happens in the dialog box. At 1.75 the issue is apparent in both windows. I _think_ the issue is a combination of caching and invalid calculations. I stepped through the `layoutLabelInArea(x, y, w, h, alignment)` method in LabeledSkinBase and found that 3 layout passes take place. In the first and second passes, all the layout calculations appear to be done without taking scaling into account. The 3rd pass appears to be when a scene is involved, and the snap* methods start having an impact. It looks like some values are scaled appropriately, but others are still using the pre-scene cached values. In particular, the call to `leftLabelPadding()` returns 5 for the first 2 passes, but 5.6 in the 3rd (at 1.25 scaling). The value of `w` doesn't change though, and that .6 increase in padding causes the label to be truncated. When you interact with the CheckBox to trigger a 4th layout, the value of `w` is increased by .6, and the layout appears to work as expected. I've hacked some of the caching out of `Parent` by adding a call to clearSizeCache() to the start of the `prefWidth(height)` and `prefHeight(width)` methods, which forces JavaFX to re-compute everything on every call. This resolves the issues for simple layouts at 1.25 and 1.5 scaling (but not 1.75). This doesn't resolve issues in more complicated layouts, however, as many subclasses of `Parent` have caching of their own. For example, controls in GridPanes will still exhibit this behaviour. I've hacked some caching out of that by removing the early return in the `computePrefHeights(widths)` and `computePrefWidths(heights)` methods, which resolves it for the GridPane case. I imagine there are many other instances where these cached values aren't correctly invalidated. I think there's also a fundamental issue with the layout calculations with non-integer scaling, as the layout is _always_ wrong at 1.75. I suspect that the layout calculations are always wrong, but the error at lower scaling values isn't enough to cause visible issues after pixel snapping. I'm not really sure where to go from here, as I'm not at all familiar with how and when JavaFX invalidates its layout calculations. If anyone can point me at some other threads to pull, I'd be grateful. Thanks, Sam Code to reproduce: import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Alert; import javafx.scene.control.Button; import javafx.scene.control.ButtonType; import javafx.scene.control.CheckBox; import javafx.scene.layout.GridPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class LayoutBug { public static void main(String[] args) { System.setProperty("glass.win.uiScale", "1.5"); Application.launch(MainWindow.class); } public static class MainWindow extends Application { public void start(final Stage primaryStage) { final var button = new Button("Show Dialog"); button.setOnAction(e -> { final var alert = new Alert(Alert.AlertType.NONE); alert.initOwner(primaryStage); alert.getButtonTypes().add(ButtonType.OK); alert.getDialogPane().setContent(createTestUi()); alert.show(); }); final var root = createTestUi(); root.getChildren().add(button); primaryStage.setScene(new Scene(root, 400, 600)); primaryStage.show(); } private VBox createTestUi() { final var gridPane = new GridPane(); gridPane.addRow(0, new CheckBox("Checkbox in gridpane")); return new VBox(10, gridPane, new CheckBox("Checkbox outside gridpane")); } } } From johan.vos at gluonhq.com Fri Jun 19 14:32:07 2020 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 19 Jun 2020 16:32:07 +0200 Subject: backport requests for 11.0.8 Message-ID: Hi Kevin, I request approval to backport the following fixes to OpenJFX 11 (11.0.8): JDK-8238249 : GetPrimitiveArrayCritical passed with hardcoded FALSE value JDK-8212034 : Potential memory leaks in jpegLoader.c in error case JDK-8241370 : Crash in JPEGImageLoader after fix for JDK-8212034 JDK-8232811 : Dialog's preferred size no longer accommodates multi-line strings JDK-8237782 : Only read advances up to the minimum of the numHorMetrics or the available font data. JDK-8237833 : Check glyph size before adding to glyph texture cache. JDK-8237944 : webview native cl "-m32" unknown option for windows 32-bit build JDK-8189092 : ArrayIndexOutOfBoundsException on Linux in getCachedGlyph JDK-8242106 : [macos] Remove obsolete GlassView2D.m class JDK-8236685 : [macOs] Remove obsolete file dialog subclasses All patches apply clean (if applied in this order). - Johan From kevin.rushforth at oracle.com Fri Jun 19 15:49:28 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Jun 2020 08:49:28 -0700 Subject: backport requests for 11.0.8 In-Reply-To: References: Message-ID: +1 On 6/19/2020 7:32 AM, Johan Vos wrote: > Hi Kevin, > > I request approval to backport the following fixes to OpenJFX 11 (11.0.8): > > JDK-8238249 : > GetPrimitiveArrayCritical passed with hardcoded FALSE value > JDK-8212034 : Potential > memory leaks in jpegLoader.c in error case > JDK-8241370 : Crash in > JPEGImageLoader after fix for JDK-8212034 > JDK-8232811 : Dialog's > preferred size no longer accommodates multi-line strings > JDK-8237782 : Only read > advances up to the minimum of the numHorMetrics or the available font data. > JDK-8237833 : Check glyph > size before adding to glyph texture cache. > JDK-8237944 : webview > native cl "-m32" unknown option for windows 32-bit build > JDK-8189092 : > ArrayIndexOutOfBoundsException on Linux in getCachedGlyph > JDK-8242106 : [macos] > Remove obsolete GlassView2D.m class > JDK-8236685 : [macOs] > Remove obsolete file dialog subclasses > > All patches apply clean (if applied in this order). > > - Johan From github.com+60214806+ronyfla at openjdk.java.net Fri Jun 19 16:04:18 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Fri, 19 Jun 2020 16:04:18 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jun 2020 00:04:37 GMT, Kevin Rushforth wrote: >> Rony G. Flatscher has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 27 commits: >> - Updates to meet Kevin's comment in PR 192 as of May 27th. >> - Merge remote-tracking branch 'upstream/master' into scriptCompilablePIcompileFallback >> - Reword the compile processing instructions (replace 'Hint' with 'Note:', adjust text to context), remove spurious empty >> line in script example code. >> - Document the compile processing instruction for scripts. >> - Add missing language processing instruction. >> - Correct typo, replace tabs, remove trailing blanks. >> - Make sure we test the default behaviour to compile script by leaving out the compile PI. >> - Revert temporary rename of test method. >> - Correct ModuleLauncherTest (remove non-existing test), correct formatting. >> - Always supply the script's filename in the error message first to further ease spotting the location of script >> exceptions. >> - ... and 17 more: https://git.openjdk.java.net/jfx/compare/6bd0e22d...7ef1bd68 > > I reviewed the implementation, and I think this is close to being ready, but I have a couple questions. I also still > need to review the test and run it, but that will be later. > I also noticed a few places with minor formatting issues -- mostly missing spaces and extra blank lines added to some > files, but also `else {` when it should be `} else {`. I'll wait until the substantive part of the review is done to > note them all (so if you can fix them ahead of time, that would be good). @CSR-update: looks good! > modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1769: > >> 1768: try { >> 1769: if (isCompiled) { >> 1770: compiledScript.eval(localBindings); > > I think there may be other places you need to set isCompiled (it isn't set in the first couple of methods where you > compile scripts). Can you check this? isCompiled gets set explicitly to false at object creation time. It only will be changed to true, if the script was successfully compiled. ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From github.com+60214806+ronyfla at openjdk.java.net Fri Jun 19 16:04:16 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Fri, 19 Jun 2020 16:04:16 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v4] In-Reply-To: References: Message-ID: > This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The > PI data is turned into a boolean value using "Boolean.parseBoolean(String)". > This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if > the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case > compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be > done without compilation. Because of the fallback scripts get compiled with this version by default. > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > ### Issue > * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement > javax.script.Compilable compile scripts > > > ### Download > `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` > `$ git checkout pull/192` Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: Incorporating Kevin's review comments (final int, fix for loop test, correct formatting). ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/192/files - new: https://git.openjdk.java.net/jfx/pull/192/files/7ef1bd68..f2ea3d0e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/192/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/192/webrev.02-03 Stats: 15 lines in 1 file changed: 1 ins; 5 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/192.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192 PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Fri Jun 19 16:10:23 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Jun 2020 16:10:23 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jun 2020 15:49:36 GMT, Rony G. Flatscher wrote: >> modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1769: >> >>> 1768: try { >>> 1769: if (isCompiled) { >>> 1770: compiledScript.eval(localBindings); >> >> I think there may be other places you need to set isCompiled (it isn't set in the first couple of methods where you >> compile scripts). Can you check this? > > isCompiled gets set explicitly to false at object creation time. It only will be changed to true, if the script was > successfully compiled. I was (mistakenly) thinking of the `processStartElement` and `processEndElement` methods of the `ScriptElement` class, but that's a different class, and they use a local `compiledScript` variable. So this is fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Fri Jun 19 16:16:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Jun 2020 16:16:29 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jun 2020 15:49:43 GMT, Rony G. Flatscher wrote: > CSR-update: looks good! I have moved the CSR to the "proposed" state in preparation for formal review. ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Fri Jun 19 23:07:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Jun 2020 23:07:01 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v5] In-Reply-To: <2hjiSautqrqvDzeddO6LFsllP1zcb0Hp93NuZegs7p0=.bb6f2e7f-8bc3-489d-b342-f8f20dd45ddf@github.com> References: <2hjiSautqrqvDzeddO6LFsllP1zcb0Hp93NuZegs7p0=.bb6f2e7f-8bc3-489d-b342-f8f20dd45ddf@github.com> Message-ID: On Wed, 17 Jun 2020 12:28:41 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the un-required flag > > Marked as reviewed by kcr (Lead). Pending a second reviewer. @aghaisas or @kleopatra can one of you review it? ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Fri Jun 19 23:51:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Jun 2020 23:51:55 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call In-Reply-To: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Message-ID: On Thu, 18 Jun 2020 16:30:42 GMT, Ambarish Rapte wrote: > Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to > listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong > reference to the returned UnmodifiableObservableSet. > > So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every > call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. > > Added a small unit test. and, > Altered(minor) a test which was modified in > past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) > (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be > updated in view of this change. The fix looks good, given that `FXCollections.unmodifiableObservableSet()` wraps an observable set listens to changes to the backing set. Can you add a test to ensure that the listeners are getting called? modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 168: > 167: assertSame("getPseudoClassStates() should always return the same instance", > 168: node.getPseudoClassStates(), node.getPseudoClassStates()); > 169: } To make this more clear, I recommend to store the expected value in a local variable and then call assert. ------------- PR: https://git.openjdk.java.net/jfx/pull/253 From daniel.peintner at gmail.com Mon Jun 22 09:07:34 2020 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Mon, 22 Jun 2020 11:07:34 +0200 Subject: JavaFX HiDPI layout bugs In-Reply-To: <2029AC74-7F26-40D4-AAA1-39890FA2FC3D@screamingfrog.co.uk> References: <2029AC74-7F26-40D4-AAA1-39890FA2FC3D@screamingfrog.co.uk> Message-ID: Hi Sam, all, FYI: I have been encountering a similar behaviour but I have been *wrongly* thinking it relates to ControlsFX PropertySheet which uses labels also. see https://github.com/controlsfx/controlsfx/issues/1235 The sample with buttons works fine while PropertySheet does not work as expected. -- Daniel On Fri, Jun 19, 2020 at 3:52 PM Sam Hutchins < sam.hutchins at screamingfrog.co.uk> wrote: > Hi, > > I've been doing some investigation into a layout bug in JavaFX on Windows > with non-integer scaling values. I think it's related to JDK-8199592, and > I've put a small example that will reproduce these layout bugs at the end > of this email. The most obvious layout error is truncation of labels in > many controls. I've used CheckBoxes in this example, but the truncation > errors are apparent in any labeled control. I suspect the issue affects > other controls too (and probably the entire layout), but in more subtle > ways. With scaling values of 1.25 or 1.5, the label truncation only happens > in the dialog box. At 1.75 the issue is apparent in both windows. > > I _think_ the issue is a combination of caching and invalid calculations. > I stepped through the `layoutLabelInArea(x, y, w, h, alignment)` method in > LabeledSkinBase and found that 3 layout passes take place. > > In the first and second passes, all the layout calculations appear to be > done without taking scaling into account. > The 3rd pass appears to be when a scene is involved, and the snap* methods > start having an impact. It looks like some values are scaled appropriately, > but others are still using the pre-scene cached values. In particular, the > call to `leftLabelPadding()` returns 5 for the first 2 passes, but 5.6 in > the 3rd (at 1.25 scaling). The value of `w` doesn't change though, and that > .6 increase in padding causes the label to be truncated. When you interact > with the CheckBox to trigger a 4th layout, the value of `w` is increased by > .6, and the layout appears to work as expected. > > I've hacked some of the caching out of `Parent` by adding a call to > clearSizeCache() to the start of the `prefWidth(height)` and > `prefHeight(width)` methods, which forces JavaFX to re-compute everything > on every call. This resolves the issues for simple layouts at 1.25 and 1.5 > scaling (but not 1.75). > > This doesn't resolve issues in more complicated layouts, however, as many > subclasses of `Parent` have caching of their own. For example, controls in > GridPanes will still exhibit this behaviour. I've hacked some caching out > of that by removing the early return in the `computePrefHeights(widths)` > and `computePrefWidths(heights)` methods, which resolves it for the > GridPane case. I imagine there are many other instances where these cached > values aren't correctly invalidated. > > I think there's also a fundamental issue with the layout calculations with > non-integer scaling, as the layout is _always_ wrong at 1.75. I suspect > that the layout calculations are always wrong, but the error at lower > scaling values isn't enough to cause visible issues after pixel snapping. > > I'm not really sure where to go from here, as I'm not at all familiar with > how and when JavaFX invalidates its layout calculations. If anyone can > point me at some other threads to pull, I'd be grateful. > > Thanks, > > Sam > > > Code to reproduce: > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.control.Alert; > import javafx.scene.control.Button; > import javafx.scene.control.ButtonType; > import javafx.scene.control.CheckBox; > import javafx.scene.layout.GridPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > public class LayoutBug > { > public static void main(String[] args) > { > System.setProperty("glass.win.uiScale", "1.5"); > Application.launch(MainWindow.class); > } > public static class MainWindow extends Application > { > public void start(final Stage primaryStage) > { > final var button = new Button("Show Dialog"); > button.setOnAction(e -> > { > final var alert = new Alert(Alert.AlertType.NONE); > alert.initOwner(primaryStage); > alert.getButtonTypes().add(ButtonType.OK); > alert.getDialogPane().setContent(createTestUi()); > alert.show(); > }); > final var root = createTestUi(); > root.getChildren().add(button); > primaryStage.setScene(new Scene(root, 400, 600)); > primaryStage.show(); > } > private VBox createTestUi() > { > final var gridPane = new GridPane(); > gridPane.addRow(0, new CheckBox("Checkbox in gridpane")); > return new VBox(10, > gridPane, > new CheckBox("Checkbox outside gridpane")); > } > } > } > > From fastegal at openjdk.java.net Mon Jun 22 12:04:00 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 22 Jun 2020 12:04:00 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call In-Reply-To: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Message-ID: On Thu, 18 Jun 2020 16:30:42 GMT, Ambarish Rapte wrote: > Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to > listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong > reference to the returned UnmodifiableObservableSet. > > So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every > call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. > > Added a small unit test. and, > Altered(minor) a test which was modified in > past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) > (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be > updated in view of this change. Changes requested by fastegal (Committer). modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9371: > 9370: final ObservableSet unmodifiablePseudoClassStates = > 9371: FXCollections.unmodifiableObservableSet(pseudoClassStates); > 9372: /** the unmodifiable field can be private, or is there any reason for being package? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9375: > 9374: public final ObservableSet getPseudoClassStates() { > 9375: > 9376: return FXCollections.unmodifiableObservableSet(pseudoClassStates); missing override annotation (says my IDE :) - not entirely certain about guidelines here: it was missing before as well, but now might be a good time to fix it (except if we generally leave such cleanup to a dedicated cleanup commit) ------------- PR: https://git.openjdk.java.net/jfx/pull/253 From fastegal at openjdk.java.net Mon Jun 22 12:12:10 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 22 Jun 2020 12:12:10 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call In-Reply-To: References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Message-ID: On Fri, 19 Jun 2020 23:49:45 GMT, Kevin Rushforth wrote: >> Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to >> listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong >> reference to the returned UnmodifiableObservableSet. >> >> So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every >> call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. >> >> Added a small unit test. and, >> Altered(minor) a test which was modified in >> past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) >> (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be >> updated in view of this change. > > modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 168: > >> 167: assertSame("getPseudoClassStates() should always return the same instance", >> 168: node.getPseudoClassStates(), node.getPseudoClassStates()); >> 169: } > > To make this more clear, I recommend to store the expected value in a local variable and then call assert. would suggest some more tests (overcautious maybe, be have seen horses vomit at unbelievable places ;) Test that the returned set - is indeed unmodifiable - not gc'ed - is a wrapper around the backing set Test code: @Test(expected=UnsupportedOperationException.class) public void testPseudoClassesUnmodifiable() { Node node = new Rectangle(); node.getPseudoClassStates().add(PseudoClass.getPseudoClass("dummy")); } @Test public void testPseudoClassesNotGCed() { Node node = new Rectangle(); WeakReference> weakRef = new WeakReference<>(node.getPseudoClassStates()); ControlSkinFactory.attemptGC(weakRef); assertNotNull("pseudoClassStates must not be gc'ed", weakRef.get()); } // requires additional method in NodeShim @Test public void testUnmodifiablePseudoClassStatesEqualsBackingStates() { Rectangle node = new Rectangle(); PseudoClass pseudo = PseudoClass.getPseudoClass("somepseudo"); node.pseudoClassStateChanged(pseudo, true); assertEquals(1, node.getPseudoClassStates().size()); assertEquals(NodeShim.pseudoClassStates(node).size(), node.getPseudoClassStates().size()); assertTrue(NodeShim.pseudoClassStates(node).contains(pseudo)); assertTrue(node.getPseudoClassStates().contains(pseudo)); } ------------- PR: https://git.openjdk.java.net/jfx/pull/253 From fastegal at openjdk.java.net Mon Jun 22 12:12:10 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 22 Jun 2020 12:12:10 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call In-Reply-To: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Message-ID: On Thu, 18 Jun 2020 16:30:42 GMT, Ambarish Rapte wrote: > Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to > listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong > reference to the returned UnmodifiableObservableSet. > > So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every > call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. > > Added a small unit test. and, > Altered(minor) a test which was modified in > past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) > (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be > updated in view of this change. forgot to comment the test (can't seem to be able to add to a review?) ------------- Changes requested by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/253 From arapte at openjdk.java.net Tue Jun 23 10:33:05 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Jun 2020 10:33:05 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call [v2] In-Reply-To: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Message-ID: <3qJCWEwcHxxRjyX13KeHA8PlPqWacH_3p9DhSXHowis=.57840718-4370-41d1-8dcf-48304aee479c@github.com> > Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to > listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong > reference to the returned UnmodifiableObservableSet. > > So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every > call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. > > Added a small unit test. and, > Altered(minor) a test which was modified in > past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) > (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be > updated in view of this change. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review corrections ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/253/files - new: https://git.openjdk.java.net/jfx/pull/253/files/2c4cbfba..7eac1d30 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/253/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/253/webrev.00-01 Stats: 77 lines in 4 files changed: 75 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/253.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/253/head:pull/253 PR: https://git.openjdk.java.net/jfx/pull/253 From arapte at openjdk.java.net Tue Jun 23 10:33:09 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Jun 2020 10:33:09 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call [v2] In-Reply-To: References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Message-ID: On Mon, 22 Jun 2020 11:50:05 GMT, Jeanette Winzenburg wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> review corrections > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9375: > >> 9374: public final ObservableSet getPseudoClassStates() { >> 9375: >> 9376: return FXCollections.unmodifiableObservableSet(pseudoClassStates); > > missing override annotation (says my IDE :) - not entirely certain about guidelines here: it was missing before as > well, but now might be a good time to fix it (except if we generally leave such cleanup to a dedicated cleanup commit) Corrected in the next commit, please take a look. > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9371: > >> 9370: final ObservableSet unmodifiablePseudoClassStates = >> 9371: FXCollections.unmodifiableObservableSet(pseudoClassStates); >> 9372: /** > > the unmodifiable field can be private, or is there any reason for being package? It is not required to be package, changed it to private. ------------- PR: https://git.openjdk.java.net/jfx/pull/253 From arapte at openjdk.java.net Tue Jun 23 10:33:27 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Jun 2020 10:33:27 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call [v2] In-Reply-To: References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Message-ID: On Mon, 22 Jun 2020 12:08:21 GMT, Jeanette Winzenburg wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/NodeTest.java line 168: >> >>> 167: assertSame("getPseudoClassStates() should always return the same instance", >>> 168: node.getPseudoClassStates(), node.getPseudoClassStates()); >>> 169: } >> >> To make this more clear, I recommend to store the expected value in a local variable and then call assert. > > would suggest some more tests (overcautious maybe, be have seen horses vomit at unbelievable places ;) > > Test that the returned set > > - is indeed unmodifiable > - not gc'ed > - is a wrapper around the backing set > > Test code: > > @Test(expected=UnsupportedOperationException.class) > public void testPseudoClassesUnmodifiable() { > Node node = new Rectangle(); > node.getPseudoClassStates().add(PseudoClass.getPseudoClass("dummy")); > } > > @Test > public void testPseudoClassesNotGCed() { > Node node = new Rectangle(); > WeakReference> weakRef = new WeakReference<>(node.getPseudoClassStates()); > ControlSkinFactory.attemptGC(weakRef); > assertNotNull("pseudoClassStates must not be gc'ed", weakRef.get()); > } > > // requires additional method in NodeShim > @Test > public void testUnmodifiablePseudoClassStatesEqualsBackingStates() { > Rectangle node = new Rectangle(); > PseudoClass pseudo = PseudoClass.getPseudoClass("somepseudo"); > node.pseudoClassStateChanged(pseudo, true); > assertEquals(1, node.getPseudoClassStates().size()); > assertEquals(NodeShim.pseudoClassStates(node).size(), node.getPseudoClassStates().size()); > assertTrue(NodeShim.pseudoClassStates(node).contains(pseudo)); > assertTrue(node.getPseudoClassStates().contains(pseudo)); > } Corrected the existing test and added these new tests, with minor changes. ControlSkinFactory is a file from control tests. So have added a copy of `attemptGC()` method in `test.javafx.scene.shape.TestUtils` class. The class does not seem to be a perfect location for `attemptGC()`. But wanted to avoid a new util kind off class just for this one method. ------------- PR: https://git.openjdk.java.net/jfx/pull/253 From aghaisas at openjdk.java.net Tue Jun 23 10:48:35 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 23 Jun 2020 10:48:35 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v5] In-Reply-To: References: Message-ID: <4GQ_NgNUsqa9c8Q3QLxhdvpUow7pqB5EXqCbql6bGTA=.46727a51-efe6-46df-aba5-dd469acfd67d@github.com> On Wed, 17 Jun 2020 11:38:45 GMT, Ambarish Rapte wrote: >> Issue: >> In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not >> retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using >> `setAll()`). Cause: >> >> 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. >> 2. The indices from these TreeModificationEvents are not reliable. >> 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor >> results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of >> sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the >> selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or >> collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues >> combine in wrong update of the selection. Fix: >> >> 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the >> TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is >> almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change >> events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as >> before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change >> events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` >> Verification: >> The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the >> change should not cause any other failures. Added unit tests which fail before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Remove the un-required flag modules/javafx.controls/src/main/java/javafx/scene/control/TreeTablePosition.java line 79: > 78: } > 79: > 80: // Copy-like constructor with a different row. Suggest to add // Not public API before this description. (Similar to the constructor above this newly added constructor) modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1856: > 1855: Callback, Boolean> sortPolicy = getSortPolicy(); > 1856: if (sortPolicy == null) return; > 1857: Boolean success = sortPolicy.call(this); Do we need to set sortingInProgress to false before returning from here? ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From wurstsemmel at mailbox.org Tue Jun 23 10:50:06 2020 From: wurstsemmel at mailbox.org (wurstsemmel at mailbox.org) Date: Tue, 23 Jun 2020 12:50:06 +0200 Subject: OpenJFX: Follow HiDPI Scaling Settings in Fedora Workstation 32 (Gnome) In-Reply-To: References: <8e47f66576dc0ea57956fe3673782d73eeb0643a.camel@mailbox.org> <5339b584-96fe-5fc2-7e9c-a924eed72b1b@oracle.com> <5EEB95AD.90407@oracle.com> <3da756b8-a849-e694-4e17-899b9db1f4fb@oracle.com> Message-ID: <210537a100d768148d3f33cf6a774b9a481ee8c4.camel@mailbox.org> Dear Kevin, Dear Phil, Dear Developers, the bug is now listed as JDK-8248126 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8248126 . Kind regards, wurstsemmel Am Freitag, den 19.06.2020, 13:29 +0200 schrieb wurstsemmel at mailbox.org: > Dear Kevin, Dear Phil, > > thank you for your quick responses. I submitted a bug report > (internal > review ID: 9065523). Within the description I listed JDK-8137050 and > additionally bug reports from Cryptomator which describe the issue > also > in Ubuntu 20.04 LTS and pop!OS. > > Kind regards and thanks, > > wurstsemmel > > Am Donnerstag, den 18.06.2020, 09:37 -0700 schrieb Kevin Rushforth: > > On 6/18/2020 9:26 AM, Philip Race wrote: > > > Although we only support integer scaling on Linux you have 200% > > > which > > > should work. > > > So sounds like it could be a breaking change in Fedora, where it > > > passes around / defines > > > the scale in some new setting and doesn't set the old ones needed > > > for > > > compatibility. > > > > That could be. > > > > > > (either via gsettings or the GDI_SCALE env variable) > > > > > > GDK_SCALE, not GDI_SCALE > > > > Oops. :) Of course. > > > > -- Kevin > > > > > > > -phil > > > > > > > > > > > > On 6/18/20, 5:12 AM, Kevin Rushforth wrote: > > > > We will need a new bug ID for this (we never reuse a bug ID for > > > > which > > > > a commit has been pushed). You can file a new bug, mentioning > > > > JDK-8137050 in the Description, at: > > > > > > > > https://bugreport.java.com/ > > > > > > > > Question for other Linux users on this list: are any of you > > > > using > > > > a > > > > Linux machine with Hi-DPI scaling? Is it detecting it properly > > > > or > > > > do > > > > you have to set the scaling property (either via gsettings or > > > > the > > > > GDI_SCALE env variable) yourself? > > > > > > > > -- Kevin > > > > > > > > > > > > On 6/18/2020 1:51 AM, wurstsemmel at mailbox.org wrote: > > > > > Dear OpenJFX Developers, > > > > > > > > > > on Fedora 32 Workstation (Gnome) the AppImage from > > > > > Cryptomator > > > > > (cryptomator.org) does not follow the system-wide scale > > > > > settings from > > > > > Gnome Settings. > > > > > > > > > > *System Setup > > > > > Linux: Fedora Workstation 32 (Gnome) > > > > > Hardware: Dell XPS 13 with HiDPI (200 % scaling) > > > > > Cryptomator version: 1.5.5-x86_64 AppImage > > > > > > > > > > *Expected Behavior > > > > > App window should scale according to system-wide settings. > > > > > > > > > > *Actual Behavior > > > > > App window scales at 100 %. > > > > > > > > > > *Two workarounds exist: > > > > > $gsettings set org.gnome.desktop.interface scaling-factor 2 > > > > > $GDK_SCALE=2 ./cryptomator-1.5.5-x86_64.AppImage > > > > > > > > > > According to the developers from Cryptomator (see > > > > > https://github.com/cryptomator/cryptomator/issues/1242#issuecomment-643095195 > > > > > > > > > > ) this is a bug which was intended to be fixed with > > > > > https://bugs.openjdk.java.net/browse/JDK-8137050. However, > > > > > the > > > > > bug > > > > > still occurs in OpenJFX 14.0.1 and 11. > > > > > > > > > > I am happy to help if anything is unclear. Please re-open the > > > > > bug JDK- > > > > > 8137050 and make OpenJFX follow the system-wide scaling > > > > > settings in > > > > > Gnome. > > > > > > > > > > Thank you! > > > > > > > > > > wurstsemmel > > > > > > > > > > > > > > > > > > > > > > > > > From kcr at openjdk.java.net Tue Jun 23 12:34:42 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Jun 2020 12:34:42 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v5] In-Reply-To: <4GQ_NgNUsqa9c8Q3QLxhdvpUow7pqB5EXqCbql6bGTA=.46727a51-efe6-46df-aba5-dd469acfd67d@github.com> References: <4GQ_NgNUsqa9c8Q3QLxhdvpUow7pqB5EXqCbql6bGTA=.46727a51-efe6-46df-aba5-dd469acfd67d@github.com> Message-ID: On Tue, 23 Jun 2020 10:07:37 GMT, Ajit Ghaisas wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the un-required flag > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1856: > >> 1855: Callback, Boolean> sortPolicy = getSortPolicy(); >> 1856: if (sortPolicy == null) return; >> 1857: Boolean success = sortPolicy.call(this); > > Do we need to set sortingInProgress to false before returning from here? Yes, I think so. Good catch. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Tue Jun 23 12:53:18 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Jun 2020 12:53:18 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call [v2] In-Reply-To: <3qJCWEwcHxxRjyX13KeHA8PlPqWacH_3p9DhSXHowis=.57840718-4370-41d1-8dcf-48304aee479c@github.com> References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> <3qJCWEwcHxxRjyX13KeHA8PlPqWacH_3p9DhSXHowis=.57840718-4370-41d1-8dcf-48304aee479c@github.com> Message-ID: On Tue, 23 Jun 2020 10:33:05 GMT, Ambarish Rapte wrote: >> Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to >> listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong >> reference to the returned UnmodifiableObservableSet. >> >> So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every >> call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. >> >> Added a small unit test. and, >> Altered(minor) a test which was modified in >> past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) >> (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be >> updated in view of this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review corrections Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/253 From fastegal at openjdk.java.net Tue Jun 23 13:11:55 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 23 Jun 2020 13:11:55 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v5] In-Reply-To: References: <2hjiSautqrqvDzeddO6LFsllP1zcb0Hp93NuZegs7p0=.bb6f2e7f-8bc3-489d-b342-f8f20dd45ddf@github.com> Message-ID: On Fri, 19 Jun 2020 23:04:51 GMT, Kevin Rushforth wrote: >> Marked as reviewed by kcr (Lead). > > Pending a second reviewer. > > @aghaisas or @kleopatra can one of you review it? confirmed test failures before and passing after the fix - impressive :) While digging a bit (mainly around my [earlier concerns](https://github.com/openjdk/jfx/pull/244#issuecomment-638702570) - which still hold but could be discussed in a follow-up issue :) I came up with a NPE thrown by the newly added code block ins sort (the one walking up the parent hierarchy). @Test public void testNPEOnSortAfterSetAll() { // stand-alone setup TreeTableView treeTableView = new TreeTableView<>(); TreeTableColumn col = new TreeTableColumn("column"); col.setSortType(ASCENDING); col.setCellValueFactory(param -> new ReadOnlyObjectWrapper(param.getValue().getValue())); treeTableView.getColumns().add(col); TreeItem root = new TreeItem("root"); root.setExpanded(true); root.getChildren().addAll( new TreeItem("Apple"), new TreeItem("Orange"), new TreeItem("Banana")); treeTableView.setRoot(root); // add expanded children root.getChildren().forEach(child -> { child.setExpanded(true); String value = child.getValue(); for (int i = 1; i <= 3; i++) { child.getChildren().add(new TreeItem<>(value + i)); } }); assertEquals("sanity", 13, treeTableView.getExpandedItemCount()); TreeTableViewSelectionModel selectionModel = treeTableView.getSelectionModel(); selectionModel.setSelectionMode(SelectionMode.MULTIPLE); selectionModel.selectIndices(2, 5, 8, 10); assertEquals(10, selectionModel.getSelectedIndex()); TreeItem lastRootChild = root.getChildren().get(2); assertEquals("sanity: selectedItem child of last", lastRootChild, selectionModel.getSelectedItem().getParent()); // replace children of last root child List> childrenOfLastRootChild = new ArrayList<>(lastRootChild.getChildren()); childrenOfLastRootChild.remove(0); lastRootChild.getChildren().setAll(childrenOfLastRootChild); treeTableView.sort(); } (before the fix it throws an IOOB, plus the behavior completely rotten in a visual test) Did nothing to go to the bottom of this - looks like somehow the state of the selection is (still?) broken after setAll. Which might bring us back to the replace != permutation (can't resist to try :) actually there's no reason to special case a replace with all same items against a replace with only some same items (doing so introduces a discontinuity in behavior) - we should either try to keep selected items or not. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From fastegal at openjdk.java.net Tue Jun 23 13:22:49 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 23 Jun 2020 13:22:49 GMT Subject: RFR: 8214699: Node.getPseudoClassStates must return the same instance on every call [v2] In-Reply-To: <3qJCWEwcHxxRjyX13KeHA8PlPqWacH_3p9DhSXHowis=.57840718-4370-41d1-8dcf-48304aee479c@github.com> References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> <3qJCWEwcHxxRjyX13KeHA8PlPqWacH_3p9DhSXHowis=.57840718-4370-41d1-8dcf-48304aee479c@github.com> Message-ID: On Tue, 23 Jun 2020 10:33:05 GMT, Ambarish Rapte wrote: >> Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to >> listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong >> reference to the returned UnmodifiableObservableSet. >> >> So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every >> call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. >> >> Added a small unit test. and, >> Altered(minor) a test which was modified in >> past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) >> (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be >> updated in view of this change. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review corrections looks fine :) ------------- Marked as reviewed by fastegal (Committer). PR: https://git.openjdk.java.net/jfx/pull/253 From arapte at openjdk.java.net Tue Jun 23 13:27:41 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 23 Jun 2020 13:27:41 GMT Subject: Integrated: 8214699: Node.getPseudoClassStates must return the same instance on every call In-Reply-To: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> References: <0F7gs_d8CC6GIWLkhrHMVClL6Msk88d8zEt-ShoPuew=.40163a01-c5ea-49d0-8ff7-388f6983d131@github.com> Message-ID: On Thu, 18 Jun 2020 16:30:42 GMT, Ambarish Rapte wrote: > Node.getPseudoClassStates() returns a new UnmodifiableObservableSet of PseudoClassState on each call. So in order to > listen to any changes in this set, user must call the method Node.getPseudoClassStates() only once and keep a strong > reference to the returned UnmodifiableObservableSet. > > So the fix is that the method Node.getPseudoClassStates() should return the same UnmodifiableObservableSet on every > call. As the returned set is an UnmodifiableObservableSet, it will not have any impact on it's usage. > > Added a small unit test. and, > Altered(minor) a test which was modified in > past(https://github.com/openjdk/jfx/commit/0ac98695a1b11443c342fad4f009d6e03a052522) > (https://github.com/openjdk/jfx/commit/62323e0a9c5817b33daa262d6914eba0e8d274ff) along with this method and should be > updated in view of this change. This pull request has now been integrated. Changeset: a5878e05 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/a5878e05 Stats: 94 lines in 5 files changed: 7 ins; 84 del; 3 mod 8214699: Node.getPseudoClassStates must return the same instance on every call Reviewed-by: fastegal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/253 From arapte at openjdk.java.net Wed Jun 24 09:56:13 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 24 Jun 2020 09:56:13 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v5] In-Reply-To: References: <4GQ_NgNUsqa9c8Q3QLxhdvpUow7pqB5EXqCbql6bGTA=.46727a51-efe6-46df-aba5-dd469acfd67d@github.com> Message-ID: On Tue, 23 Jun 2020 12:32:22 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java line 1856: >> >>> 1855: Callback, Boolean> sortPolicy = getSortPolicy(); >>> 1856: if (sortPolicy == null) return; >>> 1857: Boolean success = sortPolicy.call(this); >> >> Do we need to set sortingInProgress to false before returning from here? > > Yes, I think so. Good catch. Corrected in the next commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 24 09:56:13 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 24 Jun 2020 09:56:13 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v5] In-Reply-To: <4GQ_NgNUsqa9c8Q3QLxhdvpUow7pqB5EXqCbql6bGTA=.46727a51-efe6-46df-aba5-dd469acfd67d@github.com> References: <4GQ_NgNUsqa9c8Q3QLxhdvpUow7pqB5EXqCbql6bGTA=.46727a51-efe6-46df-aba5-dd469acfd67d@github.com> Message-ID: <-3tJ9iIw5es2mRzl33MrG6BM3qlPMv_7Y4Uedl8BzkI=.0a39e45d-725a-4ce7-a6a3-1019f598e4b2@github.com> On Tue, 23 Jun 2020 10:02:17 GMT, Ajit Ghaisas wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the un-required flag > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeTablePosition.java line 79: > >> 78: } >> 79: >> 80: // Copy-like constructor with a different row. > > Suggest to add > // Not public API > before this description. > > (Similar to the constructor above this newly added constructor) Corrected in the next commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 24 10:23:25 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 24 Jun 2020 10:23:25 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v5] In-Reply-To: References: <2hjiSautqrqvDzeddO6LFsllP1zcb0Hp93NuZegs7p0=.bb6f2e7f-8bc3-489d-b342-f8f20dd45ddf@github.com> Message-ID: On Tue, 23 Jun 2020 13:09:44 GMT, Jeanette Winzenburg wrote: > While digging a bit (mainly around my [earlier > concerns](https://github.com/openjdk/jfx/pull/244#issuecomment-638702570) - which still hold but could be discussed in > a follow-up issue :) Yes, We need to address these issues. How should we treat permutation vs replace, which may involve answering few more small questions. Like, What should be the selected item when we remove the current selected item? What should the contents of an event be in such cases? Regarding the scenario in your test, In `TreeTableView`, when `setAll()` is called by providing the exact same items in a different order, then it is considered as permutation. and a `wasPermutated` `TreeModificationEvent` gets generated. But if even a single `TreeItem` is removed and `setAll(` with the remaining n-1 TreeItems`)` is called, then it is considered as adding new items. (May be it should be generate as `wasRemoved`). And similar issue can be observed when a `TreeItem` is added. In the test that you provided, one `TreeItem` is removed before doing `setAll()`. So this results in a `wasAdded` `TreeModificationEvent `and does not enter the `wasPermutated` code block. This fix only changes the `wasPermutated` event. So the behavior is still buggy more or less similar to before this change. There are multiple such issues with updating the selection. I have grouped few already reported issues under [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217). > I came up with a NPE thrown by the newly added code block ins sort (the one walking up the parent hierarchy). I have added a null check for now, with a reasoning comment. We will have to remove that check once we fix the other issues. Thanks for the providing the test :). code really helps to understand. I have added this scenario to test along with few others. The tests are ignored using [JDK-8248217](https://bugs.openjdk.java.net/browse/JDK-8248217). Please take a look. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Wed Jun 24 11:02:53 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 24 Jun 2020 11:02:53 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v6] In-Reply-To: References: Message-ID: > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: review comment corrections, adding new tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/244/files - new: https://git.openjdk.java.net/jfx/pull/244/files/c70178cf..bf225d64 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/244/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/244/webrev.04-05 Stats: 90 lines in 3 files changed: 74 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/244/head:pull/244 PR: https://git.openjdk.java.net/jfx/pull/244 From jvos at openjdk.java.net Thu Jun 25 06:42:05 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 25 Jun 2020 06:42:05 GMT Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has focus [v4] In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020 13:38:10 GMT, Abhinay Agarwal wrote: >> worth discussing the case were a TextInput is the only control. > > @mipastgt The issue happens because of the focus listener. With this PR, we introduce `mouseEventListener` to show the > Keyboard on `MOUSE_CLICKED` event. Therefore, the issue brought up by your previous comment should be resolved by > updating the `focusChangeListener` to: private final ChangeListener focusChangeListener = (observable, > wasFocused, isFocused) -> { > if (wasFocused && !isFocused) { > hideSoftwareKeyboard(); > } > }; > > We should most probably also introduce an API for showing the keyboard as available on both iOS and Android platforms :) > > Thoughts? It is probably good to add this suggestion in this PR. I'll review again once it is in. ------------- PR: https://git.openjdk.java.net/jfx/pull/219 From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Jun 25 17:58:34 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 25 Jun 2020 17:58:34 GMT Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has focus [v5] In-Reply-To: References: Message-ID: > In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard. > Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This > condition fails in cases where the control already has focus but the keyboard is not visible. Ideally, the keyboard > should be shown again when the user taps on the TextInputControl. > This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard if the TextInput control is > both editable and focused. Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Show keyboard on mouse event. Focus change listener should be responsible for hiding the keyboard only. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/219/files - new: https://git.openjdk.java.net/jfx/pull/219/files/3024ddcb..0aa79029 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/219/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/219/webrev.03-04 Stats: 12 lines in 2 files changed: 0 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/219.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/219/head:pull/219 PR: https://git.openjdk.java.net/jfx/pull/219 From github.com+3197675+abhinayagarwal at openjdk.java.net Thu Jun 25 18:20:55 2020 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Thu, 25 Jun 2020 18:20:55 GMT Subject: RFR: 8245053: Keyboard doesn't show when TextInputControl has focus [v6] In-Reply-To: References: Message-ID: > In Android, TextInputControls (TextField and TextArea) are responsible for showing and hiding software keyboard. > Currently, a focus listener is attached to these controls and is used to toggle the visibility of keyboard. This > condition fails in cases where the control already has focus but the keyboard is not visible. Ideally, the keyboard > should be shown again when the user taps on the TextInputControl. > This PR adds an event handler for `MouseEvent.MOUSE_CLICKED` event and shows the keyboard if the TextInput control is > both editable and focused. Abhinay Agarwal has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Show keyboard on mouse event. Focus change listener should be responsible for hiding the keyboard only. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/219/files - new: https://git.openjdk.java.net/jfx/pull/219/files/0aa79029..b13c44b3 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/219/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/219/webrev.04-05 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/219.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/219/head:pull/219 PR: https://git.openjdk.java.net/jfx/pull/219 From kcr at openjdk.java.net Thu Jun 25 22:50:26 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Jun 2020 22:50:26 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v6] In-Reply-To: References: Message-ID: On Wed, 24 Jun 2020 11:02:53 GMT, Ambarish Rapte wrote: >> Issue: >> In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not >> retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using >> `setAll()`). Cause: >> >> 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. >> 2. The indices from these TreeModificationEvents are not reliable. >> 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor >> results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of >> sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the >> selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or >> collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues >> combine in wrong update of the selection. Fix: >> >> 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the >> TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is >> almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change >> events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as >> before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change >> events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` >> Verification: >> The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the >> change should not cause any other failures. Added unit tests which fail before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > review comment corrections, adding new tests The changes to the fix itself look fine. I have a question and minor comment on the test changes. As for the questions raised by @kleopatra as long as you plan to address them in the follow-up issue(s), that seems fine, since you aren't regressing any behavior. modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 400: > 399: > 400: @Ignore("JDK-8248217") > 401: @Test public void testSelectionUpdatesCorrectlyAfterRemovingSelectedItem() { Question: did you mean to point to the umbrella Task or is there a more specific bug that you could point to (I think referring to the Task is fine if you aren't sure). This applies to all of the newly added `@Ignore`d tests. modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 443: > 442: @Test public void testSelectionUpdatesCorrectlyAfterChildRemoveOneAndSetAll() { > 443: TreeTableColumn col = setupForPermutationTest(); > 444: TreeItem parentTreeItem = ((TreeItem)sm.getSelectedItem()).getParent(); Minor: `col` is unused. ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From kcr at openjdk.java.net Fri Jun 26 00:01:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 26 Jun 2020 00:01:59 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v4] In-Reply-To: References: Message-ID: On Fri, 19 Jun 2020 16:04:16 GMT, Rony G. Flatscher wrote: >> This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The >> PI data is turned into a boolean value using "Boolean.parseBoolean(String)". >> This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if >> the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case >> compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be >> done without compilation. Because of the fallback scripts get compiled with this version by default. >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> ### Issue >> * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement >> javax.script.Compilable compile scripts >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` >> `$ git checkout pull/192` > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > Incorporating Kevin's review comments (final int, fix for loop test, correct formatting). The API changes look good. Also, the CSR has been approved. The code changes in FXMLLoader look good. The newly added tests pass with your fix. I also verified that at least some of the newly added tests fail without fix (good) Most of the rest of the comments are on formatting and code style, so this looks about ready to go in. modules/javafx.fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html line 1114: > 1113: > 1114: Extra blank line added (should be removed) modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1575: > 1574: do { > 1575: n = scriptReader.read(charBuffer,0,bufSize); > 1576: if (n > 0) { Indentation should be 4 spaces modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1594: > 1593: } catch (ScriptException compileExc) { > 1594: Logging.getJavaFXLogger().warning(filename+": compiling caused \""+compileExc+"\", > falling back to evaluating script in uncompiled mode"); 1595: } Minor: add space before and after `+` (and maybe wrap since the line is getting rather long) modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1605: > 1604: } catch (ScriptException exception) { > 1605: System.err.println(filename+": caused ScriptException"); > 1606: exception.printStackTrace(); Minor: add space before and after `+` modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1633: > 1632: } catch (ScriptException compileExc) { > 1633: Logging.getJavaFXLogger().warning(filename+": compiling caused \""+compileExc+"\", > falling back to evaluating script in uncompiled mode"); 1634: } Minor: add space before and after `+` (and maybe wrap since the line is getting rather long) modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1644: > 1643: } catch (ScriptException exception) { > 1644: System.err.println(filename+": caused ScriptException\n"+exception.getMessage()); > 1645: } Minor: add space before and after `+` modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1737: > 1736: public CompiledScript compiledScript; > 1737: public boolean isCompiled=false; > 1738: Add space before and after `=` modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1750: > 1749: } catch (ScriptException compileExc){ > 1750: Logging.getJavaFXLogger().warning(filename+": compiling caused \""+compileExc+"\", falling > back to evaluating script in uncompiled mode"); 1751: } Minor: add space before and after `+` (and maybe wrap since the line is getting rather long) modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1772: > 1771: } catch (ScriptException exception){ > 1772: throw new RuntimeException(filename+": caused ScriptException", exception); > 1773: } Minor: add space before and after `+` modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 2757: > 2756: } else if (piTarget.equals(COMPILE_PROCESSING_INSTRUCTION)) { > 2757: String strCompile=xmlStreamReader.getPIData().trim(); > 2758: // if PIData() is empty string then default to true, otherwise use Boolean.parseBoolean(string) to > determine the boolean value Add space before and after `=` modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 2759: > 2758: // if PIData() is empty string then default to true, otherwise use Boolean.parseBoolean(string) to > determine the boolean value 2759: compileScript = (strCompile.length()==0 ? true : > Boolean.parseBoolean(strCompile)); 2760: } Add space before and after `==` modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 3638: > 3637: > 3638: Extra 2 blank lines were added (should be removed) tests/system/src/test/java/test/launchertest/ModuleLauncherTest.java line 310: > 309: > 310: Extra 2 blank lines were added (should be removed) tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java line 110: > 109: btn.fireEvent(new MouseEvent(MouseEvent.MOUSE_CLICKED, > 110: 0, // double x, > 111: 0, // double y, Optional: you may want to align this and successive lines under `MouseEvent.MOUSE_CLICKED,` (it's up to you). tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java line 174: > 173: > 174: for (Integer invocation = 1; invocation <= invocationList.size(); invocation++) { > 175: InvocationInfos entry = (InvocationInfos) invocationList.get(invocation - 1); I think this should be `int` instead of `Integer`. tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java line 271: > 270: > Util.assertEndsWith("demo_03_fail_compile.fxml-onAction_attribute_in_element_ending_at_line_46", filename); > 271: Util.assertStartsWith("demo_03_fail_compile.fxml embedded event - ActionEvent - line # 45 - LF > entity ( ) forces linebreak in attribute value:", script); 272: break; You might want to consider wrapping some of the longer lines? tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Fail_Compilation.java line 288: > 287: > 288: There are two extra blank lines in this file that can be removed. tests/system/src/testscriptapp2/java/mymod/myapp2/FXMLScriptDeployment2Compile_Off.java line 60: > 59: */ > 60: public class FXMLScriptDeployment2Compile_Off extends Application { > 61: Most of the comments I made in the previous test class apply in this and the other tests, too. tests/system/src/testscriptapp2/java/mymod/pseudoScriptEngineCompilable/InvocationInfos.java line 78: > 77: } > 78: Extra blank line can be removed. tests/system/src/testscriptapp2/java/mymod/pseudoScriptEngineCompilable/RgfPseudoCompiledScript.java line 35: > 34: public class RgfPseudoCompiledScript extends CompiledScript > 35: { > 36: String code = null; This brace should go on the previous line tests/system/src/testscriptapp2/java/mymod/pseudoScriptEngineCompilable/RgfPseudoCompiledScript.java line 60: > 59: } > 60: Extra blank line can be removed. tests/system/src/testscriptapp2/java/mymod/pseudoScriptEngineCompilable/RgfPseudoScriptEngineCompilable.java line 143: > 142: > 143: Two extra blank lines can be removed. ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From almatvee at openjdk.java.net Fri Jun 26 00:03:16 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 26 Jun 2020 00:03:16 GMT Subject: RFR: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo Message-ID: - Added DirectShow baseclasses to repository. - Dependency on Windows SDK 7.1 DirectShow baseclasses was removed. ------------- Commit messages: - 8247947: Fixed files permissions - 8247947: Build DirectShow Samples (Base Classes) from source checked into repo Changes: https://git.openjdk.java.net/jfx/pull/254/files Webrev: https://webrevs.openjdk.java.net/jfx/254/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247947 Stats: 38685 lines in 73 files changed: 38674 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/254.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/254/head:pull/254 PR: https://git.openjdk.java.net/jfx/pull/254 From github.com+1413266+jgneff at openjdk.java.net Fri Jun 26 03:56:11 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 26 Jun 2020 03:56:11 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread Message-ID: Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). ------------- Commit messages: - 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread Changes: https://git.openjdk.java.net/jfx/pull/255/files Webrev: https://webrevs.openjdk.java.net/jfx/255/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8201567 Stats: 35 lines in 5 files changed: 29 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/255.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/255/head:pull/255 PR: https://git.openjdk.java.net/jfx/pull/255 From github.com+1413266+jgneff at openjdk.java.net Fri Jun 26 04:01:15 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 26 Jun 2020 04:01:15 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer Message-ID: Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). ------------- Commit messages: - 8248381: Create a daemon thread for MonocleTimer Changes: https://git.openjdk.java.net/jfx/pull/256/files Webrev: https://webrevs.openjdk.java.net/jfx/256/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248381 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/256.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/256/head:pull/256 PR: https://git.openjdk.java.net/jfx/pull/256 From github.com+1413266+jgneff at openjdk.java.net Fri Jun 26 06:08:54 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 26 Jun 2020 06:08:54 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 03:47:55 GMT, John Neffenger wrote: > Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). The method `QueuedPixelSource.usesSameBuffer` calls `Pixels.getPixels` on the QuantumRenderer thread while trying to find a buffer that's not in use, yet in doing so it rewinds buffers in use on the JavaFX Application Thread. This pull request modifies `QueuedPixelSource.usesSameBuffer` to call a new method, `Pixels.getBuffer`, that returns the buffer without rewinding it. Because the issue only affects the final rendered pixels, I added assertions to catch the error in the Monocle classes `HeadlessScreen` and `EPDScreen` instead of creating a unit test case. I tried to stay within the guidelines of [Programming With Assertions][1], which states: > As a rule, the expressions contained in assertions should be free of *side effects*: evaluating the expression should > not affect any state that is visible after the evaluation is complete. One exception to this rule is that assertions > can modify state that is used only from within other assertions. Below are animated images showing a few frames from a JavaFX animation on the Monocle VNC platform before and after the fix. ### Before the fix ![monocle-vnc-sw-before](https://user-images.githubusercontent.com/1413266/85825425-0f89e100-b737-11ea-98c6-32fb624dd306.gif) ### After the fix ![monocle-vnc-sw-after](https://user-images.githubusercontent.com/1413266/85825441-19134900-b737-11ea-930f-b7865556d17e.gif) ### Background The error occurs with software rendering when a subclass of `com.sun.glass.ui.View` uses the buffer position to upload a pixel buffer to the screen. That can occur in at least two cases: 1. when the pixels are uploaded to a composition byte buffer on the heap, and 2. when the width of the JavaFX scene is less than the width of the screen. In the first case, the non-direct byte buffer method `IntBuffer.put(IntBuffer)` relies on the source buffer position when copying the pixels, while the corresponding direct byte buffer method `DirectIntBufferU.put(IntBuffer)` does not. In the second case, `Framebuffer.composePixels`, for example, uses the buffer position to loop through the source pixel buffer when its width does not match the width of the destination pixel buffer. Most subclasses of `View` upload pixels with native methods that do not use the buffer position, so their final rendered pixels are not corrupted. Because of implementation choices, only the Monocle platforms end up having visible errors in their rendered pixels. While there are ways to work around the issue just for Monocle, this pull request is an attempt to correct the error at its source. ### Testing To reproduce the problem, I used the JavaFX application [epd-javafx][2] with the following command: $ java --add-modules=javafx.graphics \ --module-path=$HOME/lib/armv6hf-sdk/lib \ -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw \ -jar dist/epd-javafx.jar --pattern=3 --loops=0 You can run the command on an actual ARM device or on a QEMU *armhf* virtual machine running on an *amd64* Linux host. I connected to the Monocle VNC server with the Remmina VNC client on port 5901 with 24-bit color and encryption disabled. Even without access to an ARM device or virtual machine, you can capture the error on any Linux desktop by adding similar `assert` statements to the `_uploadPixels` method of `GtkView`, along with calls to `Thread.sleep` to change the timing of the two threads. Let me know if you would like information on installing a QEMU *armhf* virtual machine, or details on the assertions and `sleep` calls that allowed me to captured the error directly on my Dell Linux workstation. [1]: https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage [2]: https://github.com/jgneff/epd-javafx ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From thevenet.fred at free.fr Fri Jun 26 09:13:20 2020 From: thevenet.fred at free.fr (thevenet.fred at free.fr) Date: Fri, 26 Jun 2020 11:13:20 +0200 (CEST) Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: Message-ID: <1086831465.1428307572.1593162800612.JavaMail.zimbra@free.fr> Hi everyone, I think this is now ready for another (and hopefully final) round of reviews. Thanks. -- Fred ----- Mail original ----- De: "Frederic Thevenet" ?: "openjfx-dev" Envoy?: Vendredi 28 F?vrier 2020 18:58:00 Objet: RFR: 8238954: Improve performance of tiled snapshot rendering Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk of regressions, either in terms of performances and correctness, while still offering some relief to the original issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is necessary while still introducing no regressions compared to the original solution. ------------- Commits: - e13b5a06: Use tiling in QuantumToolkit::renderToImage when requested image is larger than max texture size - b914a48d: Revert "8088198: Exception thrown from snapshot if dimensions are larger than max texture size" Changes: https://git.openjdk.java.net/jfx/pull/112/files Webrev: https://webrevs.openjdk.java.net/jfx/112/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238954 Stats: 173 lines in 2 files changed: 84 ins; 50 del; 39 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From arapte at openjdk.java.net Fri Jun 26 09:22:53 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 26 Jun 2020 09:22:53 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v7] In-Reply-To: References: Message-ID: > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Correct the bug-id for ignored tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/244/files - new: https://git.openjdk.java.net/jfx/pull/244/files/bf225d64..d8c9c92e Webrevs: - full: https://webrevs.openjdk.java.net/jfx/244/webrev.06 - incr: https://webrevs.openjdk.java.net/jfx/244/webrev.05-06 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/244/head:pull/244 PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Fri Jun 26 09:22:56 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 26 Jun 2020 09:22:56 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v6] In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 22:45:17 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment corrections, adding new tests > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 443: > >> 442: @Test public void testSelectionUpdatesCorrectlyAfterChildRemoveOneAndSetAll() { >> 443: TreeTableColumn col = setupForPermutationTest(); >> 444: TreeItem parentTreeItem = ((TreeItem)sm.getSelectedItem()).getParent(); > > Minor: `col` is unused. Corrected in the next commit ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From arapte at openjdk.java.net Fri Jun 26 09:23:13 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 26 Jun 2020 09:23:13 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v6] In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 22:44:18 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment corrections, adding new tests > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 400: > >> 399: >> 400: @Ignore("JDK-8248217") >> 401: @Test public void testSelectionUpdatesCorrectlyAfterRemovingSelectedItem() { > > Question: did you mean to point to the umbrella Task or is there a more specific bug that you could point to (I think > referring to the Task is fine if you aren't sure). This applies to all of the newly added `@Ignore`d tests. These ignored tests are related to removing and adding a TreeItem. I have corrected the id to use JDK-8193442 for the tests that remove an item and created a new JBS issue JDK-8248389, and used it for the test of adding an item . ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From fastegal at openjdk.java.net Fri Jun 26 09:53:07 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 26 Jun 2020 09:53:07 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v6] In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 22:48:07 GMT, Kevin Rushforth wrote: > > > The changes to the fix itself look fine. I have a question and minor comment on the test changes. > > As for the questions raised by @kleopatra as long as you plan to address them in the follow-up issue(s), that seems > fine, since you aren't regressing any behavior. agreed - plus it's not only not regressing, but considerably improving the behavior :) ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From fastegal at openjdk.java.net Fri Jun 26 10:46:19 2020 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 26 Jun 2020 10:46:19 GMT Subject: RFR: 8246745: ListCell/Skin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Wed, 10 Jun 2020 23:33:46 GMT, Kevin Rushforth wrote: >> ListCellSkin installs listeners to the ListView/fixedCellSize that introduce a memory leak, NPE on replacing the >> listView and incorrect update of internal state (see bug report for details) >> Fixed by removing the listeners (and the internal state had been copied from listView on change) and access of listView >> state when needed. >> Added tests that failed before and pass after the fix, plus a sanity test to guarantee same (correct) behavior >> before/after. > > @arapte can you review? Hmm .. bottleneck seems to be layout as such (including css), accessing an instance field vs. querying a property doesn't make a difference (at least none I could see). ------------- PR: https://git.openjdk.java.net/jfx/pull/251 From kcr at openjdk.java.net Fri Jun 26 13:40:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 26 Jun 2020 13:40:40 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v7] In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 09:22:53 GMT, Ambarish Rapte wrote: >> Issue: >> In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not >> retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using >> `setAll()`). Cause: >> >> 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. >> 2. The indices from these TreeModificationEvents are not reliable. >> 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor >> results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of >> sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the >> selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or >> collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues >> combine in wrong update of the selection. Fix: >> >> 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the >> TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is >> almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change >> events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as >> before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change >> events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` >> Verification: >> The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the >> change should not cause any other failures. Added unit tests which fail before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Correct the bug-id for ignored tests Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From github.com+60214806+ronyfla at openjdk.java.net Fri Jun 26 18:38:23 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Fri, 26 Jun 2020 18:38:23 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v4] In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 23:59:47 GMT, Kevin Rushforth wrote: >> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporating Kevin's review comments (final int, fix for loop test, correct formatting). > > The API changes look good. Also, the CSR has been approved. > > The code changes in FXMLLoader look good. > > The newly added tests pass with your fix. > > I also verified that at least some of the newly added tests fail without fix (good) > > Most of the rest of the comments are on formatting and code style, so this looks about ready to go in. Kevin, thank you for your feedback and sponsorship! Hope that I have applied the changes to all affected files appropriately. (It is interesting for me that despite trying to adhere to the OpenJDK formatting, sometimes my own - decadelong trained :) - formattings slip thru without noticing it.) ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From github.com+60214806+ronyfla at openjdk.java.net Fri Jun 26 18:38:10 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Fri, 26 Jun 2020 18:38:10 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v5] In-Reply-To: References: Message-ID: > This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The > PI data is turned into a boolean value using "Boolean.parseBoolean(String)". > This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if > the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case > compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be > done without compilation. Because of the fallback scripts get compiled with this version by default. > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > ### Issue > * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement > javax.script.Compilable compile scripts > > > ### Download > `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` > `$ git checkout pull/192` Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: Incorporating Kevin's review comments. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/192/files - new: https://git.openjdk.java.net/jfx/pull/192/files/f2ea3d0e..f7f9cacb Webrevs: - full: https://webrevs.openjdk.java.net/jfx/192/webrev.04 - incr: https://webrevs.openjdk.java.net/jfx/192/webrev.03-04 Stats: 38 lines in 6 files changed: 3 ins; 10 del; 25 mod Patch: https://git.openjdk.java.net/jfx/pull/192.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192 PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Fri Jun 26 21:46:24 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 26 Jun 2020 21:46:24 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v5] In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 18:38:10 GMT, Rony G. Flatscher wrote: >> This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The >> PI data is turned into a boolean value using "Boolean.parseBoolean(String)". >> This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if >> the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case >> compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be >> done without compilation. Because of the fallback scripts get compiled with this version by default. >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> ### Issue >> * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement >> javax.script.Compilable compile scripts >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` >> `$ git checkout pull/192` > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > Incorporating Kevin's review comments. You got most of them, but there are still a few code style issues. I marked the ones as resolved that were, so you should be able to look at the above comments for those that are stil ourstanding. One of the comments is more than just code style. I think the following, which appears in a few test files (I noted it in `FXMLScriptDeployment2Compile_Fail_Compilation.java`), should use an `int` variable rather than an `Integer` in the for loop: for (Integer invocation = 1; invocation <= invocationList.size(); invocation++) { modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1567: > 1566: InputStreamReader scriptReader = null; > 1567: String script=null; > 1568: try { Here's one more place to add spaces surrounding `=` (I missed it last time) ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Fri Jun 26 23:07:53 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 26 Jun 2020 23:07:53 GMT Subject: RFR: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 23:19:05 GMT, Alexander Matveev wrote: > - Added DirectShow baseclasses to repository. > - Dependency on Windows SDK 7.1 DirectShow baseclasses was removed. Looks good. I was able to do a build and test with the patch applied. I confirm that it now builds without needing `C:/Program Files/Microsoft SDKs/Windows/v7.1`. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/254 From kcr at openjdk.java.net Fri Jun 26 23:11:41 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 26 Jun 2020 23:11:41 GMT Subject: RFR: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 23:05:46 GMT, Kevin Rushforth wrote: >> - Added DirectShow baseclasses to repository. >> - Dependency on Windows SDK 7.1 DirectShow baseclasses was removed. > > Looks good. I was able to do a build and test with the patch applied. I confirm that it now builds without needing > `C:/Program Files/Microsoft SDKs/Windows/v7.1`. @arapte can you be the second reviewer on this? @johanvos @tiainen FYI, in case you want to take a look as well: It's a straight-forward build change with no changes other than the location of the Microsoft DirectShow samples (Base Classes), which are now in the repo. No more external dependency on Windows 7.1 SDK. ------------- PR: https://git.openjdk.java.net/jfx/pull/254 From kcr at openjdk.java.net Fri Jun 26 23:25:49 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 26 Jun 2020 23:25:49 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 03:50:02 GMT, John Neffenger wrote: > Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). It looks simple enough for a single reviewer. Since it is in Monocle, @johanvos will probably want to review it. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From github.com+1413266+jgneff at openjdk.java.net Fri Jun 26 23:55:35 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Fri, 26 Jun 2020 23:55:35 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 23:23:43 GMT, Kevin Rushforth wrote: >> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). > > It looks simple enough for a single reviewer. Since it is in Monocle, @johanvos will probably want to review it. Note that this is a regression error that is not present in JavaFX 14, so it would be good to fix it before JavaFX 15 is released. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From github.com+1413266+jgneff at openjdk.java.net Sat Jun 27 00:22:35 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sat, 27 Jun 2020 00:22:35 GMT Subject: RFR: 8201570: Get two bytes for the Linux input event type, not four Message-ID: Fixes [JDK-8201570](https://bugs.openjdk.java.net/browse/JDK-8201570). ------------- Commit messages: - 8201570: Get two bytes for the Linux input event type, not four Changes: https://git.openjdk.java.net/jfx/pull/257/files Webrev: https://webrevs.openjdk.java.net/jfx/257/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8201570 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/257.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/257/head:pull/257 PR: https://git.openjdk.java.net/jfx/pull/257 From github.com+1413266+jgneff at openjdk.java.net Sat Jun 27 00:31:46 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sat, 27 Jun 2020 00:31:46 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened Message-ID: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). ------------- Commit messages: - 8201568: zForce touchscreen input device fails when closed and immediately reopened Changes: https://git.openjdk.java.net/jfx/pull/258/files Webrev: https://webrevs.openjdk.java.net/jfx/258/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8201568 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/258.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/258/head:pull/258 PR: https://git.openjdk.java.net/jfx/pull/258 From github.com+1413266+jgneff at openjdk.java.net Sat Jun 27 01:54:06 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sat, 27 Jun 2020 01:54:06 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened In-Reply-To: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> Message-ID: On Sat, 27 Jun 2020 00:21:06 GMT, John Neffenger wrote: > Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). I thought I could avoid fixing this bug simply by waiting a few years, but the old devices from 2012 and 2013 where the problem occurs are still supported and still even being sold (refurbished) by the manufacturer. The Monocle EPD platform has a work-around for the bug in the method `EPDInputDeviceRegistry.createDevice`. The problem does not occur on newer 2015 and 2018 devices that I tested. ### Background The Neonode zForce touchscreen input device almost always fails when it is opened immediately after being closed. Once it fails, no input events are received. The device driver logs the following messages to the kernel ring buffer: [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() [zForce_ir_touch_recv_data-145] command Activate (0) ... [zForce_ir_touch_recv_data-154] command Resolution (0) ... [zForce_ir_touch_recv_data-179] command Frequency (0) ... [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() [zForce_ir_touch_recv_data-142] command Deactivate ... [zForce_ir_touch_recv_data-198] command overrun (8) ... This pull request reorders the initialization sequence to be "open, open, close" instead of "open, close, open" so that the input device is never actually closed. With this change, the file reference count remains above zero so the call to close it is ignored, and the device driver logs the following messages to the ring buffer: [drivers/input/touchscreen/zforce_i2c.c-425] zforce_i2c_open() [zForce_ir_touch_recv_data-145] command Activate (0) ... [zForce_ir_touch_recv_data-154] command Resolution (0) ... [zForce_ir_touch_recv_data-179] command Frequency (0) ... In both cases, when the program exits or is canceled with `Ctrl-C`, the input device is closed normally: [drivers/input/touchscreen/zforce_i2c.c-440] zforce_i2c_close() [zForce_ir_touch_recv_data-142] command Deactivate ... ### Summary I decided to go ahead and submit this pull request for the following reasons: 1. we know of at least one input device where the code causes problems, so there could be others; 2. this makes progress towards removing 48 lines of work-around code from `EPDInputDeviceRegistry`; and 3. opening and closing an input device is expensive enough that we probably shouldn't close it when we know we're going to open it again only two statements later. ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From github.com+60214806+ronyfla at openjdk.java.net Sat Jun 27 14:07:24 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Sat, 27 Jun 2020 14:07:24 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6] In-Reply-To: References: Message-ID: > This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The > PI data is turned into a boolean value using "Boolean.parseBoolean(String)". > This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if > the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case > compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be > done without compilation. Because of the fallback scripts get compiled with this version by default. > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > ### Issue > * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement > javax.script.Compilable compile scripts > > > ### Download > `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` > `$ git checkout pull/192` Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: Incorporating Kevin's review comments (overlooked some places). ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/192/files - new: https://git.openjdk.java.net/jfx/pull/192/files/f7f9cacb..52da8a35 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/192/webrev.05 - incr: https://webrevs.openjdk.java.net/jfx/192/webrev.04-05 Stats: 138 lines in 7 files changed: 20 ins; 2 del; 116 mod Patch: https://git.openjdk.java.net/jfx/pull/192.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192 PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Sat Jun 27 14:12:34 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 27 Jun 2020 14:12:34 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: Message-ID: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> On Fri, 26 Jun 2020 23:53:21 GMT, John Neffenger wrote: >> It looks simple enough for a single reviewer. Since it is in Monocle, @johanvos will probably want to review it. > > Note that this is a regression error that is not present in JavaFX 14, so it would be good to fix it before JavaFX 15 > is released. The regression was caused by the fix for [JDK-8176499](https://bugs.openjdk.java.net/browse/JDK-8176499). See PR #117. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From jvos at openjdk.java.net Sat Jun 27 14:36:26 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 27 Jun 2020 14:36:26 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 03:50:02 GMT, John Neffenger wrote: > Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleTimer.java line 38: > 37: private static final String THREAD_NAME = "Monocle Timer"; > 38: private static final int POOL_SIZE = 1; > 39: I don't think there is a usecase where POOL_SIZE would be different from 1, so this could be skipped? ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From kcr at openjdk.java.net Sat Jun 27 14:43:40 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 27 Jun 2020 14:43:40 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6] In-Reply-To: References: Message-ID: On Sat, 27 Jun 2020 14:07:24 GMT, Rony G. Flatscher wrote: >> This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The >> PI data is turned into a boolean value using "Boolean.parseBoolean(String)". >> This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if >> the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case >> compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be >> done without compilation. Because of the fallback scripts get compiled with this version by default. >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> ### Issue >> * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement >> javax.script.Compilable compile scripts >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` >> `$ git checkout pull/192` > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > Incorporating Kevin's review comments (overlooked some places). Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Sat Jun 27 15:40:05 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 27 Jun 2020 15:40:05 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread In-Reply-To: References: Message-ID: On Fri, 26 Jun 2020 03:47:55 GMT, John Neffenger wrote: > Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). At first glance the fix looks fine (aside from the `assert` statements that need to be removed). It will also need to be tested using the SW pipeline on all platforms. modules/javafx.graphics/src/main/java/com/sun/glass/ui/Pixels.java line 194: > 193: public final Buffer getBuffer() { > 194: assert this.bytes != null || this.ints != null; > 195: return this.bytes != null ? this.bytes : this.ints; We should not use `assert` statements in the JavaFX runtime. If this is a condition that needs to be checked, then use an `if` test and throw an appropriate `RuntimeException` or an `InternalError`. ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Sat Jun 27 16:16:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 27 Jun 2020 16:16:43 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> References: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> Message-ID: <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> On Sat, 27 Jun 2020 14:10:21 GMT, Kevin Rushforth wrote: >> Note that this is a regression error that is not present in JavaFX 14, so it would be good to fix it before JavaFX 15 >> is released. > > The regression was caused by the fix for [JDK-8176499](https://bugs.openjdk.java.net/browse/JDK-8176499). See PR #117. On second thought, this seems more like a workaround than a fix. Maybe it would be better to shutdown the timer to shut it down in an orderly fashion with the FX runtime is terminated. The `QuantumToolkit::exit` method already calls `PulseTimer::stop` so that seems a likely place to stop the timer. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From github.com+1413266+jgneff at openjdk.java.net Sat Jun 27 16:20:53 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sat, 27 Jun 2020 16:20:53 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: Message-ID: On Sat, 27 Jun 2020 14:34:09 GMT, Johan Vos wrote: >> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleTimer.java line 38: > >> 37: private static final String THREAD_NAME = "Monocle Timer"; >> 38: private static final int POOL_SIZE = 1; >> 39: > > I don't think there is a usecase where POOL_SIZE would be different from 1, so this could be skipped? Thanks, Johan. I'll remove it. By the way, I added the thread name constant instead of calling `getClass().getSimpleName()` just so the name would appear similar to the other threads in the system, shown below. ![javafx-threads-2020-06-27](https://user-images.githubusercontent.com/1413266/85926564-1eff4c00-b855-11ea-98f3-1a2ec86d1348.png) ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From github.com+1413266+jgneff at openjdk.java.net Sat Jun 27 16:27:42 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sat, 27 Jun 2020 16:27:42 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> References: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Sat, 27 Jun 2020 16:14:36 GMT, Kevin Rushforth wrote: > On second thought, this seems more like a workaround than a fix. This change just restores the thread daemon status to the way it was before in JavaFX 14, where `true` is passed to the `Timer` constructor for "isDaemon - true if the associated thread should run as a daemon." if (timer == null) { timer = new java.util.Timer(true); } I tried setting `task.cancel(true)` instead of `false` in the `_stop` method, but that didn't stop the non-daemon thread. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From jvos at openjdk.java.net Sat Jun 27 18:32:29 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 27 Jun 2020 18:32:29 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov wrote: > I have tested on Linux (Fedora 31) only. > It works as intended (with one test failure due to 15-ea+4 being too old now). > > UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. > But as I could not find anything about it, that section in the documentation may need some love. WEBKIT-MEDIA-STUBS.md line 24: > 23: ```` > 24: $projectDir/../caches/sdk/lib > 25: ```` I know the caches have been at this location in the past, but I find it intrusive if `$projectDir/..` is used, so my preference would be to have it at `$projectDir/caches` . But maybe there is a good reason for using .. ? ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From jvos at openjdk.java.net Sat Jun 27 18:38:48 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sat, 27 Jun 2020 18:38:48 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: <9JltKgx8tzmEqGhK4jIXHZySwnIvkYqUfgSowMkgGuY=.4188d94b-1d50-4e1e-a659-de66a5fe4d74@github.com> On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov wrote: > I have tested on Linux (Fedora 31) only. > It works as intended (with one test failure due to 15-ea+4 being too old now). > > UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. > But as I could not find anything about it, that section in the documentation may need some love. build.gradle line 1269: > 1268: defaultStubRuntime = cachedBundledRuntime > 1269: } else if (IS_STUB_RUNTIME_OPENJFX) { > 1270: defaultStubRuntime = openjfxStubRuntime this won't be used if the cachedBundleRuntime exists. Shouldn't the order be reversed? (first check IS_STUB_TUNTIME_OPENJFX) ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From kcr at openjdk.java.net Sat Jun 27 19:39:19 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 27 Jun 2020 19:39:19 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> Message-ID: On Sat, 27 Jun 2020 16:25:24 GMT, John Neffenger wrote: >> On second thought, this seems more like a workaround than a fix. Maybe it would be better to shutdown the timer to shut >> it down in an orderly fashion with the FX runtime is terminated. The `QuantumToolkit::exit` method already calls >> `PulseTimer::stop` so that seems a likely place to stop the timer. > >> On second thought, this seems more like a workaround than a fix. > > This change just restores the thread daemon status to the way it was before in JavaFX 14, where `true` is passed to the > `Timer` constructor for "isDaemon - true if the associated thread should run as a daemon." > if (timer == null) { > timer = new java.util.Timer(true); > } > > I tried setting `task.cancel(true)` instead of `false` in the `_stop` method, but that didn't stop the non-daemon > thread. OK, that seems fine then. I'll take a closer look and then finish my review. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From kcr at openjdk.java.net Sat Jun 27 19:41:49 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 27 Jun 2020 19:41:49 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: On Sat, 27 Jun 2020 18:30:10 GMT, Johan Vos wrote: >> I have tested on Linux (Fedora 31) only. >> It works as intended (with one test failure due to 15-ea+4 being too old now). >> >> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. >> But as I could not find anything about it, that section in the documentation may need some love. > > WEBKIT-MEDIA-STUBS.md line 24: > >> 23: ```` >> 24: $projectDir/../caches/sdk/lib >> 25: ```` > > I know the caches have been at this location in the past, but I find it intrusive if `$projectDir/..` is used, so my > preference would be to have it at `$projectDir/caches` . But maybe there is a good reason for using .. ? This is just documenting current behavior. We have many build scripts rely on this. ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From github.com+1413266+jgneff at openjdk.java.net Sat Jun 27 19:43:04 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sat, 27 Jun 2020 19:43:04 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> Message-ID: On Sat, 27 Jun 2020 19:37:01 GMT, Kevin Rushforth wrote: > OK, that seems fine then. I'll take a closer look and then finish my review. Actually, I think you may be right, though. Sorry for replying before looking into it. I now think the `ScheduledThreadPoolExecutor` should be shut down, but let me look into it a bit more this afternoon before your final review. Thanks! The new `ScheduledThreadPoolExecutor` is ~complicated~ flexible! ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From kcr at openjdk.java.net Sat Jun 27 19:45:11 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 27 Jun 2020 19:45:11 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: <9JltKgx8tzmEqGhK4jIXHZySwnIvkYqUfgSowMkgGuY=.4188d94b-1d50-4e1e-a659-de66a5fe4d74@github.com> References: <9JltKgx8tzmEqGhK4jIXHZySwnIvkYqUfgSowMkgGuY=.4188d94b-1d50-4e1e-a659-de66a5fe4d74@github.com> Message-ID: On Sat, 27 Jun 2020 18:36:33 GMT, Johan Vos wrote: >> I have tested on Linux (Fedora 31) only. >> It works as intended (with one test failure due to 15-ea+4 being too old now). >> >> UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. >> But as I could not find anything about it, that section in the documentation may need some love. > > build.gradle line 1269: > >> 1268: defaultStubRuntime = cachedBundledRuntime >> 1269: } else if (IS_STUB_RUNTIME_OPENJFX) { >> 1270: defaultStubRuntime = openjfxStubRuntime > > this won't be used if the cachedBundleRuntime exists. Shouldn't the order be reversed? (first check > IS_STUB_TUNTIME_OPENJFX) Either is fine with me: if you want to make this change it could be the first test instead of the last. ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From github.com+1413266+jgneff at openjdk.java.net Sun Jun 28 01:58:39 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sun, 28 Jun 2020 01:58:39 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Sat, 27 Jun 2020 19:40:53 GMT, John Neffenger wrote: >> OK, that seems fine then. I'll take a closer look and then finish my review. > >> OK, that seems fine then. I'll take a closer look and then finish my review. > > Actually, I think you may be right, though. Sorry for replying before looking into it. I now think the > `ScheduledThreadPoolExecutor` should be shut down, but let me look into it a bit more this afternoon before your final > review. Thanks! The new `ScheduledThreadPoolExecutor` is ~complicated~ flexible! ?? I think the code in the `_stop` method is correct after all. The `MonocleTimer` class is written to allow for multiple calls to the pair of `_start` and `_stop` methods (even though I don't think that ever happens), and the static `ScheduledThreadPoolExecutor`, named `scheduler`, is created only once and reused on subsequent calls. Changing the `_stop` method to call `task.cancel(true)` still leaves the timer thread running, which prevents the JavaFX application from exiting when the timer thread is a user thread. Furthermore, whether it's a user or daemon thread, if the call to `task.cancel(true)` happens to run exactly when the periodic task is *in progress*, the `timerRunnable` lambda in `QuantumToolkit` prints the stack trace when it catches the `InterruptedException`. java.lang.InterruptedException: at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit .lambda$runToolkit$12(QuantumToolkit.java:345) at java.base/java.util.concurrent.Executors$RunnableAdapter .call(Executors.java:515) at java.base/java.util.concurrent.FutureTask .runAndReset(FutureTask.java:305) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask .run(ScheduledThreadPoolExecutor.java:305) at java.base/java.util.concurrent.ThreadPoolExecutor .runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker .run(ThreadPoolExecutor.java:630) at java.base/java.lang.Thread .run(Thread.java:832) So the call to `task.cancel(false)` is correct. Changing the `_stop` method to shut down the `scheduler` will terminate the associated thread, regardless of its daemon status, but a subsequent call to `_start` will throw a `RejectedExecutionException` when trying to schedule the timer task: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at b1fe89 [Not completed, task = java.util.concurrent.Executors$RunnableAdapter at 1f85c96 [Wrapped task = com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$111/0x34563828 at 141859b]] rejected from java.util.concurrent.ScheduledThreadPoolExecutor at 55f462 [Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] at java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy .rejectedExecution(ThreadPoolExecutor.java:2057) at java.base/java.util.concurrent.ThreadPoolExecutor .reject(ThreadPoolExecutor.java:827) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor .delayedExecute(ScheduledThreadPoolExecutor.java:340) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor .scheduleAtFixedRate(ScheduledThreadPoolExecutor.java:632) at javafx.graphics/com.sun.glass.ui.monocle.MonocleTimer ._start(MonocleTimer.java:64) at javafx.graphics/com.sun.glass.ui.Timer .start(Timer.java:96) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit .runToolkit(QuantumToolkit.java:384) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit .lambda$startup$10(QuantumToolkit.java:280) at javafx.graphics/com.sun.glass.ui.Application .lambda$run$1(Application.java:153) at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor .runLoop(RunnableProcessor.java:92) at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor .run(RunnableProcessor.java:51) at java.base/java.lang.Thread .run(Thread.java:832) So if we want `MonocleTimer` to reuse a single `ScheduledThreadPoolExecutor` object, I think the only way to make sure that its timer thread exits when the application exits is to set its daemon status to `true`. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From github.com+1413266+jgneff at openjdk.java.net Sun Jun 28 02:28:35 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sun, 28 Jun 2020 02:28:35 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer [v2] In-Reply-To: References: Message-ID: > Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Remove POOL_SIZE constant ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/256/files - new: https://git.openjdk.java.net/jfx/pull/256/files/c771c242..4ca2bc03 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/256/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/256/webrev.00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/256.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/256/head:pull/256 PR: https://git.openjdk.java.net/jfx/pull/256 From github.com+1413266+jgneff at openjdk.java.net Sun Jun 28 02:37:27 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Sun, 28 Jun 2020 02:37:27 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Sat, 27 Jun 2020 15:36:01 GMT, Kevin Rushforth wrote: >> Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/Pixels.java line 194: > >> 193: public final Buffer getBuffer() { >> 194: assert this.bytes != null || this.ints != null; >> 195: return this.bytes != null ? this.bytes : this.ints; > > We should not use `assert` statements in the JavaFX runtime. If this is a condition that needs to be checked, then use > an `if` test and throw an appropriate `RuntimeException` or an `InternalError`. Thanks, Kevin. I saw `assert` used elsewhere (`EventLoop` in the same package, for example), and thought it was okay?even preferable?for these "should never occur" checks. Is that a general policy not to use `asserts` anywhere in JavaFX? Should I also remove the asserts I added to `HeadlessScreen` and `EPDScreen` in lieu of a unit test case? ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From github.com+60214806+ronyfla at openjdk.java.net Sun Jun 28 18:10:27 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Sun, 28 Jun 2020 18:10:27 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6] In-Reply-To: References: Message-ID: <7Rt4yXU62x2Y338R2LQbhC90_JF5pjdcmR92-v3RFEU=.e7d9f2c4-0854-4b6a-9489-db7eed1740c2@github.com> On Sat, 27 Jun 2020 14:41:29 GMT, Kevin Rushforth wrote: >> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporating Kevin's review comments (overlooked some places). > > Looks good. It seems that there is a need of 2 reviewers though only one is defined (when clicking "Show all reviewers"). Is there anything I can/need to do to advance the state? ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From jpereda at openjdk.java.net Sun Jun 28 18:34:01 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 28 Jun 2020 18:34:01 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes [v3] In-Reply-To: References: Message-ID: > This PR comments out too verbose console logging, as it has been done with some other fprintf calls. > As a follow up of this PR, a custom directive that enables this output if needed can be considered. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Restore initial printout ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/165/files - new: https://git.openjdk.java.net/jfx/pull/165/files/34d256da..35173e64 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/165/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/165/webrev.01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/165.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/165/head:pull/165 PR: https://git.openjdk.java.net/jfx/pull/165 From jpereda at openjdk.java.net Sun Jun 28 18:34:01 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 28 Jun 2020 18:34:01 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes [v2] In-Reply-To: References: Message-ID: On Mon, 15 Jun 2020 19:52:26 GMT, Jose Pereda wrote: >> modules/javafx.graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m line 86: >> >>> 85: if (pulseLoggingRequested) { >>> 86: fprintf(stderr, "IOSWindowSystemInterface : deleteContext unimp\n"); >>> 87: } >> >> this doesn't relate to pulseLogging I believe? > > Right, but since it wasn't commented out, should I just leave it as it was? @johanvos I've finally restored the initial printout. ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From jvos at openjdk.java.net Sun Jun 28 19:08:07 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Sun, 28 Jun 2020 19:08:07 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes [v3] In-Reply-To: References: Message-ID: On Sun, 28 Jun 2020 18:34:01 GMT, Jose Pereda wrote: >> This PR comments out too verbose console logging, as it has been done with some other fprintf calls. >> As a follow up of this PR, a custom directive that enables this output if needed can be considered. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Restore initial printout Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From aghaisas at openjdk.java.net Mon Jun 29 04:47:20 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 29 Jun 2020 04:47:20 GMT Subject: RFR: 8193800: TreeTableView selection changes on sorting [v7] In-Reply-To: References: Message-ID: <-cU6oxwM2C1GiKkopoMiZ8tI8EIVdtPDQ3-grqekMOc=.c2327610-988c-4c36-ba96-0dfe78b10eb4@github.com> On Fri, 26 Jun 2020 09:22:53 GMT, Ambarish Rapte wrote: >> Issue: >> In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not >> retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using >> `setAll()`). Cause: >> >> 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. >> 2. The indices from these TreeModificationEvents are not reliable. >> 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor >> results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of >> sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the >> selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or >> collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues >> combine in wrong update of the selection. Fix: >> >> 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the >> TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is >> almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change >> events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as >> before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change >> events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` >> Verification: >> The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the >> change should not cause any other failures. Added unit tests which fail before and pass after the fix. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Correct the bug-id for ignored tests Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From aghaisas at openjdk.java.net Mon Jun 29 05:48:37 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 29 Jun 2020 05:48:37 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6] In-Reply-To: References: Message-ID: On Sat, 27 Jun 2020 14:07:24 GMT, Rony G. Flatscher wrote: >> This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The >> PI data is turned into a boolean value using "Boolean.parseBoolean(String)". >> This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if >> the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case >> compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be >> done without compilation. Because of the fallback scripts get compiled with this version by default. >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> ### Issue >> * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement >> javax.script.Compilable compile scripts >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` >> `$ git checkout pull/192` > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > Incorporating Kevin's review comments (overlooked some places). Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From arapte at openjdk.java.net Mon Jun 29 05:50:39 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 29 Jun 2020 05:50:39 GMT Subject: Integrated: 8193800: TreeTableView selection changes on sorting In-Reply-To: References: Message-ID: On Tue, 2 Jun 2020 17:00:28 GMT, Ambarish Rapte wrote: > Issue: > In TreeTableView, in case of Multiple selection mode, if nested items are selected, then TreeTableView does not > retain/update the selection correctly when the tree items are permuted(either by `sort()` or by reordering using > `setAll()`). Cause: > > 1. For permutation, the current implementation uses `TreeModificationEvent` to update the selection. > 2. The indices from these TreeModificationEvents are not reliable. > 3. It uses the non public `TreeTablePosition` constructor to create intermediate `TreeItem` positions, this constructor > results in another unexpected TreeModificationEvent while one for sorting is already being processed. 4. In case of > sorting, there can be multiple intermediate TreeModificationEvents generated, and for each TreeModificationEvent, the > selection gets updated and results in selection change events being generated. 5. Each time a TreeItem is expanded or > collapsed, the selection must be shifted, but shifting is not necessary in case of permutation. All these issues > combine in wrong update of the selection. Fix: > > 1. On each TreeModificationEvent for permutation, for updating the selection, use index of TreeItem from the > TreeTableView but not from the TreeModificationEvent. 2. Added a new non public TreeTablePosition constructor, which is > almost a copy constructor but accepts a different row. 3. In case of sorting, send out the set of selection change > events only once after the sorting is over. 4. In case of setAll, send out the set of selection change events same as > before.(setAll results in only one TreeModificationEvent, which effectively results in only one set of selection change > events). `shiftSelection()` should not be called in case of permutation i.e. call `if (shift != 0)` > Verification: > The change is very limited to updating of selection of TreeTableView items when the TreeItems are permuted, so the > change should not cause any other failures. Added unit tests which fail before and pass after the fix. This pull request has now been integrated. Changeset: 2ca509a1 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/2ca509a1 Stats: 368 lines in 3 files changed: 32 ins; 280 del; 56 mod 8193800: TreeTableView selection changes on sorting Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/244 From jvos at openjdk.java.net Mon Jun 29 11:25:34 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Jun 2020 11:25:34 GMT Subject: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 30 Apr 2020 18:56:40 GMT, Jesper Skov wrote: > I have tested on Linux (Fedora 31) only. > It works as intended (with one test failure due to 15-ea+4 being too old now). > > UPDATE_STUB_CACHE suggests there is some magic available to help manage the stub cache. > But as I could not find anything about it, that section in the documentation may need some love. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/202 From jvos at openjdk.java.net Mon Jun 29 11:30:16 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Jun 2020 11:30:16 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened In-Reply-To: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> Message-ID: On Sat, 27 Jun 2020 00:21:06 GMT, John Neffenger wrote: > Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). The rationale makes sense (open/open/close) instead of (open/close/open) ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/258 From jvos at openjdk.java.net Mon Jun 29 11:34:02 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Jun 2020 11:34:02 GMT Subject: RFR: 8201570: Get two bytes for the Linux input event type, not four In-Reply-To: References: Message-ID: On Sat, 27 Jun 2020 00:12:41 GMT, John Neffenger wrote: > Fixes [JDK-8201570](https://bugs.openjdk.java.net/browse/JDK-8201570). This fixes a bug that currently didn't cause any harm (https://bugs.openjdk.java.net/browse/JDK-8201570?focusedCommentId=14172176) , but it's better to fix it now. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/257 From jvos at openjdk.java.net Mon Jun 29 11:35:41 2020 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Jun 2020 11:35:41 GMT Subject: RFR: 8248381: Create a daemon thread for MonocleTimer In-Reply-To: References: <2PhZsHjERBESDIRHg27MzRUkmp-I2exRDnvSr7HHYRk=.e207ba18-3b5d-44ef-8f01-5e6baf8e2997@github.com> <9Td5GaMz2wBpRiz9JucqHQk5dJeHjFGwoU7WwSw7Jyw=.27ddc1ec-0967-49ad-8bc6-d2c94f4bade9@github.com> Message-ID: <0P3rBw0Lkt5oFlgcSWPBaw8JQ_545NxYEinvuPMJAYI=.37ab6b83-9938-418d-a0f6-459fc5a7771b@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Sun, 28 Jun 2020 01:56:26 GMT, John Neffenger wrote: >>> OK, that seems fine then. I'll take a closer look and then finish my review. >> >> Actually, I think you may be right, though. Sorry for replying before looking into it. I now think the >> `ScheduledThreadPoolExecutor` should be shut down, but let me look into it a bit more this afternoon before your final >> review. Thanks! The new `ScheduledThreadPoolExecutor` is ~complicated~ flexible! ?? > > I think the code in the `_stop` method is correct after all. > > The `MonocleTimer` class is written to allow for multiple calls to the pair of `_start` and `_stop` methods (even > though I don't think that ever happens), and the static `ScheduledThreadPoolExecutor`, named `scheduler`, is created > only once and reused on subsequent calls. Changing the `_stop` method to call `task.cancel(true)` still leaves the > timer thread running, which prevents the JavaFX application from exiting when the timer thread is a user thread. > Furthermore, whether it's a user or daemon thread, if the call to `task.cancel(true)` happens to run exactly when the > periodic task is *in progress*, the `timerRunnable` lambda in `QuantumToolkit` prints the stack trace when it catches > the `InterruptedException`. java.lang.InterruptedException: > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit > .lambda$runToolkit$12(QuantumToolkit.java:345) > at java.base/java.util.concurrent.Executors$RunnableAdapter > .call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask > .runAndReset(FutureTask.java:305) > at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask > .run(ScheduledThreadPoolExecutor.java:305) > at java.base/java.util.concurrent.ThreadPoolExecutor > .runWorker(ThreadPoolExecutor.java:1130) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker > .run(ThreadPoolExecutor.java:630) > at java.base/java.lang.Thread > .run(Thread.java:832) > > So the call to `task.cancel(false)` is correct. > > Changing the `_stop` method to shut down the `scheduler` will terminate the associated thread, regardless of its daemon > status, but a subsequent call to `_start` will throw a `RejectedExecutionException` when trying to schedule the timer > task: java.util.concurrent.RejectedExecutionException: > Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at b1fe89 > [Not completed, task = java.util.concurrent.Executors$RunnableAdapter at 1f85c96 > [Wrapped task = com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$111/0x34563828 at 141859b]] > rejected from java.util.concurrent.ScheduledThreadPoolExecutor at 55f462 > [Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > at java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy > .rejectedExecution(ThreadPoolExecutor.java:2057) > at java.base/java.util.concurrent.ThreadPoolExecutor > .reject(ThreadPoolExecutor.java:827) > at java.base/java.util.concurrent.ScheduledThreadPoolExecutor > .delayedExecute(ScheduledThreadPoolExecutor.java:340) > at java.base/java.util.concurrent.ScheduledThreadPoolExecutor > .scheduleAtFixedRate(ScheduledThreadPoolExecutor.java:632) > at javafx.graphics/com.sun.glass.ui.monocle.MonocleTimer > ._start(MonocleTimer.java:64) > at javafx.graphics/com.sun.glass.ui.Timer > .start(Timer.java:96) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit > .runToolkit(QuantumToolkit.java:384) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit > .lambda$startup$10(QuantumToolkit.java:280) > at javafx.graphics/com.sun.glass.ui.Application > .lambda$run$1(Application.java:153) > at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor > .runLoop(RunnableProcessor.java:92) > at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor > .run(RunnableProcessor.java:51) > at java.base/java.lang.Thread > .run(Thread.java:832) > > So if we want `MonocleTimer` to reuse a single `ScheduledThreadPoolExecutor` object, I think the only way to make sure > that its timer thread exits when the application exits is to set its daemon status to `true`. While the PR should indeed fix the original issue, I'm unsure about the behavior of multiple invocations of start/stop rather than using the (nop) pause method. However, it seems this behavior is similar on other platforms, so I assume it is by design. ------------- PR: https://git.openjdk.java.net/jfx/pull/256 From thevenet.fred at free.fr Mon Jun 29 12:40:35 2020 From: thevenet.fred at free.fr (thevenet.fred at free.fr) Date: Mon, 29 Jun 2020 14:40:35 +0200 (CEST) Subject: RFR: 8238954: Improve performance of tiled snapshot rendering In-Reply-To: References: <1086831465.1428307572.1593162800612.JavaMail.zimbra@free.fr> <2a32e3db-97ba-4e27-f1e0-0dd728d870ea@oracle.com> <504517011.1430180095.1593183422537.JavaMail.zimbra@free.fr> <1478114114.1430386425.1593185283397.JavaMail.zimbra@free.fr> <3bdfbdfe-ea1e-b4a4-4ccc-dd785d120cb0@oracle.com> Message-ID: <470745621.1449524827.1593434435414.JavaMail.zimbra@free.fr> Hi Ambarish, Thanks for your review. I don't have access to a Mac so I can't check that directly. The tests pass on both my Windows 10 and Ubuntu 20.04 environments and the stack isn't very helpful (it simply indicates the renderImage method returned null). There could be many reasons for that, but this is what would happen when running the test with the unpatched version of the QuantumToolkit::renderToImage method. Maybe double-check the pull applied cleanly on your clone? With regard to the choice of random noise for the test image, my idea was to be able to catch any misalignment caused by tiling in the final snapshot: using a single color or a simple pattern would not necessarily help catching such errors. Using a complex image could do the trick, and avoid the broken aspect you mentioned, but it would need to be very large (>4096x4096), and I was not sure it would be wise to add such a large binary resource to the repo. So I settled for random noise, since it was the simplest way to generate an image with 100% guaranties any misalignment would be caught by comparing pixels 1 to 1. PS: I cc'ing the mailing list, so that the skara bot will hopefully pick it up and add it to the PR, so we can resume the discussion there once Github is up again. -- Fred. ----- Mail original ----- De: "Ambarish Rapte" ?: "Kevin Rushforth" , "thevenet fred" Envoy?: Lundi 29 Juin 2020 13:12:47 Objet: RE: RFR: 8238954: Improve performance of tiled snapshot rendering Hi, Looks like github is down, Unable to do a fresh login OR post a comment on the PR from already logged in session. Here is my comment about the tests, I observed that the added tests are failing on mac machine(Mojave 10.14.6), but they do pass on windows10. Can you please verify ? Attached mac test execution log. I would suggest to fill the image with a single or preferably some pattern of multiple recognizable colors instead of noise. The noise gives a broken feel. It might confuse the verifications of any future fixes in this area. A well defined color would be nice. Regards, Ambarish -----Original Message----- From: Kevin Rushforth Sent: Sunday, June 28, 2020 1:27 AM To: thevenet.fred at free.fr Cc: Ambarish Rapte Subject: Re: RFR: 8238954: Improve performance of tiled snapshot rendering No worries. I hope to finish the review on Monday or Tuesday. I ran a full test on Windows today and it looks good. I have some more testing to do and then I will sanity test it on other platforms. I took a quick look at the code changes since last time, and didn't spot any issues. I'll do a more careful review Monday. The new tests look good, but I haven't looked carefully at the code yet. -- Kevin On 6/26/2020 8:28 AM, thevenet.fred at free.fr wrote: >> I didn't copy openjfx-dev, so there is no way my reply could have >> been forwarded to either the list or the PR (else it would have been). > Yes, of course: I realized that immediately *after* I pressed the send button... > >> I don't see any duplication of your message. There is exactly one >> reply to the list, which was forwarded to the PR (as expected). The >> Skara bot will forward comments made in the GitHub PR as a reply to >> the RFR email and vice-versa. >> >> If you want to make a comment on the mailing list related to your PR, >> but don't want that to show up in the PR, the easiest way is to start >> a new message thread rather than doing a reply. > Indeed, there's no need to overthink it. > > Thank you, and my apologies for being a little dense today ;-) > > -- Fred > > >> -- Kevin >> >> >> On 6/26/2020 7:57 AM, thevenet.fred at free.fr wrote: >>> Hi Kevin, thank you for that. >>> >>> As an unrelated side question: my original email to the list got >>> picked up by a bot and pushed to the PR, and then pushed back onto >>> the list,adding even more noise. >>> Meanwhile your reply didn't; why is that? >>> >>> Do you know where I can find the rules used by the gh bot to pick-up >>> messages from the list, so I can avoid tripping one of them >>> unintentionally? >>> >>> Thanks. >>> >>> -- Fred >>> >>> >>> >>> ----- Mail original ----- >>> De: "Kevin Rushforth" >>> ?: "thevenet fred" >>> Cc: "Ambarish Rapte" >>> Envoy?: Vendredi 26 Juin 2020 15:39:56 >>> Objet: Re: RFR: 8238954: Improve performance of tiled snapshot >>> rendering >>> >>> Thanks for the reminder. Ambarish and I spoke yesterday and both of >>> us will review it. >>> >>> -- Kevin >>> >>> >>> On 6/26/2020 2:13 AM, thevenet.fred at free.fr wrote: >>>> Hi everyone, >>>> >>>> I think this is now ready for another (and hopefully final) round of reviews. >>>> >>>> Thanks. >>>> >>>> -- Fred >>>> >>>> ----- Mail original ----- >>>> De: "Frederic Thevenet" >>>> >>>> ?: "openjfx-dev" >>>> Envoy?: Vendredi 28 F?vrier 2020 18:58:00 >>>> Objet: RFR: 8238954: Improve performance of tiled snapshot >>>> rendering >>>> >>>> Issue JDK-8088198, where an exception would be thrown when trying >>>> to capture a snapshot whose final dimensions would be larger than >>>> the running platform's maximum supported texture size, was addressed in openjfx14. >>>> The fix, based around the idea of capturing as many tiles of the >>>> maximum possible size and re-compositing the final snapshot out of >>>> these, is currently only attempted after the original, non-tiled, >>>> strategy has already failed. >>>> This was decided to avoid any risk of regressions, either in terms >>>> of performances and correctness, while still offering some relief >>>> to the original issue. >>>> >>>> This follow-on issue aims to propose a fix to the original issue, >>>> that is able to correctly decide on the best snapshot strategy >>>> (tiled or not) to adopt before applying it and ensure best >>>> performances possible when tiling is necessary while still >>>> introducing no regressions compared to the original solution. >>>> >>>> ------------- >>>> >>>> Commits: >>>> - e13b5a06: Use tiling in QuantumToolkit::renderToImage when >>>> requested image is larger than max texture size >>>> - b914a48d: Revert "8088198: Exception thrown from snapshot if >>>> dimensions are larger than max texture size" >>>> >>>> Changes: https://git.openjdk.java.net/jfx/pull/112/files >>>> Webrev: https://webrevs.openjdk.java.net/jfx/112/webrev.00 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8238954 >>>> Stats: 173 lines in 2 files changed: 84 ins; 50 del; 39 mod >>>> Patch: https://git.openjdk.java.net/jfx/pull/112.diff >>>> Fetch: git fetch https://git.openjdk.java.net/jfx >>>> pull/112/head:pull/112 >>>> >>>> PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Mon Jun 29 13:29:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 29 Jun 2020 13:29:25 GMT Subject: RFR: 8240264: iOS: Unnecessary logging on every pulse when GL context changes [v3] In-Reply-To: References: Message-ID: <7UMLJrWf_qUGtnVip-Vtct9YsUdZTe4WK99enHBfh48=.abb7514c-8037-4b61-8ad1-9866c9dfebd5@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Sun, 28 Jun 2020 18:34:01 GMT, Jose Pereda wrote: >> This PR comments out too verbose console logging, as it has been done with some other fprintf calls. >> As a follow up of this PR, a custom directive that enables this output if needed can be considered. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Restore initial printout Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From arapte at openjdk.java.net Mon Jun 29 14:04:28 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 29 Jun 2020 14:04:28 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v5] In-Reply-To: References: Message-ID: On Wed, 17 Jun 2020 11:33:27 GMT, Frederic Thevenet wrote: >>> [...] I'd like to see some additional system tests that cover all of the cases of X and Y fitting/not-fitting exactly >>> (and if you stick with your current approach, X or Y as the inner loop). >> >> What kind of tests do you have in mind? More specifically do you mean simply adding tests that expand on the existing >> `doTestSnapshotScaleNodeDefer`and `doTestSnapshotScaleNodeImm` (which basically just prove that taking a snapshot >> returns a non-null image of the expected size)? Or do you think we need to include a test that proves the snapshot >> produced by tiling is entirely faithful to the original, pixel-wise? > > I went ahead and wrote a bunch of tests that: > 1. Setup a scene to display an `ImageView` of a selected dimensions chosen to trigger tiling in different ways when > taking snapshots. 2. Fill up the image with noise. > 3. Take a snapshot and do a pixel-wise comparison with the original image. > > I've added the new tests to the existing `Snapshot2Test.java`. I observed that the added tests are failing on mac machine(Mojave 10.14.6), but they do pass on windows10. Can you please verify ? Timeout and NPE exception from the log, test.javafx.scene.Snapshot2Test > testSnapshot2x2TilesSameWidthImm[0] FAILED ? ? java.lang.IllegalArgumentException: Unrecognized image loader: null ? ? ? ? at javafx.graphics/javafx.scene.image.WritableImage.loadTkImage(WritableImage.java:278) ? ? ? ? at javafx.graphics/javafx.scene.image.WritableImage$1.loadTkImage(WritableImage.java:53) ? ? ? ? at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1342) ? ? ? ? at javafx.graphics/javafx.scene.Node.doSnapshot(Node.java:2136) ? ? ? ? at javafx.graphics/javafx.scene.Node.snapshot(Node.java:2214) ? ? ? ? at test.javafx.scene.Snapshot2Test.lambda$doTestTiledSnapshotImm$12(Snapshot2Test.java:364) test.javafx.scene.Snapshot2Test > testSnapshot2x1TilesSameSizeDefer[0] FAILED ? ? junit.framework.AssertionFailedError: Timeout waiting for snapshot callback ? ? ? ? at test.javafx.scene.SnapshotCommon.runDeferredSnapshotWait(SnapshotCommon.java:157) ? ? ? ? at test.javafx.scene.SnapshotCommon.runDeferredSnapshotWait(SnapshotCommon.java:183) ? ? ? ? at test.javafx.scene.Snapshot2Test.doTestTiledSnapshotDefer(Snapshot2Test.java:378) ? ? ? ? at test.javafx.scene.Snapshot2Test.testSnapshot2x1TilesSameSizeDefer(Snapshot2Test.java:459) I would suggest to fill the image with a single or preferably some pattern of multiple recognizable colors instead of noise. The noise gives a broken feel. It might confuse the verifications of any future fixes in this area. A well defined color would be nice. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Mon Jun 29 14:37:15 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 29 Jun 2020 14:37:15 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v5] In-Reply-To: References: Message-ID: On Mon, 29 Jun 2020 14:02:11 GMT, Ambarish Rapte wrote: >> I went ahead and wrote a bunch of tests that: >> 1. Setup a scene to display an `ImageView` of a selected dimensions chosen to trigger tiling in different ways when >> taking snapshots. 2. Fill up the image with noise. >> 3. Take a snapshot and do a pixel-wise comparison with the original image. >> >> I've added the new tests to the existing `Snapshot2Test.java`. > > I observed that the added tests are failing on mac machine(Mojave 10.14.6), but they do pass on windows10. Can you > please verify ? Timeout and Unrecognized Image loader errors from the log, > test.javafx.scene.Snapshot2Test > testSnapshot2x2TilesSameWidthImm[0] FAILED > ? ? java.lang.IllegalArgumentException: Unrecognized image loader: null > ? ? ? ? at javafx.graphics/javafx.scene.image.WritableImage.loadTkImage(WritableImage.java:278) > ? ? ? ? at javafx.graphics/javafx.scene.image.WritableImage$1.loadTkImage(WritableImage.java:53) > ? ? ? ? at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1342) > ? ? ? ? at javafx.graphics/javafx.scene.Node.doSnapshot(Node.java:2136) > ? ? ? ? at javafx.graphics/javafx.scene.Node.snapshot(Node.java:2214) > ? ? ? ? at test.javafx.scene.Snapshot2Test.lambda$doTestTiledSnapshotImm$12(Snapshot2Test.java:364) > > test.javafx.scene.Snapshot2Test > testSnapshot2x1TilesSameSizeDefer[0] FAILED > ? ? junit.framework.AssertionFailedError: Timeout waiting for snapshot callback > ? ? ? ? at test.javafx.scene.SnapshotCommon.runDeferredSnapshotWait(SnapshotCommon.java:157) > ? ? ? ? at test.javafx.scene.SnapshotCommon.runDeferredSnapshotWait(SnapshotCommon.java:183) > ? ? ? ? at test.javafx.scene.Snapshot2Test.doTestTiledSnapshotDefer(Snapshot2Test.java:378) > ? ? ? ? at test.javafx.scene.Snapshot2Test.testSnapshot2x1TilesSameSizeDefer(Snapshot2Test.java:459) > > I would suggest to fill the image with a single or preferably some pattern of multiple recognizable colors instead of > noise. The noise gives a broken feel. It might confuse the verifications of any future fixes in this area. A well > defined color would be nice. Thanks for your review. I don't have access to a Mac so I can't check that directly. The tests pass on both my Windows 10 and Ubuntu 20.04 environments and the stack isn't very helpful (it simply indicates the renderImage method returned null). Running the test with the unpatched version of the `QuantumToolkit::renderToImage` method would typically result in such a stack, but there are many other possible reasons. With regard to the choice of random noise for the test image, my idea was to be able to catch any misalignment caused by tiling in the final snapshot: using a single color or a simple pattern would not necessarily help catching such errors. Using a complex image could do the trick, and avoid the broken aspect you mentioned, but it would need to be very large (>4096x4096), and I was not sure it would be wise to add such a large binary resource to the repo. So I settled for random noise, since it was the simplest way to generate an image which guaranties any misalignment would be caught by comparing pixels 1 to 1. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From jpereda at openjdk.java.net Mon Jun 29 15:27:26 2020 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 29 Jun 2020 15:27:26 GMT Subject: Integrated: 8240264: iOS: Unnecessary logging on every pulse when GL context changes In-Reply-To: References: Message-ID: On Wed, 8 Apr 2020 08:37:27 GMT, Jose Pereda wrote: > This PR comments out too verbose console logging, as it has been done with some other fprintf calls. > As a follow up of this PR, a custom directive that enables this output if needed can be considered. This pull request has now been integrated. Changeset: 15f97ed4 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/15f97ed4 Stats: 28 lines in 3 files changed: 0 ins; 26 del; 2 mod 8240264: iOS: Unnecessary logging on every pulse when GL context changes Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/165 From github.com+7450507+fthevenet at openjdk.java.net Mon Jun 29 16:27:30 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 29 Jun 2020 16:27:30 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v5] In-Reply-To: References: Message-ID: On Mon, 29 Jun 2020 14:35:00 GMT, Frederic Thevenet wrote: >> I observed that the added tests are failing on mac machine(Mojave 10.14.6), but they do pass on windows10. Can you >> please verify ? Timeout and Unrecognized Image loader errors from the log, >> test.javafx.scene.Snapshot2Test > testSnapshot2x2TilesSameWidthImm[0] FAILED >> ? ? java.lang.IllegalArgumentException: Unrecognized image loader: null >> ? ? ? ? at javafx.graphics/javafx.scene.image.WritableImage.loadTkImage(WritableImage.java:278) >> ? ? ? ? at javafx.graphics/javafx.scene.image.WritableImage$1.loadTkImage(WritableImage.java:53) >> ? ? ? ? at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1342) >> ? ? ? ? at javafx.graphics/javafx.scene.Node.doSnapshot(Node.java:2136) >> ? ? ? ? at javafx.graphics/javafx.scene.Node.snapshot(Node.java:2214) >> ? ? ? ? at test.javafx.scene.Snapshot2Test.lambda$doTestTiledSnapshotImm$12(Snapshot2Test.java:364) >> >> test.javafx.scene.Snapshot2Test > testSnapshot2x1TilesSameSizeDefer[0] FAILED >> ? ? junit.framework.AssertionFailedError: Timeout waiting for snapshot callback >> ? ? ? ? at test.javafx.scene.SnapshotCommon.runDeferredSnapshotWait(SnapshotCommon.java:157) >> ? ? ? ? at test.javafx.scene.SnapshotCommon.runDeferredSnapshotWait(SnapshotCommon.java:183) >> ? ? ? ? at test.javafx.scene.Snapshot2Test.doTestTiledSnapshotDefer(Snapshot2Test.java:378) >> ? ? ? ? at test.javafx.scene.Snapshot2Test.testSnapshot2x1TilesSameSizeDefer(Snapshot2Test.java:459) >> >> I would suggest to fill the image with a single or preferably some pattern of multiple recognizable colors instead of >> noise. The noise gives a broken feel. It might confuse the verifications of any future fixes in this area. A well >> defined color would be nice. > > Thanks for your review. > > I don't have access to a Mac so I can't check that directly. > The tests pass on both my Windows 10 and Ubuntu 20.04 environments and the stack isn't very helpful (it simply > indicates the renderImage method returned null). > Running the test with the unpatched version of the `QuantumToolkit::renderToImage` method would typically result in > such a stack, but there are many other possible reasons. > With regard to the choice of random noise for the test image, my idea was to be able to catch any misalignment caused > by tiling in the final snapshot: using a single color or a simple pattern would not necessarily help catching such > errors. Using a complex image could do the trick, and avoid the broken aspect you mentioned, but it would need to be > very large (>4096x4096), and I was not sure it would be wise to add such a large binary resource to the repo. So I > settled for random noise, since it was the simplest way to generate an image which guaranties any misalignment would be > caught by comparing pixels 1 to 1. I have changed the test setup to fill up the scene with a gradient instead of random noise; it should be as able to catch misalignment, while not looking like something's gone horribly wrong. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Mon Jun 29 16:27:19 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 29 Jun 2020 16:27:19 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v13] In-Reply-To: References: Message-ID: > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Fill test image with a bilinear gradient instead of random noise. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/a01aaa20..efccc4d8 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.12 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.11-12 Stats: 16 lines in 1 file changed: 11 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Mon Jun 29 16:44:09 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 29 Jun 2020 16:44:09 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v5] In-Reply-To: References: Message-ID: On Mon, 29 Jun 2020 16:16:58 GMT, Frederic Thevenet wrote: >> Thanks for your review. >> >> I don't have access to a Mac so I can't check that directly. >> The tests pass on both my Windows 10 and Ubuntu 20.04 environments and the stack isn't very helpful (it simply >> indicates the renderImage method returned null). >> Running the test with the unpatched version of the `QuantumToolkit::renderToImage` method would typically result in >> such a stack, but there are many other possible reasons. >> With regard to the choice of random noise for the test image, my idea was to be able to catch any misalignment caused >> by tiling in the final snapshot: using a single color or a simple pattern would not necessarily help catching such >> errors. Using a complex image could do the trick, and avoid the broken aspect you mentioned, but it would need to be >> very large (>4096x4096), and I was not sure it would be wise to add such a large binary resource to the repo. So I >> settled for random noise, since it was the simplest way to generate an image which guaranties any misalignment would be >> caught by comparing pixels 1 to 1. > > I have changed the test setup to fill up the scene with a gradient instead of random noise; it should be as able to > catch misalignment, while not looking like something's gone horribly wrong. Also, while running the tests again on a ubuntu 20.04 VM, I encountered 2 occurences where one of the tests failed, out of ~8 runs in total. In one case, the error where similar to yours: > Task :systemTests:test test.javafx.scene.Snapshot2Test > testSnapshot2x2TilesSameSizeImm[3] FAILED java.lang.IllegalArgumentException: Unrecognized image loader: null at javafx.graphics/javafx.scene.image.WritableImage.loadTkImage(WritableImage.java:278) at javafx.graphics/javafx.scene.image.WritableImage$1.loadTkImage(WritableImage.java:53) at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1342) at javafx.graphics/javafx.scene.Node.doSnapshot(Node.java:2136) at javafx.graphics/javafx.scene.Node.snapshot(Node.java:2214) at test.javafx.scene.Snapshot2Test.lambda$doTestTiledSnapshotImm$12(Snapshot2Test.java:375) 148 tests completed, 1 failed While in the other, it pointed to an Out Of Memory Error: Task :systemTests:test test.javafx.scene.Snapshot2Test > testSnapshot2x2TilesSameHeightDefer[3] FAILED java.lang.OutOfMemoryError: Java heap space at java.base/java.nio.HeapByteBuffer.(HeapByteBuffer.java:63) at java.base/java.nio.ByteBuffer.allocate(ByteBuffer.java:351) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.createPlatformImage(QuantumToolkit.java:1426) at javafx.graphics/javafx.scene.image.Image.(Image.java:740) at javafx.graphics/javafx.scene.image.WritableImage.(WritableImage.java:77) at test.javafx.scene.Snapshot2Test.doTestTiledSnapshotDefer(Snapshot2Test.java:377) at test.javafx.scene.Snapshot2Test.testSnapshot2x2TilesSameHeightDefer(Snapshot2Test.java:489) 148 tests completed, 1 failed Again, in my environment, it only failed one test, and not all the time, but this could be the same root cause. Two ways we could find out would be by either increasing the max heap size for the test runner or use a smaller image and force the prism.maxTextureSize property to something less than 4096 to trigger tiling anyway. Unfortunately, I could not find out how to achieve either of these (simply passing the properties to the JVM running the Gradle wrapper seem to have no effect). ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+1413266+jgneff at openjdk.java.net Mon Jun 29 18:51:39 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Mon, 29 Jun 2020 18:51:39 GMT Subject: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened In-Reply-To: References: <59tIhawaXq53d5OeT-oudNfyA8DFOQi4qQEUKy6ho0M=.30e8c96e-1ee5-4997-b627-f9af9c6adc92@github.com> Message-ID: <8--OACSjfgvu2du_DnLxqAoTAIH7MwSdGpxkQAyuf7M=.2085b45b-18a3-4dad-beee-3abf1c0220cf@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Mon, 29 Jun 2020 11:26:50 GMT, Johan Vos wrote: >> Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). > > The rationale makes sense (open/open/close) instead of (open/close/open) Based on my notes below, I believe this change is safe for any Linux input device driver because the driver shouldn't receive the intermediate *open* and *close* calls at all. Nonetheless, it would be reassuring if someone could try [this change](https://github.com/openjdk/jfx/pull/258/files) just once on a mainstream device, such as the Raspberry Pi with a touchscreen LCD panel. I only have six obscure ARM devices and a headless QEMU ARM virtual machine for testing. @johanvos or @dellgreen - Is that something you could test? If you think it's overkill and not worth it, that's fine, too. #### Notes The Linux kernel documentation about [opening and closing](https://www.kernel.org/doc/html/latest/input/input-programming.html#dev-open-and-dev-close) input devices states: > Note that input core keeps track of number of users for the device and makes sure that dev->open() is called only when > the first user connects to the device and that dev->close() is called when the very last user disconnects. Calls to > both callbacks are serialized. Also, the Linux Programmer's Manual for the *close* system call (`man 2 close`) states: > If *fd* is the last file descriptor referring to the underlying open file description (see **open**(2)), the resources > associated with the open file description are freed. Running a JavaFX program with `strace -f -e trace=open,close -o strace.log` shows the one *open* for the *event0* keyboard, and the *open, open, close* for the *event1* touchscreen: 5847 open("/dev/input/event0", O_RDONLY) = 11 ... 5847 open("/dev/input/event1", O_RDONLY) = 12 5847 open("/dev/input/event1", O_RDONLY) = 13 5847 close(13) = 0 Both devices are actually closed by the kernel when the JavaFX program ends. ------------- PR: https://git.openjdk.java.net/jfx/pull/258 From kcr at openjdk.java.net Mon Jun 29 21:06:37 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 29 Jun 2020 21:06:37 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v5] In-Reply-To: References: Message-ID: <6nPqi3UKL6GK7G_dXLFt6X8DNU4bskyGGtdX0_tlIg8=.0c1ef663-6c85-4fa6-8ea6-96ce4d76ed0e@github.com> On Mon, 29 Jun 2020 16:41:53 GMT, Frederic Thevenet wrote: >> I have changed the test setup to fill up the scene with a gradient instead of random noise; it should be as able to >> catch misalignment, while not looking like something's gone horribly wrong. > > Also, while running the tests again on a ubuntu 20.04 VM, I encountered 2 occurences where one of the tests failed, out > of ~8 runs in total. In one case, the error where similar to yours: >> Task :systemTests:test > > test.javafx.scene.Snapshot2Test > testSnapshot2x2TilesSameSizeImm[3] FAILED > java.lang.IllegalArgumentException: Unrecognized image loader: null > at javafx.graphics/javafx.scene.image.WritableImage.loadTkImage(WritableImage.java:278) > at javafx.graphics/javafx.scene.image.WritableImage$1.loadTkImage(WritableImage.java:53) > at javafx.graphics/javafx.scene.Scene.doSnapshot(Scene.java:1342) > at javafx.graphics/javafx.scene.Node.doSnapshot(Node.java:2136) > at javafx.graphics/javafx.scene.Node.snapshot(Node.java:2214) > at test.javafx.scene.Snapshot2Test.lambda$doTestTiledSnapshotImm$12(Snapshot2Test.java:375) > > 148 tests completed, 1 failed > While in the other, it pointed to an Out Of Memory Error: > > Task :systemTests:test > > test.javafx.scene.Snapshot2Test > testSnapshot2x2TilesSameHeightDefer[3] FAILED > java.lang.OutOfMemoryError: Java heap space > at java.base/java.nio.HeapByteBuffer.(HeapByteBuffer.java:63) > at java.base/java.nio.ByteBuffer.allocate(ByteBuffer.java:351) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.createPlatformImage(QuantumToolkit.java:1426) > at javafx.graphics/javafx.scene.image.Image.(Image.java:740) > at javafx.graphics/javafx.scene.image.WritableImage.(WritableImage.java:77) > at test.javafx.scene.Snapshot2Test.doTestTiledSnapshotDefer(Snapshot2Test.java:377) > at test.javafx.scene.Snapshot2Test.testSnapshot2x2TilesSameHeightDefer(Snapshot2Test.java:489) > > 148 tests completed, 1 failed > > Again, in my environment, it only failed one test, and not all the time, but this could be the same root cause. Two > ways we could find out would be by either increasing the max heap size for the test runner or use a smaller image and > force the prism.maxTextureSize property to something less than 4096 to trigger tiling anyway. Unfortunately, I could > not find out how to achieve either of these (simply passing the properties to the JVM running the Gradle wrapper seem > to have no effect). It runs fine for me on Ubuntu 20.04 (VM) and Windows 10. I also see the failures on macOS. This isn't related to heap size. The failures are consistent, and hit virtually all of the tests whose dimensions are larger than 4096. Also, I modified the test to `@Ignore` all but one of the failing tests, and that test still fails. I instrumented the code, and from one of the failing tests I see this: renderToImage: need to tile image, size = 18000 x 90 renderTile: 4096 x 90 renderTile: 4096 x 90 renderTile: 4096 x 90 renderTile: 4096 x 90 renderTile: 1616 x 90 renderTile: 4096 x 0 This last tile is an illegal tile size (so you're probably just getting lucky that it isn't causing problems on Windows or Linux). I would check the tiling logic. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Mon Jun 29 21:54:15 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 29 Jun 2020 21:54:15 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v13] In-Reply-To: References: Message-ID: On Mon, 29 Jun 2020 16:27:19 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Fill test image with a bilinear gradient instead of random noise. I think I found the problem in the tiling logic that leads to the macOS failures. You need to check that the remainder width or height is > 0. Also, it looks like you have the "B" and "R" loops backwards, which is a bit confusing. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1612: > 1611: int bTileHeight = tileHeight; > 1612: while (bTileHeight == tileHeight && bOffset < h) { > 1613: renderTile(x, xOffset, y, bOffset, mTileWidth, bTileHeight, buffer, rf, tileRttCache, > pImage); It looks like the "B" and the "R" loops are reversed. This isn't causing any actual problems, but is confusing since it doesn't match the comment or the diagram above. The comment for this block says "B" tiles, but actually, it is the "R" tiles in the diagram that this is looping over. At the end of the main loop, `mTileWIdth` and `mTileHeight` will be set to the size of the corner tile. Given this, the tiles of `mTileWidth` X `tileHeight` will be the right hand column. Once you fix this, you will need to surround this `while` loop in a check for `if (mTileWidth > 0)` modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1620: > 1619: int rTileWidth = tileWidth; > 1620: while (rTileWidth == tileWidth && rOffset < w) { > 1621: renderTile(x, rOffset, y, yOffset, rTileWidth, mTileHeight, buffer, rf, tileRttCache, > pImage); Similarly, you will need to surround this `while` loop in a check for `if (mTileHeight > 0)` modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1626: > 1625: // Render corner "C" tile if needed > 1626: if (bOffset > 0 && rOffset > 0) { > 1627: renderTile(x, rOffset, y, bOffset, rTileWidth, bTileHeight, buffer, rf, tileRttCache, > pImage); I might recommend to also add a check for `mTileWidth > 0 && mTileHeight > 0` ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From kcr at openjdk.java.net Mon Jun 29 22:48:35 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 29 Jun 2020 22:48:35 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v13] In-Reply-To: References: Message-ID: <-_Q9yX7QBpY8nOyCubRlW-iAUD6SMv0MiXrpgI3m__I=.1f7f65df-895d-46fe-9921-d3cd2649c957@github.com> On Mon, 29 Jun 2020 21:50:50 GMT, Kevin Rushforth wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> Fill test image with a bilinear gradient instead of random noise. > > I think I found the problem in the tiling logic that leads to the macOS failures. You need to check that the remainder > width or height is > 0. Also, it looks like you have the "B" and "R" loops backwards, which is a bit confusing. Actually, it also fails the same way on Ubuntu 20.04 as it does on macOS if I force HW acceleration on Ubuntu. It's off by default when running in a VM, so is using the SW pipeline, which doesn't have a hard limit (so that could explain the heap problem you were facing). Ensuring that the tile size is > 0 fixes it on Linux and Mac. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From aghaisas at openjdk.java.net Tue Jun 30 06:03:52 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 30 Jun 2020 06:03:52 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6] In-Reply-To: References: Message-ID: <_tFE2b6zGmq38ggJ2ZDWbp4hXBWy2XxLfgtbtKM7Lps=.c75a7fef-9666-4aa3-a4c9-0db4efd9d5d3@github.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Sat, 27 Jun 2020 14:41:29 GMT, Kevin Rushforth wrote: >> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporating Kevin's review comments (overlooked some places). > > Looks good. @kevinrushforth, I see this is not integrated yet due to jcheck failure. No details about failure can be seen (At least I am unable to see any reported failures). Can you please have a look? ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From aghaisas at openjdk.java.net Tue Jun 30 06:03:52 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 30 Jun 2020 06:03:52 GMT Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6] In-Reply-To: References: Message-ID: On Sat, 27 Jun 2020 14:07:24 GMT, Rony G. Flatscher wrote: >> This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The >> PI data is turned into a boolean value using "Boolean.parseBoolean(String)". >> This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if >> the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case >> compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be >> done without compilation. Because of the fallback scripts get compiled with this version by default. >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> ### Issue >> * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement >> javax.script.Compilable compile scripts >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` >> `$ git checkout pull/192` > > Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: > > Incorporating Kevin's review comments (overlooked some places). Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From github.com+1413266+jgneff at openjdk.java.net Tue Jun 30 06:07:21 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 30 Jun 2020 06:07:21 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread In-Reply-To: References: Message-ID: On Sat, 27 Jun 2020 15:37:52 GMT, Kevin Rushforth wrote: > It will also need to be tested using the SW pipeline on all platforms. Thanks for the reminder. I managed to build JavaFX on Windows and macOS today, so I'll test this pull request on those platforms in addition to Linux desktop and embedded. ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From rony.flatscher at wu.ac.at Tue Jun 30 08:11:22 2020 From: rony.flatscher at wu.ac.at (Rony G Flatscher) Date: Tue, 30 Jun 2020 10:11:22 +0200 Subject: RFR: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts [v6] In-Reply-To: References: Message-ID: <94E1B3F5-5AC4-49A7-929E-25B2FB7B4833@wu.ac.at> Hi Ajit, Kevin looked into it already yesterday. There was some problem at github at the time I submitted the /integrate comment, which merely needs to be reissued by me. Having been on the road I was not able to do it yesterday, will be first thing after arriving at the office today. Also, thank you very much for your review efforts! Best regards ?-rony Rony G. Flatscher (mobil/e) > Am 29.06.2020 um 07:56 schrieb Ajit Ghaisas : > > ?On Sat, 27 Jun 2020 14:07:24 GMT, Rony G. Flatscher wrote: > >>> This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The >>> PI data is turned into a boolean value using "Boolean.parseBoolean(String)". >>> This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if >>> the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case >>> compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be >>> done without compilation. Because of the fallback scripts get compiled with this version by default. >>> --------- >>> ### Progress >>> - [x] Change must not contain extraneous whitespace >>> - [x] Commit message must refer to an issue >>> - [ ] Change must be properly reviewed >>> >>> ### Issue >>> * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement >>> javax.script.Compilable compile scripts >>> >>> >>> ### Download >>> `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` >>> `$ git checkout pull/192` >> >> Rony G. Flatscher has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporating Kevin's review comments (overlooked some places). > > Marked as reviewed by aghaisas (Reviewer). > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/192 From github.com+7450507+fthevenet at openjdk.java.net Tue Jun 30 09:44:44 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 30 Jun 2020 09:44:44 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v13] In-Reply-To: <-_Q9yX7QBpY8nOyCubRlW-iAUD6SMv0MiXrpgI3m__I=.1f7f65df-895d-46fe-9921-d3cd2649c957@github.com> References: <-_Q9yX7QBpY8nOyCubRlW-iAUD6SMv0MiXrpgI3m__I=.1f7f65df-895d-46fe-9921-d3cd2649c957@github.com> Message-ID: On Mon, 29 Jun 2020 22:46:26 GMT, Kevin Rushforth wrote: >> I think I found the problem in the tiling logic that leads to the macOS failures. You need to check that the remainder >> width or height is > 0. Also, it looks like you have the "B" and "R" loops backwards, which is a bit confusing. > > Actually, it also fails the same way on Ubuntu 20.04 as it does on macOS if I force HW acceleration on Ubuntu. It's off > by default when running in a VM, so is using the SW pipeline, which doesn't have a hard limit (so that could explain > the heap problem you were facing). Ensuring that the tile size is > 0 fixes it on Linux and Mac. I've pushed the changes discussed above, and verified that the tests now pass on a Ubuntu 20.04 VM with `prism.forceGpu=true` (and that they indeed failed prior to those changes). ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Tue Jun 30 09:44:33 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 30 Jun 2020 09:44:33 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v14] In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- > Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be > larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around > the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is > currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk > of regressions, either in terms of performances and correctness, while still offering some relief to the original > issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best > snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is > necessary while still introducing no regressions compared to the original solution. Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: Prevent attempt to render tiles with a 0 sized dimension. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/112/files - new: https://git.openjdk.java.net/jfx/pull/112/files/efccc4d8..c0f7d14f Webrevs: - full: https://webrevs.openjdk.java.net/jfx/112/webrev.13 - incr: https://webrevs.openjdk.java.net/jfx/112/webrev.12-13 Stats: 27 lines in 1 file changed: 12 ins; 8 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/112.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/112/head:pull/112 PR: https://git.openjdk.java.net/jfx/pull/112 From github.com+7450507+fthevenet at openjdk.java.net Tue Jun 30 09:44:45 2020 From: github.com+7450507+fthevenet at openjdk.java.net (Frederic Thevenet) Date: Tue, 30 Jun 2020 09:44:45 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v13] In-Reply-To: References: Message-ID: <73D1TSe4Llu-zn5_-FmDmPnNL4tLdgk3lFyZIeRPEiQ=.542bcbf7-d5c1-4fa8-8acd-23f79165024e@github.com> On Mon, 29 Jun 2020 21:32:33 GMT, Kevin Rushforth wrote: >> Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: >> >> Fill test image with a bilinear gradient instead of random noise. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1612: > >> 1611: int bTileHeight = tileHeight; >> 1612: while (bTileHeight == tileHeight && bOffset < h) { >> 1613: renderTile(x, xOffset, y, bOffset, mTileWidth, bTileHeight, buffer, rf, tileRttCache, >> pImage); > > It looks like the "B" and the "R" loops are reversed. This isn't causing any actual problems, but is confusing since it > doesn't match the comment or the diagram above. The comment for this block says "B" tiles, but actually, it is the "R" > tiles in the diagram that this is looping over. At the end of the main loop, `mTileWIdth` and `mTileHeight` will be set > to the size of the corner tile. Given this, the tiles of `mTileWidth` X `tileHeight` will be the right hand column. > Once you fix this, you will need to surround this `while` loop in a check for `if (mTileWidth > 0)` You're right: the comments and variable names are swapped. Will fix it (and obviously add the extra condition that prevents attempts to render 0 width/height tiles). Thanks. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From aghaisas at openjdk.java.net Tue Jun 30 11:21:15 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 30 Jun 2020 11:21:15 GMT Subject: RFR: 8248551: [TestBug] Ignore two failing FXML unit tests which use Nashorn script engine Message-ID: Issue : https://bugs.openjdk.java.net/browse/JDK-8248551 Fix : Added a check whether 'Nashorn' script engine is available before running the identified tests, otherwise tests are ignored. Testing : 1) With JDK-14, these tests pass- but they log a warning (same as existing behavior without this PR) 2) With JDK-15-ea, these tests get ignored. ------------- Commit messages: - check for Nashorn engine Changes: https://git.openjdk.java.net/jfx/pull/259/files Webrev: https://webrevs.openjdk.java.net/jfx/259/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248551 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/259.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/259/head:pull/259 PR: https://git.openjdk.java.net/jfx/pull/259 From github.com+60214806+ronyfla at openjdk.java.net Tue Jun 30 11:58:31 2020 From: github.com+60214806+ronyfla at openjdk.java.net (Rony G.Flatscher) Date: Tue, 30 Jun 2020 11:58:31 GMT Subject: Integrated: 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts In-Reply-To: References: Message-ID: On Mon, 20 Apr 2020 12:45:30 GMT, Rony G. Flatscher wrote: > This PR adds a "compile" process instruction to FXML files with the optional PI data "true" (default) and "false". The > PI data is turned into a boolean value using "Boolean.parseBoolean(String)". > This makes it possible to inject the compile PI everywhere in a FXML file and turn on and off compilation of scripts if > the scripting engine implements the javax.script.Compilable interface. The PR adds the ability for a fallback in case > compilation of scripts fails, in which case a warning gets issued about this fact and evaluation of the script will be > done without compilation. Because of the fallback scripts get compiled with this version by default. > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > ### Issue > * [JDK-8238080](https://bugs.openjdk.java.net/browse/JDK-8238080): FXMLLoader: if script engines implement > javax.script.Compilable compile scripts > > > ### Download > `$ git fetch https://git.openjdk.java.net/jfx pull/192/head:pull/192` > `$ git checkout pull/192` This pull request has now been integrated. Changeset: 45c9854c Author: Rony G. Flatscher Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/45c9854c Stats: 2553 lines in 29 files changed: 2 ins; 2523 del; 28 mod 8238080: FXMLLoader: if script engines implement javax.script.Compilable compile scripts Reviewed-by: kcr, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/192 From kcr at openjdk.java.net Tue Jun 30 12:38:17 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Jun 2020 12:38:17 GMT Subject: RFR: 8248551: [TestBug] Ignore two failing FXML unit tests which use Nashorn script engine In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 11:11:12 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8248551 > Fix : Added a check whether 'Nashorn' script engine is available before running the identified tests, otherwise tests > are ignored. > Testing : > 1) With JDK-14, these tests pass- but they log a warning (same as existing behavior without this PR) > 2) With JDK-15-ea, these tests get ignored. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/259 From arapte at openjdk.java.net Tue Jun 30 13:58:01 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 30 Jun 2020 13:58:01 GMT Subject: RFR: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 25 Jun 2020 23:19:05 GMT, Alexander Matveev wrote: > - Added DirectShow baseclasses to repository. > - Dependency on Windows SDK 7.1 DirectShow baseclasses was removed. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/254 From aghaisas at openjdk.java.net Tue Jun 30 14:03:06 2020 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 30 Jun 2020 14:03:06 GMT Subject: Integrated: 8248551: [TestBug] Ignore two failing FXML unit tests which use Nashorn script engine In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 11:11:12 GMT, Ajit Ghaisas wrote: > Issue : https://bugs.openjdk.java.net/browse/JDK-8248551 > Fix : Added a check whether 'Nashorn' script engine is available before running the identified tests, otherwise tests > are ignored. > Testing : > 1) With JDK-14, these tests pass- but they log a warning (same as existing behavior without this PR) > 2) With JDK-15-ea, these tests get ignored. This pull request has now been integrated. Changeset: 527cc2b0 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/527cc2b0 Stats: 19 lines in 1 file changed: 0 ins; 18 del; 1 mod 8248551: [TestBug] Ignore two failing FXML unit tests which use Nashorn script engine Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/259 From kcr at openjdk.java.net Tue Jun 30 15:41:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Jun 2020 15:41:29 GMT Subject: RFR: 8248317: Change JavaFX release version to 16 Message-ID: Bump the version number of JavaFX to 16. I will integrate this immediately after forking the `jfx15` stabilization branch. ------------- Commit messages: - 8248317: Change JavaFX release version to 16 Changes: https://git.openjdk.java.net/jfx/pull/260/files Webrev: https://webrevs.openjdk.java.net/jfx/260/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248317 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/260.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/260/head:pull/260 PR: https://git.openjdk.java.net/jfx/pull/260 From kcr at openjdk.java.net Tue Jun 30 15:41:29 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Jun 2020 15:41:29 GMT Subject: RFR: 8248317: Change JavaFX release version to 16 In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Tue, 30 Jun 2020 15:30:31 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 16. I will integrate this immediately after forking the `jfx15` stabilization > branch. @arapte please review ------------- PR: https://git.openjdk.java.net/jfx/pull/260 From github.com+10960818+Schmidor at openjdk.java.net Tue Jun 30 18:28:11 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 30 Jun 2020 18:28:11 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v2] In-Reply-To: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: <7iy75Q1BwFgHwqiVTAEcTH8_M6qnI3mqCC1ITvp8cE8=.bef5eac2-92e7-4cf2-a4ba-bb51fc33ceb3@github.com> > In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and Math.round produce different results and > EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one error on the line width and therefore sheared > rendering. The changes were already proposed by the submitter in JBS-8220484. > > OCA is signed and send. Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: Change to Math.ceil and add test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/246/files - new: https://git.openjdk.java.net/jfx/pull/246/files/5eda49bf..994ca03c Webrevs: - full: https://webrevs.openjdk.java.net/jfx/246/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/246/webrev.00-01 Stats: 161 lines in 3 files changed: 155 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/246.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/246/head:pull/246 PR: https://git.openjdk.java.net/jfx/pull/246 From github.com+10960818+Schmidor at openjdk.java.net Tue Jun 30 18:28:21 2020 From: github.com+10960818+Schmidor at openjdk.java.net (Oliver Schmidtmer) Date: Tue, 30 Jun 2020 18:28:21 GMT Subject: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v2] In-Reply-To: References: <5BAgCYHDciJXYR8QUaxH5c6pjuJH5nKiKSkTl834Sms=.f4819cc2-459c-436c-9b93-40afe93739e7@github.com> Message-ID: On Wed, 17 Jun 2020 07:32:46 GMT, Prasanta Sadhukhan wrote: >> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision: >> >> Change to Math.ceil and add test > > In 2D, we normally use sun.java2d.pipe.Region.clipRound as it also checks for -ve/+ve max INTEGER but I guess that is > internal class to FX so it's ok to use Math.round. Approval pending test creation. While both might work, as long as there is no mixed usage of round and ceil, Math.ceil seems to be better. I'm not sure if the timed waiting for the resizes is the best way for ensuring that the buffer is resized to the new bounds, so I'm open for suggestions. To me at least it seems to create a reproducible sheared output after the second resize in the test case and not anymore after changing the calculations to Math.ceil. ------------- PR: https://git.openjdk.java.net/jfx/pull/246 From kcr at openjdk.java.net Tue Jun 30 20:36:43 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Jun 2020 20:36:43 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v14] In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 09:44:33 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Prevent attempt to render tiles with a 0 sized dimension. I've finished my testing on 4 platforms: Windows 10, macOS 10.15, Ubuntu 16.10 (physical), Ubuntu 20.04 (VM with forceGPU set to true). All looks good. The code looks good too with a couple questions below. tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java line 31: > 30: import java.util.concurrent.ThreadLocalRandom; > 31: import java.util.stream.IntStream; > 32: These are now unused imports. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1569: > 1568: } > 1569: // Find out if it is possible to divide up the image in tiles of the same size > 1570: int tileWidth = computeTileSize(w, maxTextureSize); Very minor: this comment seems like a hold-over from when the method was computing an optimum size. Now the caller doesn't know about "tiles of the same size". modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1557: > 1556: // A temp QuantumImage used only as a RTT cache for rendering tiles. > 1557: var tileRttCache = new QuantumImage((com.sun.prism.Image) null); > 1558: try { In the case of a snapshot that isn't tiled, you will end up creating and disposing a dummy `QuantumImage` that is never used. Maybe it would be worth initializing it to null here, constructing the object in the `if (h > maxTextureSize || w > maxTextureSize)` block, and checking for null before disposing in the finally block? ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From almatvee at openjdk.java.net Tue Jun 30 21:31:18 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 30 Jun 2020 21:31:18 GMT Subject: Integrated: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo In-Reply-To: References: Message-ID: On Thu, 25 Jun 2020 23:19:05 GMT, Alexander Matveev wrote: > - Added DirectShow baseclasses to repository. > - Dependency on Windows SDK 7.1 DirectShow baseclasses was removed. This pull request has now been integrated. Changeset: 62f8cee7 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/62f8cee7 Stats: 38685 lines in 73 files changed: 8 ins; 38674 del; 3 mod 8247947: Build DirectShow Samples (Base Classes) from source checked into repo Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/254 From arapte at openjdk.java.net Tue Jun 30 21:31:36 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 30 Jun 2020 21:31:36 GMT Subject: RFR: 8238954: Improve performance of tiled snapshot rendering [v14] In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 09:44:33 GMT, Frederic Thevenet wrote: >> Issue JDK-8088198, where an exception would be thrown when trying to capture a snapshot whose final dimensions would be >> larger than the running platform's maximum supported texture size, was addressed in openjfx14. The fix, based around >> the idea of capturing as many tiles of the maximum possible size and re-compositing the final snapshot out of these, is >> currently only attempted after the original, non-tiled, strategy has already failed. This was decided to avoid any risk >> of regressions, either in terms of performances and correctness, while still offering some relief to the original >> issue. This follow-on issue aims to propose a fix to the original issue, that is able to correctly decide on the best >> snapshot strategy (tiled or not) to adopt before applying it and ensure best performances possible when tiling is >> necessary while still introducing no regressions compared to the original solution. > > Frederic Thevenet has updated the pull request incrementally with one additional commit since the last revision: > > Prevent attempt to render tiles with a 0 sized dimension. The code looks good to me too, suggested minor change. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1638: > 1637: renderWholeImage(x, y, w, h, rf, pImage); > 1638: } > 1639: params.platformImage = pImage; I tried to write this code using for loop to make it little easy for reader to understand. This is just a suggestion, I leave it to you to whether replace it or not, int mTileWidth = computeTileSize(w, maxTextureSize); int mTileHeight = computeTileSize(h, maxTextureSize); IntBuffer buffer = IntBuffer.allocate(mTileWidth * mTileHeight); int mTileXOffset = 0; int mTileYOffset = 0; for (mTileXOffset = 0; (mTileXOffset + mTileWidth) <= w; mTileXOffset += mTileWidth) { for (mTileYOffset = 0; (mTileYOffset + mTileHeight) <= h; mTileYOffset += mTileHeight) { renderTile(x, mTileXOffset, y, mTileYOffset, mTileWidth, mTileHeight, buffer, rf, tileRttCache, pImage); } } int rTileXOffset = mTileXOffset; int rTileWidth = w - rTileXOffset; if (rTileWidth > 0) { for (int rTileYOffset = 0; (rTileYOffset + mTileHeight) <= h; rTileYOffset += mTileHeight) { renderTile(x, rTileXOffset, y, rTileYOffset, rTileWidth, mTileHeight, buffer, rf, tileRttCache, pImage); } } int bTileYOffset = mTileYOffset; int bTileHeight = h - bTileYOffset; if (bTileHeight > 0) { for (int bTileXOffset = 0; (bTileXOffset + mTileWidth) <= w; bTileXOffset += mTileWidth) { renderTile(x, bTileXOffset, y, bTileYOffset, mTileWidth, bTileHeight, buffer, rf, tileRttCache, pImage); } } if (rTileWidth > 0 && bTileHeight > 0) { renderTile(x, rTileXOffset, y, bTileYOffset, rTileWidth, bTileHeight, buffer, rf, tileRttCache, pImage); } modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1564: > 1563: if (h > maxTextureSize || w > maxTextureSize) { > 1564: // The requested size for the screenshot is too big to fit a single texture, > 1565: // so we need to take several snapshot tiles and merge them into pImage Very minor: screenshot should be changed to snapshot. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 1635: > 1634: else { > 1635: // The requested size for the screenshot fits max texture size, > 1636: // so we can directly render it in the target image. Very minor: screenshot should be changed to snapshot. ------------- PR: https://git.openjdk.java.net/jfx/pull/112 From arapte at openjdk.java.net Tue Jun 30 21:36:40 2020 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 30 Jun 2020 21:36:40 GMT Subject: RFR: 8248317: Change JavaFX release version to 16 In-Reply-To: References: Message-ID: On Tue, 30 Jun 2020 15:30:31 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 16. I will integrate this immediately after forking the `jfx15` stabilization > branch. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/260 From kcr at openjdk.java.net Tue Jun 30 22:53:38 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Jun 2020 22:53:38 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread In-Reply-To: References: Message-ID: On Sun, 28 Jun 2020 02:35:16 GMT, John Neffenger wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Pixels.java line 194: >> >>> 193: public final Buffer getBuffer() { >>> 194: assert this.bytes != null || this.ints != null; >>> 195: return this.bytes != null ? this.bytes : this.ints; >> >> We should not use `assert` statements in the JavaFX runtime. If this is a condition that needs to be checked, then use >> an `if` test and throw an appropriate `RuntimeException` or an `InternalError`. > > Thanks, Kevin. I saw `assert` used elsewhere (`EventLoop` in the same package, for example), and thought it was > okay?even preferable?for these "should never occur" checks. Is that a general policy not to use `asserts` anywhere in > JavaFX? Should I also remove the asserts I added to `HeadlessScreen` and `EPDScreen` in lieu of a unit test case? I don't know whether it is documented, but we did at one point have a policy to avoid them and removed a few elsewhere in glass (which is where most of the usage was). The main reason is that when running applications that want to use assertion checking themselves it's too easy for a stray assert in a library to cause problems if we don't test for it. In case it really is an invariant, and nothing that could be provoked by API calls (which I think this case is), then checking explicitly seems best. I wouldn't recommend removing any existing `assert` statements, but we could file a follow-up issue to remove them ------------- PR: https://git.openjdk.java.net/jfx/pull/255 From github.com+1413266+jgneff at openjdk.java.net Tue Jun 30 23:11:56 2020 From: github.com+1413266+jgneff at openjdk.java.net (John Neffenger) Date: Tue, 30 Jun 2020 23:11:56 GMT Subject: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2] In-Reply-To: References: Message-ID: > Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Remove assert statements ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/255/files - new: https://git.openjdk.java.net/jfx/pull/255/files/47ad942a..d408506a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/255/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/255/webrev.00-01 Stats: 21 lines in 3 files changed: 5 ins; 14 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/255.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/255/head:pull/255 PR: https://git.openjdk.java.net/jfx/pull/255 From kcr at openjdk.java.net Tue Jun 30 23:17:06 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Jun 2020 23:17:06 GMT Subject: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v6] In-Reply-To: <5dDCIGDVd43vo4JtxBVmSlPpZAhMjMKV5es8BZ6nj6c=.90895611-47ba-4f08-8232-3d2edd95dcf5@github.com> References: <5dDCIGDVd43vo4JtxBVmSlPpZAhMjMKV5es8BZ6nj6c=.90895611-47ba-4f08-8232-3d2edd95dcf5@github.com> Message-ID: On Tue, 16 Jun 2020 09:03:35 GMT, Robert Lichtenberger wrote: >> This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException > > Move replaceSelectionAtEndWithListener test to general test class. > Add a more general test for selection/text properties and replace/undo/redo operations. Changing from using bindings to using listeners seems reasonable as long as there can't be a memory leak as a result (it should be fine). As I note inline below, I think the clamping is still wrong. Maybe you can't ever hit a case where it matters now, but it should still be fixed. modules/javafx.controls/src/main/java/javafx/scene/control/TextInputControl.java line 186: > 185: int length = txt.length(); > 186: if (end > start + length) end = length; > 187: if (start > length-1) start = end = 0; As I mentioned in [this comment in PR #73](https://github.com/openjdk/jfx/pull/73#discussion_r376528686), I think this test is wrong. The value of `start` has no impact on whether `end` is out of range. So... shouldn't this simply be `if (end > length) end = length;` ? ------------- PR: https://git.openjdk.java.net/jfx/pull/138